On Monday, June 10, 2024 9:10 PM, Yuri wrote: >On 6/10/24 16:55, rsbecker@xxxxxxxxxxxxx wrote: >> I have tried to reproduce your situation using git 2.43.0 without >> success. $ mkdir test $ cd test $ touch .nfs12309 $ git clean -df . >> Removing .nfs12309 > > >"touch .nfs12309" isn't enough. > > >Here is a reliable way to reproduce the problem: >1. Have a git repository on an NFS disk. >2. mkdir xx >3. touch xx/x >4. tail -f xx/x & >5. rm xx/x >6. git clean -df . > > > > >The last operation reproduces the problem. The xx directory and the .nfsNNNN file >in it stay without warnings. >The .nfsNNNN file is created by the NFS client when the xx/x file is removed. > > >Anybody with an NFS disk should be able to reproduce it. > >FYI: Git generally warns about files that it can't remove because of permissions and >special flags reasons. >But Git doesn't warn users about this situation with an NFS directory lock file. That is what I suspected. I am suspecting that git does not see the .nfsNNNN file when it is performing the clean. I think NFS creates the file after git does the scan, so as far as git is concerned, there is no .nfsNNNN file until after the operation completes. NFS puts the file there independent of git, so git does not even know about it. Does a second git clean -df . remove the .nfsNNNN file and put a new one, with a different name, in place?
