On Monday, June 10, 2024 7:28 PM, Yuri wrote:
>On 6/10/24 14:37, Junio C Hamano wrote:
>> But .nfs* files are not something you as an application are not
>> supposed to touch, so a directory that still contains one cannot be
>> removed, either. It's a limitation (I wouldn't call it a "bug") of
>> NFS. You can kill the process (or wait until they exit) holding the
>> file open and then run "clean -df" again, perhaps.
>
>
>With the '-f' the user tells git to remove all, and if this doesn't work git should tell
>the user that this didn't work for the .nfsNNNNNNN file and for the directory as
>well.
>
>
>Why is git quiet about leaving the files. It should complain.
>
>Or maybe there should be a verbosity option, like -v 10, that would make git
>complain about such things.
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
I have tried this with and without existing commits and files, but outside of an NFS context. Do you have a reproducible set of commands that I can try? What is in your .gitignore file? I saw a very old NFS situation where . prefix files did not get reported on some operating systems - I do not think this is what is happening, however. What do the commands ls -a and ls and find . -exec {} ";" report at the root of your repository? In NFSv4.1, there is a known situation where .nfsXXXXXX and .smbXXXXXX files are retained by NFS until the server is notified (or NFS determines) that the files have been closed by all clients. These files (with those names) may be automatically created by NFS (at its whim) and are managed by that subsystem - As I understand it, NFS manages removal of those files independently of the client or programs running on the client, so git may think the file is actually removed but the file may not actually be removed because the unlink() can be deferred by NFS. My suspicion is that this NFS itself might be contributing to the situation.
Can you try creating your repository, then restarting your server and client to isolate the "is open" tests that NFS could be doing, and see whether git clean continues to experience this?
--Randall
