有没有文件系统掩码这样的东西?

时间:2012-07-11 00:13:52

标签: filesystems windows-server-2008 symlink mask

我正在考虑使用Mask作为电路面具(我认为) - 让我用方便的图表来解释

mask chart

常见的来源是c:\source

实例A实际上位于c:\instanceA但最初只有符号链接到c:\source

中的所有内容

实例B实际上位于c:\instanceB但最初只有符号链接到c:\source

中的所有内容

当您对实例A和实例B进行更改时,您将创建一个掩码,如果从Instance文件夹中删除文件,则会隐藏CommonSource中的文件,如果现有的Common Source文件,则在实例目录中创建一个新的物理文件被修改了。 新文件将存在于实例文件夹中,但永远不会返回到公共源文件。

这种类型的设置对于我想对多个实例进行许多不同类型的小调整的项目非常有用,其中不同的线程可以在不同的实例上工作。

我知道符号链接,但在修改文件时却不尽如人意。

有什么能够实现这一目标吗?如果没有,我应该尝试制作并申请专利吗?对我来说似乎是一个好主意。

我将使用Windows Server 2008或更高版本。

5 个答案:

答案 0 :(得分:8)

我担心我会说明显而易见的,但是git是一种可以用来实现这种行为的工具。

  1. 让您的“Common Source”成为一个git存储库
  2. 将存储库两次克隆到“InstanceA”和“InstanceB”
  3. 在每个实例中,查看一个新的唯一分支
  4. 在“Common Source”中进行更改时,您可以将这些更改合并到“InstanceA”和“InstanceB”中,同时保持为每个创建的“MASK”(更改为分支)

    这样做的另一个好处是允许“公共源”的更改被,而不是将“公共源”推送更改为每个实例(我想象的东西不太可取,更容易出错)

答案 1 :(得分:2)

您正在寻找union mount。不幸的是,我不知道Windows的任何实现,但有几种可用于Linux,特别是UnionFS

通常,它们用于使只读文件系统看起来像是可读写的:通常在live-CD上。

答案 2 :(得分:1)

从Windows 7开始,您可以使用libraries,这将允许您包含来自多个物理位置的文件。

Windows 7还包括VirtualStore类型的文件夹(例如,在Program Files文件夹中创建或修改文件时,它实际上将在用户特定的文件夹中创建: C:\用户\用户名\应用程序数据\本地\ VirtualStore。但是 - 我不知道你如何自己创建这种类型的文件夹,而且据我所知,你可以添加和修改文件,但不能以这种方式删除文件。

答案 3 :(得分:1)

您需要一个支持每个文件签出和权限的版本控制系统。然后你只需要设置一个简单的API转换器,它接受文件系统命令并将它们转换为版本控制命令。

删除 - >禁用访问文件的权限。

目录命令应查找本地副本和您有权访问的内容。

打开 - >从存储库中的失败签出文件中获取本地副本。

保存 - >禁用权限,保存本地副本。 //避免重复看到。

不保存关闭 - >如果从存储库访问权限,则删除本地副本。

((顺便说一句,这种存储优化对于版本化来说似乎有些虚假。磁盘空间相对便宜。

如果您不想进行版本控制,我建议您尝试将您可能想要的信息分离出来并为每个分支创建配置文件。当然,这需要对变化采取可预测的模式。))

答案 4 :(得分:1)

IBM Rational ClearCase是版本控制系统,它执行类似文件掩码的行为。它被称为MVFS:MultiVersion文件系统,可以像普通网络驱动器一样安装到工作站。

ClearCase服务器(又名.VOB)您可以存储同一文件的多个版本,每个版本位于不同的代码分支上。用户可见的文件集称为视图。每个视图都有一个配置(也就是配置规范),它定义了当前用户可以看到的文件和版本。典型文件如下所示:

# From wikipedia: http://en.wikipedia.org/wiki/IBM_Rational_ClearCase#Configuration_specifications
# Show all elements that are checked out to this view, regardless any other rules.
element * CHECKEDOUT

# For all files named 'somefile', regardless of location, always show the latest version
# on the main branch.
element .../somefile /main/LATEST

# Use a specific version of a specific file. Note: This rule must appear before
# the next rule to have any effect!
element /vobs/project1/module1/a_header.h /main/proj_dev_branch/my_dev_branch1/14

# For other files in the 'project1/module1' directory, show versions
# labeled  'PROJ1_MOD2_LABEL_1'. Furthermore, don't allow any checkouts in this path.
element /vobs/project1/module1/... PROJ1_MOD2_LABEL_1 -nocheckout

# Show the 'ANOTHER_LABEL' version of all elements under the 'project1/module2' path.
# If an element is checked out, then branch that element from the currently
# visible version, and add it to the 'module2_dev_branch' branch.
element /vobs/project1/module2/... ANOTHER_LABEL -mkbranch module2_dev_branch