Question

我使用的代码库从Git存储库检出到我的Linux机器上。由于我们的生产代码是为部署在Linux上编写的，因此我在Linux机器上进行了所有测试，但是喜欢使用Windows进行日常使用，包括代码编辑/创作。

为此，我创建了一个文件夹（我的主文件夹）的 Samba共享，我在那里签出代码，如下所示：

[wgrover]
    path = /home/wgrover
    available = yes
    valid users = wgrover
    read only = no
    browsable = yes
    public = yes
    writable = yes

但是，当我从Windows中的samba共享\\linux-box\wgrover编辑文件时， Linux中的文件权限会在编辑之前保持更改为755，即使它是644 / strong>即可。

这样会一直显示在我的git diff中：

diff --git a/debian/maggie.nginx.conf b/debian/maggie.nginx.conf old mode 100644 new mode 100755 index 7cda506..7eab574

可以在smb.conf中设置create mask，但也不会“保留”原始文件权限。我可以通过在fileMode = false中设置.gitconfig来忽略git中的文件模式更改，但这也会忽略该问题。

有没有办法在从linux修改文件权限时保留文件权限？

Answer 1

最终可以弄清楚许可改变的原因。混淆源于map archive = yes设置是Samba中的默认值。设置map archive = no后，所有者执行位开始表现得像我预期的那样。

通过阅读此处的文档找到答案：{strong>文件权限和MS-DOS和Unix上的属性部分中的http://www.samba.org/samba/docs/using_samba/ch08.html。它清楚地提到了这种副作用：

因此，Samba磁盘共享中的文件中存在的三个Unix可执行位中的任何一个都没有用处。但是，DOS文件在Unix环境中存储时需要保留自己的属性：归档，系统和隐藏位。 Samba可以通过重用Unix端文件的可执行权限位来保留这些位 - 如果它被指示这样做的话。但是，映射这些位有一个不幸的副作用：如果Windows用户将文件存储在Samba共享中，并且您使用ls -al命令在Unix上查看它，则某些可执行位将不代表您的意思期待他们。

然而，它也提到了这一点：

我们应该警告您map archive选项的默认值为yes，而其他两个选项的默认值为no。这是因为如果没有为DOS和Windows文件正确存储存档位，许多程序将无法正常工作。但是，系统和隐藏属性对于程序的操作并不重要，由管理员自行决定。

您还可以在此处详细了解存档位：http://en.wikipedia.org/wiki/Archive_bit

在编辑文件时保留samba共享的文件权限

1 个答案: