RE: [BUG] "git clean -df ." silently doesn't delete folders with stale .nfs* files

[<rsbecker@nexbridge.com>]

On Tuesday, June 11, 2024 2:49 AM, Jeff King wrote:
>On Mon, Jun 10, 2024 at 06:09:52PM -0700, 'Yuri' wrote:
>
>> "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.
>
>That is not the behavior I get. I see:
>
>  $ git clean -df .
>  warning: failed to remove xx/.nfs0000000002c8197f00000002: Device or
>resource busy
>
>Which makes sense, since the kernel fails our unlink() call. Maybe your system
>behaves differently at the syscall level?
>
>This is a pretty standard Debian system with kernel 6.8.12. I set up the NFS mount
>with:
>
>   mkdir /mnt/{server,client}
>   exportfs -o rw,sync 127.0.0.1:/mnt/server
>   mount -t nfs 127.0.0.1:/mnt/server /mnt/client
>
>and then made the repository in /mnt/client. "mount" tells me it's using nfs4.
>
>Running "git clean" on the server side does remove the files (no warning, but the
>directories are actually removed).

It has been a while since I did a self-mount in NFS, but I do not think that will reproduce the issue. The mounts have to be on different servers from the client to experience this silly rename situation. On self-mount, IIRC, the client is aware that it is on its own machine and will not try to detect the situation.