Windows相当于Linux命名空间(每进程文件系统挂载)?

Linux有一个称为命名空间的function,它可以让您将文件系统的不同“视图”分配给不同的进程。 在Windows中,如果你有一个传统的程序“floyd”,总是从C:\floyd\floyd.ini加载它的configuration,这将是有用的。 如果Windows有命名空间,你可以编写一个封装脚本来创build一个运行floyd的命名空间,当Alice运行脚本时,floyd会在一个C:\floyd存在但实际上指向C:\Users\Alice\Floyd

现在你可能会想:“好的,只要使用软链接或硬链接,并为C:\Users\Alice制作C:\floyd别名即可。 但是对于命名空间,Bob也可以运行启动脚本,但是他的floyd实例(在同一台计算机上同时运行)将会看到C:\floyd ,内容为C:\Users\Bob\Program Settings\Floyd Config (或其他我们喜欢的path)。

你可以在Linux上用命名空间来做到这一点。 在Windows上有类似或相似的东西吗? 如果它需要编写一个C程序,那就好了,如果它只适用于最新版本的Windows,那也没关系。

Solutions Collecting From Web of "Windows相当于Linux命名空间(每进程文件系统挂载)?"

NTFS的硬链接是一个简单的重分析点的情况 。 重新分析点是键入的,可以包含更高级的行为。 例如,它们也用于“脱机存储”(将文件透明迁移到辅助存储和从辅助存储中迁移)。 因此,您也可以使用重新分析点来实现每个用户的符号链接,方法是创建一个新的重新分析类型。

重新分析点类型甚至还有一个明确的“名称代理”位,如果设置了这个位,则表示这些类型的重新分析点是某种符号链接。

甚至可以在路径中有多个重新分析点。 因此,符号名称空间中的文件仍然可以迁移到辅助存储 – 在路径中只有两个重新分析点。

我认为Virtual Store会自动为传统程序尝试写入非标准目录。 因此,传统程序写入用户和程序特定的目录,而不是C:\floyd

你可以使用硬链接,但只能使用NTFS。 http://en.wikipedia.org/wiki/Hard_link

我认为Windows不具有每个进程的虚拟FS视图。

最相关的事情可能是特殊的环境文件夹,如%temp%,%appdata%,%localappdata%。 不是说它们是相同的,但是它们实现相同的目的。

您可以定义自己的环境变量,然后使用'%myspecialplace%\ myfile.txt'来访问它们。

这听起来像Windows Vista的文件系统虚拟化 。 例如,它可以静默地将c:\Program Files\Floyd重定向到c:\Users\<username>\AppData\Local\VirtualStore\Program Files\Floyd 。 但是,文件系统虚拟化几乎不像Linux命名空间那样可配置。 从阅读中我可以看出,只要32位交互式进程打开,就可以应用文件系统虚拟化,以编写只能由管理员写入的文件,文件夹或注册表项。 (因此,通常最终会在c:\Program Files下创建一些只读c:\Program Files并在c:\Users\<username>\AppData\Local\VirtalStore下创建一些每个用户可写的文件。

应用程序虚拟化产品也可以做到这一点,尽管这些产品通常更复杂,更昂贵。

作为一个可怕的kludge(在这里我预订我的通道编程地狱)你可以使用C:\ Floyd命名管道,将IO操作映射到特定于当前进程用户的文件?

我知道这并不好,我对Windows上的NamedPipes(其他方言中的FIFO)知之甚少,知道这是多么可行。

我脑海中有几件事情。

首先,您可以创建一个文件系统过滤器驱动程序(或者使用一个准备好的驱动程序,比如我们的CallbackFilter产品),将来自应用程序的所有文件系统调用重定向到其他位置。 这与您提到的虚拟化非常接近,但这不会更改驱动器号的列表。 这种做法既强大又不平凡,所以首先看另一种选择。

另一个选择是:“包装”应用程序将其文件I / O重定向到某个其他位置的存在几个产品(如果内存服务的是Thinstall,Molebox)。 也有一些SDK也是这样做的,但是我根本不记得它的名字。

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

但我认为它不是每个用户可配置的,但是目标可以根据环境变量替换而改变每个用户。

但是,大多数程序将配置存储在注册表中,在这种情况下, RegOverridePredefKey将会执行此操作。

对此,缺乏良好的解决方案。 为了简单起见,我无法改进使用NTFS软链接(路口) – 正如您正确指出的那样,如果您想要每个用户的配置,这会产生问题。 正如MSalters所说,所有NTFS软硬链接都只是重分析点的特殊情况,所以如果您不介意挖掘到NTFS的某些工作,则可以通过添加新的重新分析类型来进行更一般化的操作。

(在使用NTFS软链接进行试验时,Junction是一个非常有用的工具: http : //technet.microsoft.com/en-us/sysinternals/bb896768.aspx )

你可以采取直接的方法 – 给每个用户(或者你的程序初始化,如果你只关心一个软件)登录脚本,在他们的用户目录中设置适当的连接点(并确保你在之后清理它)。 但是很笨拙

一般来说,正确的Windows方法是把东西放到%localappdata%(从Vista开始)指向的文件夹中,更普遍的是%userprofile%系统变量。 Win文件系统虚拟化旨在确保在适用的情况下。