Windows 相当于 Linux 命名空间（每进程文件系统挂载）？
Linux 有一个名为 命名空间 的功能，它可以让您提供不同进程的文件系统的不同“视图”。在 Windows 术语中，这将很有用，例如，如果您有一个始终从 C:\floyd\floyd.ini 加载其配置的遗留程序“floyd”。如果 Windows 有命名空间，您可以编写一个包装器脚本，该脚本将创建一个运行 floyd 的命名空间，这样当 Alice 运行脚本时，floyd 将在 C 的环境中启动:\floyd 存在，但实际上指向 C:\Users\Alice\Floyd。
现在您可能会想，“好吧，只需使用软链接或硬链接，并将 C:\floyd 设为 C:\Users\Alice 的别名即可。”但有了命名空间，Bob 也可以运行启动脚本，但他的 floyd 实例（在同一台计算机上，同时运行）将看到 C:\floyd ，其内容为 < code>C:\Users\Bob\Program Settings\Floyd Config （或我们喜欢的任何其他路径）。
您可以在 Linux 上使用命名空间来执行此操作。 Windows 上有类似的东西吗？如果需要编写 C 程序也可以，如果只适用于最新版本的 Windows，也可以。
Linux has a feature called namespaces, which let you give a different "view" of the filesystem to different processes. In Windows terms, this would be useful for example if you had a legacy program "floyd" that always loaded its configuration from C:\floyd\floyd.ini. If Windows had namespaces, you could write a wrapper script which would create a namespace in which to run floyd, making it so when Alice ran the script, floyd would start up in an environment where C:\floyd existed but actually pointed to C:\Users\Alice\Floyd.
Now you may be thinking, "OK, just use soft or hard links and make C:\floyd an alias for C:\Users\Alice." But with namespaces, Bob can also run the startup script, but his instance of floyd (on the same computer, running at the same time) will see C:\floyd with the contents of, say, C:\Users\Bob\Program Settings\Floyd Config (or any other path we like).
You can do this on Linux with namespaces. Is there something similar or analogous on Windows? It's fine if it requires writing a C program, and it's OK if it only works on recent versions of Windows.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
NTFS 硬链接实际上是重分析点的简单情况。重新分析点是键入的，并且可以包括更高级的行为。例如，它们还用于“离线存储”（文件与辅助存储之间的透明迁移）。因此，您还可以通过创建新的重分析类型，使用重分析点来实现每用户符号链接。
重分析点类型甚至具有显式的“名称代理”位，该位（如果设置）指示这些类型的重分析点是某种符号链接。
您甚至可以在路径中拥有多个重新分析点。因此，符号命名空间内的文件仍然可以迁移到辅助存储 - 您在路径中只有两个重新解析点。
NTFS hard links are really a simple case of reparse points. Reparse points are typed, and can include more advanced behavior. For instance, they're also used for "offline storage" (transparent migration of files to and from secondary storage). You can therefore also use reparse points to implement per-user symbolic links, by creating a new reparse type.
The reparse point type even has an explicit "Name surrogate" bit, which (if set) indicates that reparse points of those types are some kind of symbolic link.
You can even have multiple reparse points in a path. Therefore files inside your symbolic namepace can still be migrated to secondary storage - you'd just have two reparse points in the path.
我认为虚拟存储会自动为尝试写入非标准目录的遗留程序执行此操作。因此，遗留程序会写入用户和程序特定的目录，而不是
C:\floyd。I think Virtual Store does this automatically for legacy programs that try to write to nonstandard directories. So the legacy program writes to a user- and program-specific directory instead to
C:\floyd.这听起来像 Windows Vista 的文件系统虚拟化。例如，它可以静默地将
c:\Program Files\Floyd重定向到c:\Users\\AppData\Local\VirtualStore\Program Files\Floyd 。然而，文件系统虚拟化并不像 Linux 命名空间那样可配置。据我所知，只要打开 32 位交互式进程来写入只能由管理员写入的文件、文件夹或注册表项，文件系统虚拟化就应该应用。 （因此，您通常会在c:\Program Files下得到一些只读文件，在c:\Users\\AppData\Local\ 下得到一些每用户可写文件VirtalStore 。）应用程序虚拟化产品可能也可以做到这一点，尽管这些是通常更复杂且更昂贵。
This sounds like Windows Vista's file system virtualization. For example, it can silently redirect
c:\Program Files\Floydtoc:\Users\<username>\AppData\Local\VirtualStore\Program Files\Floyd. However, file system virtualization isn't nearly as configurable as Linux namespaces. From what I can tell from reading, file system virtualization should apply any time a 32-bit interactive process opens for writing a file, folder, or registry key that's only writable by administrators. (So you typically end up with some read-only files underc:\Program Filesand some per-user writable files underc:\Users\<username>\AppData\Local\VirtalStore.)An application virtualization product can probably also do this, although those are often more complicated and more expensive.
您可以为此使用硬链接，但仅限于 NTFS。 http://en.wikipedia.org/wiki/Hard_link
我认为 Windows 没有每个进程的虚拟 FS 视图。
You can use hardlinks for that, but only with NTFS. http://en.wikipedia.org/wiki/Hard_link
I think windows doesn't have virtual FS view per process.
最相关的可能是特殊的环境文件夹，例如％temp％，％appdata％，％localappdata％。并不是说它们是等效的，而是它们实现了相同的目的。
您可以定义自己的环境变量，然后使用“%myspecialplace%\myfile.txt”来访问它们。
The most relevant thing is probably special environment folders, such as %temp%, %appdata%, %localappdata%. Not that they're equivalent, but they fulfil the same purpose.
You can define your own environment variables then use '%myspecialplace%\myfile.txt' to access them.
作为一个可怕的拼凑（在这里我预订了我的编程地狱之路），您可以使用 C:\Floyd 的 NamedPipe 将 IO 操作映射到特定于当前进程用户的文件吗？
我知道这并不漂亮，而且我对 Windows 上的 NamedPipes（其他方言中的 FIFO）了解不够，不知道这有多可行。
担
As a horrid kludge (and here I book my passage to programming hell) could you use a NamedPipe for C:\Floyd that mapped the IO operations onto a file specific to the current process user?
I know it's not pretty and I don't know enough about NamedPipes (FIFOs in other dialects) on Windows to know how feasible this is.
Dan
我想到了几件事。
首先，您可以创建一个文件系统过滤驱动程序（或使用现成的驱动程序，例如我们的 CallbackFilter 产品），它将来自应用程序的所有文件系统调用重定向到其他位置。这与您提到的虚拟化很接近，但这不会改变驱动器盘符列表。这种方法既强大又不平凡，所以首先看看其他选项。
另一个选择是：
存在多种产品（如果没记错的话，Thinstall、Molebox）可以“包装”应用程序，将其文件 I/O 重定向到其他位置。还有一些 SDK 可以做同样的事情，但我根本不记得它的名字。
There are several things that come to my mind.
First of all you can create a file system filter driver (or use a ready driver, such as our CallbackFilter product) that would redirect all file system calls, coming from the application, to other location. This is close to virtualization that you mentioned but this won't change the list of drive letters though. Such approach is both powerful and non-trivial, so see the other option first of all.
And the other option is:
there exist several products (Thinstall, Molebox if memory serves) that "wrap" the application redirecting it's file I/O to some other location. There was also some SDK to do the same, but I don't remember it's name at all.
例如 http://www .msigeek.com/4819/file-re-direction-using- Correctfilepaths-shim-to-fix-broken-applications
但我认为它不能根据用户进行配置，尽管目标可以根据环境的不同而根据用户进行变化变量替换。
不过，大多数程序将配置存储在注册表中，在这种情况下 RegOverridePredefKey 就可以了。
e.g. http://www.msigeek.com/4819/file-re-direction-using-correctfilepaths-shim-to-fix-broken-applications
But I think it's not configurable per user, although the target can vary per-user based on environment variable substitution.
Most programs, though, store configuration in the registry, in which case RegOverridePredefKey would do the trick.
对此缺乏好的解决方案。为简单起见，我无法为此改进使用 NTFS 软链接（连接） - 正如您正确指出的那样，如果您想要按用户配置，这会产生问题。 如果您不介意深入研究 NTFS 的一些工作，您可以通过实现新的重新分析类型来执行更通用的操作。
正如 MSalters 正确所说，所有 NTFS 软链接和硬链接都只是重新分析点的特殊情况，因此， 尝试 NTFS 软链接时非常有用的工具：http://technet.microsoft。 com/en-us/sysinternals/bb896768.aspx ）
您可以采取直接方法 - 为每个用户（或您的程序初始化，如果您只关心一个软件）提供一个登录脚本，该脚本设置适当的连接到他们的用户目录（并确保之后清理它）。但它笨拙。
一般来说，正确的 Windows 方法是将内容放入 %localappdata%（从 Vista 开始）指向的文件夹中，更一般地说，将内容放入 %userprofile% 系统变量中。
Win 文件系统虚拟化旨在在其适用的情况下确保这一点。
There's a shortage of good solutions for this. For simplicity, I can't improve on using NTFS soft links (junctions) for this - as you correctly point out, this creates issues if you want per-user configuration. As MSalters correctly says, all NTFS soft and hard links are just special cases of reparse points, so you could do something more general by impplementing a new reparse type, if you don't mind some work digging into NTFS..
(Junction is a pretty useful tool when experimenting with NTFS soft links: http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx )
You could just take a direct approach - give each user (or your program initialization if you only care about one piece of software) a logon script that sets up the appropriate junction into their user directory (and make sure you clean it up afterwards). But it's clumsy.
In general the right Windows approach is to put things into the folders pointed at by the %localappdata% (from Vista on) and, more generally, %userprofile% system variables.
Win file system virtualization is intended to ensure this in the cases where it applies.