preserving file permissions for samba shares when file is edited

The code bases I work with are checked out from Git repositories onto my Linux machine. Since our production code is written to be deployed on Linux, I do all the testing on my Linux machine but like to use Windows for everyday usage, including code editing/authoring.

For that purpose, I have created a Samba share of the folder (my home folder) where I checkout the code to, like this:

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

However, when I edit a file from the samba share \\linux-box\wgrover in Windows, the file permission in Linux keeps changing to 755 even though it was 644 before editing.

This keeps showing up in my git diff like this:

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

It is possible to set a create mask in smb.conf but that will also not "preserve" the original file permissions. I can ignore file mode changes in git by setting fileMode = false in .gitconfig but that also ignores the problem.

Is there any way to preserve the file permissions when they are modified from linux?

Could finally figure out why permission was changing. The confusion arose from the map archive = yes setting being the default value in Samba. After setting map archive = no, the owner execute bit started behaving like I expected it to behave.

Found the answer by reading the documentation over here: http://www.samba.org/samba/docs/using_samba/ch08.html in the File Permissions and Attributes on MS-DOS and Unix section. It clearly mentions this side effect:

> Consequently, there is no use for any of the three Unix executable bits that are present on a file in a Samba disk share. DOS files, however, have their own attributes that need to be preserved when they are stored in a Unix environment: the archive, system, and hidden bits. Samba can preserve these bits by reusing the executable permission bits of the file on the Unix side--if it is instructed to do so. Mapping these bits, however, has an unfortunate side effect: if a Windows user stores a file in a Samba share, and you view it on Unix with the ls -al command, some of the executable bits won't mean what you'd expect them to.

However, it also mentions this:

> We should warn you that the default value of the map archive option is yes, while the other two options have a default value of no. This is because many programs do not work properly if the archive bit is not stored correctly for DOS and Windows files. The system and hidden attributes, however, are not critical for a program's operation and are left to the discretion of the administrator.

You can also read more about the archive bit over here: http://en.wikipedia.org/wiki/Archive_bit