Windows equivalente agli spazi dei nomi di Linux (supporti per filesystem per processo)?

Question

Linux ha una funzionalità chiamata namespaces, che consente di assegnare una "vista" diversa del filesystem a processi diversi. In termini Windows, questo sarebbe utile ad esempio se si avesse un programma legacy "floyd" che caricava sempre la sua configurazione da C:\floyd\floyd.ini. Se Windows avesse spazi dei nomi, potresti scrivere uno script wrapper che creerebbe uno spazio dei nomi in cui eseguire floyd, facendo in modo che quando Alice eseguisse lo script, floyd si avvierebbe in un ambiente in cui era presente C:\floyd ma in realtà puntava a C:\Users\Alice\Floyd.

Ora si potrebbe pensare, "OK, basta usare collegamenti soft o hard e rendere C:\floyd un alias per C:\Users\Alice." Ma con gli spazi dei nomi, Bob può anche eseguire lo script di avvio, ma la sua istanza di floyd (sullo stesso computer, in esecuzione allo stesso tempo) vedrà C:\floyd con il contenuto di, ad esempio, C:\Users\Bob\Program Settings\Floyd Config (o qualsiasi altro percorso che ci piace).

È possibile farlo su Linux con spazi dei nomi. C'è qualcosa di simile o analogo su Windows? Va bene se richiede la scrittura di un programma in C, ed è OK se funziona solo su versioni recenti di Windows.

Answer 1

NTFS collegamenti reali sono davvero un semplice caso di reparse points. I punti di analisi vengono digitati e possono includere un comportamento più avanzato. Ad esempio, vengono anche utilizzati per "storage offline" (migrazione trasparente di file da e verso storage secondario).È quindi possibile utilizzare anche punti di analisi per implementare collegamenti simbolici per utente, creando un nuovo tipo di analisi.

Il tipo di punto di reparse ha anche un bit "Nome surrogato" esplicito, che (se impostato) indica che i punti di analisi di tali tipi sono una sorta di collegamento simbolico.

È anche possibile avere più punti di analisi in un percorso. Pertanto i file all'interno della propria area simbolica possono ancora essere migrati nell'archiviazione secondaria: si avranno solo due punti di analisi nel percorso.

Answer 2

È possibile utilizzare gli hardlink per questo, ma solo con NTFS. http://en.wikipedia.org/wiki/Hard_link

Penso che Windows non abbia una vista virtuale per processo.

Answer 3

La cosa più rilevante sono probabilmente cartelle di ambiente speciali, come% temp%,% appdata%,% localappdata%. Non che siano equivalenti, ma soddisfano lo stesso scopo.

È possibile definire le proprie variabili di ambiente, quindi utilizzare "% myspecialplace% \ myfile.txt" per accedervi.

Answer 4

Penso che Virtual Store lo faccia automaticamente per i programmi legacy che tentano di scrivere su directory non standard. Quindi il programma legacy scrive su una directory specifica per utente e programma invece su C:\floyd.

Answer 5

Questo suona come file system virtualization di Windows Vista. Ad esempio, può reindirizzare automaticamente c:\Program Files\Floyd a c:\Users\<username>\AppData\Local\VirtualStore\Program Files\Floyd. Tuttavia, la virtualizzazione del file system non è quasi configurabile come i namespace di Linux. Da quello che posso dedurre dalla lettura, la virtualizzazione del file system dovrebbe applicarsi ogni volta che un processo interattivo a 32 bit si apre per scrivere un file, una cartella o una chiave di registro che è solo scrivibile dagli amministratori. (Così in genere si finisce con alcune file di sola lettura sotto c:\Program Files e alcuni file scrivibili per-utente in c:\Users\<username>\AppData\Local\VirtalStore.)

Un prodotto application virtualization probabilmente può fare anche questo, anche se questi sono spesso più complicato e più costoso.

Answer 6

Come horrid kludge (e qui prenoto il mio passaggio all'inferno di programmazione) potresti utilizzare NamedPipe per C: \ Floyd che ha mappato le operazioni di I/O su un file specifico per l'utente del processo corrente?

So che non è bello e non so abbastanza su NamedPipes (FIFO in altri dialetti) su Windows per sapere quanto sia fattibile.

Dan

Answer 7

ad es. http://www.msigeek.com/4819/file-re-direction-using-correctfilepaths-shim-to-fix-broken-applications

Ma penso che non sia configurabile per utente, sebbene la destinazione possa variare per utente in base alla sostituzione della variabile di ambiente.

La maggior parte dei programmi, tuttavia, memorizza la configurazione nel registro, nel qual caso RegOverridePredefKey farebbe il trucco.

Answer 8

Ci sono molte cose che mi vengono in mente.

Prima di tutto è possibile creare un driver di filtro del file system (o utilizzare un driver pronto, come il nostro prodotto CallbackFilter) che reindirizza tutte le chiamate al file system, provenienti dall'applicazione, in un'altra posizione. Questo è vicino alla virtualizzazione che hai menzionato, ma questo non cambierà comunque l'elenco delle lettere di unità. Tale approccio è sia potente che non banale, quindi vedi prima l'altra opzione.

E l'altra opzione è: esistono diversi prodotti (Thinstall, Molebox se serve la memoria) che "avvolgono" l'applicazione reindirizzando l'I/O del file in un'altra posizione. C'era anche un po 'di SDK per fare lo stesso, ma non ricordo affatto il suo nome.

Answer 9

C'è una carenza di buone soluzioni per questo. Per semplicità, non riesco a migliorare l'utilizzo dei collegamenti software NTFS (giunzioni) per questo, come si sottolinea correttamente, questo crea problemi se si desidera la configurazione per utente. Come dice correttamente MSalters, tutti i collegamenti soft e hard di NTFS sono solo casi speciali di reparse point, quindi potresti fare qualcosa di più generale inserendo un nuovo tipo di reparse, se non ti interessa lavorare in NTFS.

(Junction è uno strumento piuttosto utile quando si sperimentano i collegamenti software NTFS: http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx)

Si potrebbe semplicemente prendere un approccio diretto - dare ad ogni utente (o all'inizializzazione del programma se si interessa solo un pezzo di software) uno script di accesso che imposta la giunzione appropriata nella loro directory utente (e assicurati di pulirla in seguito). Ma è impacciato.

In generale, l'approccio corretto di Windows consiste nel mettere le cose nelle cartelle puntate da% localappdata% (da Vista in poi) e, più in generale,% userprofile% di variabili di sistema. La virtualizzazione del file system di Windows è concepita per garantire ciò nei casi in cui si applica.