Check out doesn't set x-flag on CIFS

Check out doesn't set x-flag on CIFS

[Andre Esser]

Hello,

When on a CIFS filesystem a git checkout does not replicate the executable
flag from the repository:

  $ git clone git://git/abettersqlplus
  Cloning into 'abettersqlplus'...
  remote: Counting objects: 522, done.
  remote: Compressing objects: 100% (342/342), done.
  remote: Total 522 (delta 166), reused 522 (delta 166)
  Receiving objects: 100% (522/522), 82.40 KiB, done.
  Resolving deltas: 100% (166/166), done.
  $ ls -l abettersqlplus/absp.py
  -rw-rw-r-- 1 aesser geneity 45860 May 29 14:46 abettersqlplus/absp.py


Subsequently git status reports the file as changed:

  $ cd abettersqlplus/
  $ git status
  # On branch master
  # Changes not staged for commit:
  #   (use "git add <file>..." to update what will be committed)
  #   (use "git checkout -- <file>..." to discard changes in working
  directory)
  #
  #    modified:   absp.py
  #
  no changes added to commit (use "git add" and/or "git commit -a")


If I set the x-flag manually, all is well:

  $ chmod +x absp.py
  $ git status
  # On branch master
  nothing to commit (working directory clean)


This problem doesn't occur on ext3 or NFS file systems. Client is Ubuntu
12.04 with git version 1.7.9.5. CIFS is exported from Ubuntu 12.04 with
Samba version 3.6.3.

Since git recognises the x-flag on this CIFS file system, shouldn't it also
be able to set it on checkout?


Many thanks,

Andre Esser

Re: Check out doesn't set x-flag on CIFS

[Erik Faye-Lund]

On Wed, May 29, 2013 at 4:16 PM, Andre Esser <andre.esser@geneity.co.uk> wrote:
> Hello,
>
> When on a CIFS filesystem a git checkout does not replicate the executable
> flag from the repository:
>
>   $ git clone git://git/abettersqlplus
>   Cloning into 'abettersqlplus'...
>   remote: Counting objects: 522, done.
>   remote: Compressing objects: 100% (342/342), done.
>   remote: Total 522 (delta 166), reused 522 (delta 166)
>   Receiving objects: 100% (522/522), 82.40 KiB, done.
>   Resolving deltas: 100% (166/166), done.
>   $ ls -l abettersqlplus/absp.py
>   -rw-rw-r-- 1 aesser geneity 45860 May 29 14:46 abettersqlplus/absp.py
>
>
> Subsequently git status reports the file as changed:
>
>   $ cd abettersqlplus/
>   $ git status
>   # On branch master
>   # Changes not staged for commit:
>   #   (use "git add <file>..." to update what will be committed)
>   #   (use "git checkout -- <file>..." to discard changes in working
>   directory)
>   #
>   #    modified:   absp.py
>   #
>   no changes added to commit (use "git add" and/or "git commit -a")
>
>
> If I set the x-flag manually, all is well:
>
>   $ chmod +x absp.py
>   $ git status
>   # On branch master
>   nothing to commit (working directory clean)
>
>
> This problem doesn't occur on ext3 or NFS file systems. Client is Ubuntu
> 12.04 with git version 1.7.9.5. CIFS is exported from Ubuntu 12.04 with
> Samba version 3.6.3.
>
> Since git recognises the x-flag on this CIFS file system, shouldn't it also
> be able to set it on checkout?
>

You might want to check out the core.filemode configuration variable.

Re: Check out doesn't set x-flag on CIFS

[Andre Esser]

On 2013-11-20 10:51, Erik Faye-Lund wrote:
> On Wed, May 29, 2013 at 4:16 PM, Andre Esser <andre.esser@geneity.co.uk> wrote:
>> Hello,
>>
>> When on a CIFS filesystem a git checkout does not replicate the executable
>> flag from the repository:
>>
>>   $ git clone git://git/abettersqlplus
>>   Cloning into 'abettersqlplus'...
>>   remote: Counting objects: 522, done.
>>   remote: Compressing objects: 100% (342/342), done.
>>   remote: Total 522 (delta 166), reused 522 (delta 166)
>>   Receiving objects: 100% (522/522), 82.40 KiB, done.
>>   Resolving deltas: 100% (166/166), done.
>>   $ ls -l abettersqlplus/absp.py
>>   -rw-rw-r-- 1 aesser geneity 45860 May 29 14:46 abettersqlplus/absp.py
>>
>>
>> Subsequently git status reports the file as changed:
>>
>>   $ cd abettersqlplus/
>>   $ git status
>>   # On branch master
>>   # Changes not staged for commit:
>>   #   (use "git add <file>..." to update what will be committed)
>>   #   (use "git checkout -- <file>..." to discard changes in working
>>   directory)
>>   #
>>   #    modified:   absp.py
>>   #
>>   no changes added to commit (use "git add" and/or "git commit -a")
>>
>>
>> If I set the x-flag manually, all is well:
>>
>>   $ chmod +x absp.py
>>   $ git status
>>   # On branch master
>>   nothing to commit (working directory clean)
>>
>>
>> This problem doesn't occur on ext3 or NFS file systems. Client is Ubuntu
>> 12.04 with git version 1.7.9.5. CIFS is exported from Ubuntu 12.04 with
>> Samba version 3.6.3.
>>
>> Since git recognises the x-flag on this CIFS file system, shouldn't it also
>> be able to set it on checkout?
>>
> 
> You might want to check out the core.filemode configuration variable.

Thanks, but unfortunately that only suppresses the error message, it
still doesn't set the x-flag when it should.

Andre

Re: Check out doesn't set x-flag on CIFS

[Erik Faye-Lund]

Sigh, it seems replying from Gmail on my phone culled the CC-list.
Sorry about that, and here's the rest of the discussion in case
someone else is interested:

On Wed, Nov 20, 2013 at 1:38 PM, Andre Esser <andre.esser@geneity.co.uk> wrote:
> On 2013-11-20 12:23, Erik Faye-Lund wrote:
>> On Wed, Nov 20, 2013 at 12:59 PM, Andre Esser <andre.esser@geneity.co.uk> wrote:
>>>
>>> There is with POSIX extensions, and git recognises it correctly when an
>>> executable file is being committed, ie the file's exec flag is set in
>>> the repository.
>>>
>>> If that file is then however checked out to the same CIFS file system,
>>> the exec flag is not set, which seems a least inconsistent.
>>
>> OK, in that case, core.filemode probably leads down the wrong path. In
>> fact, shouldn't everything just work? I mean, normal POSIX calls
>> should behave as ususal, no? Perhaps this is a Samba issue?
>
> We've had a look at the GIT source code (after my original post) and it
> seems that after GIT identifies the file system as CIFS, it doesn't even
> try to set the x-flag. Given POSIX extensions have been around for years
> it would probably be a good idea to change GIT's behaviour. But I'm no
> developer and we don't have the spare manpower in the company to look
> into this any deeper.
>
> Thanks for your replies though!
>
> Andre