ClearCase MVFS 文件权限

ClearCase MVFS files permissions

我开始理解我在 Git 和 ClearCase 之间的存储库同步过程中遇到的问题。

我们来看看这个:

$ cd
$ touch foo && chmod 777 foo
$ ls -al foo
-rwxrwxrwx+ 1 ch52198 Domain Users 0 Sep  4 15:04 foo
$ cd /vob/view/project/
$ cp ~/foo .
$ ls -al foo
$ -rw-r----- 1 ch52198 Domain Users 0 Sep  4 15:05 foo
$ chmod u+x foo
$ ls -al foo
$ -rw-r----- 1 ch52198 Domain Users 0 Sep  4 15:05 foo

ClearCase 做错了一切。使用 MVFS 存储时,它会忽略所有文件权限。

事情变得更糟,因为如果在我的本地 Git 存储库中,我在脚本上设置了可执行标志。我将永远无法在我的 ClearCase 存储库中保留此标志。

我该如何解决这个问题?

我尝试使用 cleartol protect -chmod 777 foo,但我看不到 Cygwin 的权限更改。

对于您复制的文件,您需要cleartool protect -chmod来恢复权限。

还要检查您认为的 umask。这将决定如何在 ClearCase 视图中设置与文件关联的 mod。

另请参阅“Access control for view-private files in dynamic views

On Linux and the UNIX system, the initial owner, group, and protection mode for a view-private file are determined by the following rules:

  • Owner. The initial owner is the user of the process that creates the file or directory.
  • Group. The initial group is the primary group of the process that creates the file or directory.
  • Protection mode. The initial protection mode for a view-private file depends on the umask of the user who creates the file or directory. A umask is a setting supported on Linux and the UNIX system that specifies that some permissions are not granted when the user creates a file. (For details, see the umask reference page on Linux or the UNIX system.)
    When a user creates a view-private file or directory, Rational ClearCase begins with a set of permissions that depend on how the file or directory is created. The permissions specified by the user’s umask are then removed by Rational ClearCase.
    For example, if the user’s umask is 002, write permission for others is removed by Rational ClearCase.