{"thread":{"id":"61618","subject":"[BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","startedAt":"2024-06-10T18:58:15Z","lastAt":"2024-06-13T09:21:30Z","messageCount":17,"participants":["Yuri","Junio C Hamano","rsbecker@nexbridge.com","'Yuri'","Chris Torek","Jeff King","Gabor Gombas"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"496786","messageId":"ae862adb-1475-48e9-bd50-0c07dc42a520@rawbw.com","threadId":"61618","inReplyTo":null,"subject":"[BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"Yuri","fromEmail":"yuri@rawbw.com","sentAt":"2024-06-10T18:36:28Z","receivedAt":"2024-06-10T18:58:15Z","isPatch":false,"sender":{"key":"yuri@rawbw.com","avatar":null},"body":"NFS sometimes leaves files like .nfsXXXXXXXXXXX which usually means that \nsome process that has this file open is alive.\n\n\n\"git clean -df .\" was supposed to remove the folder where such file is \nlocated, but it encountered the failure, and silently ignored it and \nsucceeded.\n\n\nDesired behavior: \"git clean -df .\" should notify the user with warnings \nor errors for each such file that it failed to remove.\n\n\nWhen \"git clean -df .\" succeeded I ran the next command and it failed \nbecause of the still-present folder with the .nfsXXXXXXXXX file in it.\n\n\nI believe that this is a bug in git.\n\n\ngit-2.38.1\n\n\n\nThanks,\n\nYuri\n\n\n"},{"id":"496792","messageId":"xmqqwmmw1sev.fsf@gitster.g","threadId":"61618","inReplyTo":"ae862adb-1475-48e9-bd50-0c07dc42a520@rawbw.com","subject":"Re: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-06-10T19:58:32Z","receivedAt":"2024-06-10T19:58:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yuri <yuri@rawbw.com> writes:\n\n> NFS sometimes leaves files like .nfsXXXXXXXXXXX which usually means\n> that some process that has this file open is alive.\n\nYes, and from everybody's point of view, including \"git\", a\ndirectory with such a file is not yet empty.\n\n> \"git clean -df .\" was supposed to remove the folder where such file is\n> located, but it encountered the failure, and silently ignored it and\n> succeeded.\n\nSo \"was supposed to remove\" above is not quite correct.  Where did\nsuch a piece of misinformation come from?\n\n"},{"id":"496795","messageId":"4ed426e4-beb6-45ed-b493-1e19c7c0511b@rawbw.com","threadId":"61618","inReplyTo":"xmqqwmmw1sev.fsf@gitster.g","subject":"Re: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"Yuri","fromEmail":"yuri@rawbw.com","sentAt":"2024-06-10T20:08:38Z","receivedAt":"2024-06-10T20:08:50Z","isPatch":false,"sender":{"key":"yuri@rawbw.com","avatar":null},"body":"On 6/10/24 12:58, Junio C Hamano wrote:\n> So \"was supposed to remove\" above is not quite correct. Where did such \n> a piece of misinformation come from?\n\n\n\"git clean -df .\" removes all files that\n\n(1) aren't added to the repo\n\n(2) aren't added as exceptions\n\n(3) aren't repo files themselves.\n\n\n\n\nIs the above definition incorrect?\n\n\n\n\n\n\nYuri\n\n"},{"id":"496806","messageId":"xmqqikygzdgk.fsf@gitster.g","threadId":"61618","inReplyTo":"4ed426e4-beb6-45ed-b493-1e19c7c0511b@rawbw.com","subject":"Re: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-06-10T21:37:31Z","receivedAt":"2024-06-10T21:37:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yuri <yuri@rawbw.com> writes:\n\n> On 6/10/24 12:58, Junio C Hamano wrote:\n>> So \"was supposed to remove\" above is not quite correct. Where did\n>> such a piece of misinformation come from?\n>\n>\n> \"git clean -df .\" removes all files that\n>\n> (1) aren't added to the repo\n>\n> (2) aren't added as exceptions\n>\n> (3) aren't repo files themselves.\n\nBut .nfs* files are not something you as an application are not\nsupposed to touch, so a directory that still contains one cannot be\nremoved, either.\n\nIt's a limitation (I wouldn't call it a \"bug\") of NFS.  You can kill\nthe process (or wait until they exit) holding the file open and then\nrun \"clean -df\" again, perhaps.\n\nA few Google searches tell us more, e.g.\n\n - https://nfs.sourceforge.net/#faq_d2\n - https://kb.netapp.com/on-prem/ontap/da/NAS/NAS-KBs/What_are_nfsXXXX_files_and_how_do_I_delete_them\n\nThey tell us what these files, which are the result of \"silly\nrename\", are, why they exist, and that they will appear again even\nif we remove them.  So we don't remove them, which means the\ndirectory that contains them will not become empty, which in turn\nmeans we do not remove them.\n\n"},{"id":"496815","messageId":"e8feffd0-ba6d-4aae-8c80-3d6482896b08@rawbw.com","threadId":"61618","inReplyTo":"xmqqikygzdgk.fsf@gitster.g","subject":"Re: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"Yuri","fromEmail":"yuri@rawbw.com","sentAt":"2024-06-10T23:27:32Z","receivedAt":"2024-06-10T23:27:35Z","isPatch":false,"sender":{"key":"yuri@rawbw.com","avatar":null},"body":"On 6/10/24 14:37, Junio C Hamano wrote:\n> But .nfs* files are not something you as an application are not \n> supposed to touch, so a directory that still contains one cannot be \n> removed, either. It's a limitation (I wouldn't call it a \"bug\") of \n> NFS. You can kill the process (or wait until they exit) holding the \n> file open and then run \"clean -df\" again, perhaps.\n\n\nWith the '-f' the user tells git to remove all, and if this doesn't work \ngit should tell the user that this didn't work for the .nfsNNNNNNN file \nand for the directory as well.\n\n\nWhy is git quiet about leaving the files. It should complain.\n\nOr maybe there should be a verbosity option, like -v 10, that would make \ngit complain about such things.\n\n\n\n\n\n\n\nThanks,\n\nYuri\n\n"},{"id":"496817","messageId":"0ee501dabb91$aa2340a0$fe69c1e0$@nexbridge.com","threadId":"61618","inReplyTo":"e8feffd0-ba6d-4aae-8c80-3d6482896b08@rawbw.com","subject":"RE: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-06-10T23:55:20Z","receivedAt":"2024-06-10T23:55:37Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Monday, June 10, 2024 7:28 PM, Yuri wrote:\n>On 6/10/24 14:37, Junio C Hamano wrote:\n>> But .nfs* files are not something you as an application are not\n>> supposed to touch, so a directory that still contains one cannot be\n>> removed, either. It's a limitation (I wouldn't call it a \"bug\") of\n>> NFS. You can kill the process (or wait until they exit) holding the\n>> file open and then run \"clean -df\" again, perhaps.\n>\n>\n>With the '-f' the user tells git to remove all, and if this doesn't work git should tell\n>the user that this didn't work for the .nfsNNNNNNN file and for the directory as\n>well.\n>\n>\n>Why is git quiet about leaving the files. It should complain.\n>\n>Or maybe there should be a verbosity option, like -v 10, that would make git\n>complain about such things.\n\nI have tried to reproduce your situation using git 2.43.0 without success.\n\n$ mkdir test\n$ cd test\n$ touch .nfs12309\n$ git clean -df .\nRemoving .nfs12309\n\nI 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.\n\nCan 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?\n\n--Randall\n\n"},{"id":"496819","messageId":"xmqqmsnsxqwy.fsf@gitster.g","threadId":"61618","inReplyTo":"0ee501dabb91$aa2340a0$fe69c1e0$@nexbridge.com","subject":"Re: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-06-11T00:29:49Z","receivedAt":"2024-06-11T00:29:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"<rsbecker@nexbridge.com> writes:\n\n> I have tried to reproduce your situation using git 2.43.0 without success.\n>\n> $ mkdir test\n> $ cd test\n> $ touch .nfs12309\n> $ git clean -df .\n> Removing .nfs12309\n\nI suspec that this is different from a real NFSv3 client in that\nremoval of such \"removed while still open\" files would result in\nanother one automatically resurrected by the filesystem.\n\nIn any case, if we cannot remove a file (due to filesystem\nlimitation), we should report the fact, just like in a case\nwhere we cannot remove a regular file, e.g.\n\n    $ cd git.git/\n    $ mkdir -p junk/ttt\n    $ >junk/ttt/sss\n    $ chmod a-w junk/ttt\n    $ cd junk\n    $ git clean -f -d -x ttt; echo $?\n    warning: failed to remove ttt/sss: Permission denied\n    1\n\nFiguring out why it is not happening is left as an exercise to\nreaders ;-), as I no longer have an NFSv3 environment handy.\n\nThanks.\n"},{"id":"496820","messageId":"8fdc76e2-3de2-4312-956c-2662336fa54d@rawbw.com","threadId":"61618","inReplyTo":"0ee501dabb91$aa2340a0$fe69c1e0$@nexbridge.com","subject":"Re: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"'Yuri'","fromEmail":"yuri@rawbw.com","sentAt":"2024-06-11T01:09:52Z","receivedAt":"2024-06-11T01:09:58Z","isPatch":false,"sender":{"key":"yuri@rawbw.com","avatar":null},"body":"On 6/10/24 16:55, rsbecker@nexbridge.com wrote:\n> I have tried to reproduce your situation using git 2.43.0 without \n> success. $ mkdir test $ cd test $ touch .nfs12309 $ git clean -df . \n> Removing .nfs12309 \n\n\n\"touch .nfs12309\" isn't enough.\n\n\nHere is a reliable way to reproduce the problem:\n1. Have a git repository on an NFS disk.\n2. mkdir xx\n3. touch xx/x\n4. tail -f xx/x &\n5. rm xx/x\n6. git clean -df .\n\n\n\n\nThe last operation reproduces the problem. The xx directory and the \n.nfsNNNN file in it stay without warnings.\nThe .nfsNNNN file is created by the NFS client when the xx/x file is \nremoved.\n\n\nAnybody with an NFS disk should be able to reproduce it.\n\nFYI: Git generally warns about files that it can't remove because of \npermissions and special flags reasons.\nBut Git doesn't warn users about this situation with an NFS directory \nlock file.\n\n\nThanks,\nYuri\n\n\n"},{"id":"496821","messageId":"0eef01dabb9d$70c99690$525cc3b0$@nexbridge.com","threadId":"61618","inReplyTo":"8fdc76e2-3de2-4312-956c-2662336fa54d@rawbw.com","subject":"RE: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-06-11T01:19:38Z","receivedAt":"2024-06-11T01:19:53Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Monday, June 10, 2024 9:10 PM, Yuri wrote:\n>On 6/10/24 16:55, rsbecker@nexbridge.com wrote:\n>> I have tried to reproduce your situation using git 2.43.0 without\n>> success. $ mkdir test $ cd test $ touch .nfs12309 $ git clean -df .\n>> Removing .nfs12309\n>\n>\n>\"touch .nfs12309\" isn't enough.\n>\n>\n>Here is a reliable way to reproduce the problem:\n>1. Have a git repository on an NFS disk.\n>2. mkdir xx\n>3. touch xx/x\n>4. tail -f xx/x &\n>5. rm xx/x\n>6. git clean -df .\n>\n>\n>\n>\n>The last operation reproduces the problem. The xx directory and the .nfsNNNN file\n>in it stay without warnings.\n>The .nfsNNNN file is created by the NFS client when the xx/x file is removed.\n>\n>\n>Anybody with an NFS disk should be able to reproduce it.\n>\n>FYI: Git generally warns about files that it can't remove because of permissions and\n>special flags reasons.\n>But Git doesn't warn users about this situation with an NFS directory lock file.\n\nThat 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?\n\n"},{"id":"496822","messageId":"b8f8fa08-e4a0-4755-99f0-9311b05945dd@rawbw.com","threadId":"61618","inReplyTo":"0eef01dabb9d$70c99690$525cc3b0$@nexbridge.com","subject":"Re: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"'Yuri'","fromEmail":"yuri@rawbw.com","sentAt":"2024-06-11T01:22:29Z","receivedAt":"2024-06-11T01:22:35Z","isPatch":false,"sender":{"key":"yuri@rawbw.com","avatar":null},"body":"On 6/10/24 18:19, rsbecker@nexbridge.com wrote:\n> That is what I suspected. I am suspecting that git does not see the \n> .nfsNNNN file when it is performing the clean. I think NFS creates the \n> file after git does the scan, so as far as git is concerned, there is \n> no .nfsNNNN file until after the operation completes. NFS puts the \n> file there independent of git, so git does not even know about it. \n> Does a second git clean -df . remove the .nfsNNNN file and put a new \n> one, with a different name, in place?\n\n\nNo, *only* the .nfsXXXX file exists in the xx directory when git runs.\n\n\n\n\nYuri\n\n\n"},{"id":"496823","messageId":"CAPx1GveJ-ckaoxqTQ9-jpRGw8p0SO0+xxL4vErW1tv3tE83=Kw@mail.gmail.com","threadId":"61618","inReplyTo":"b8f8fa08-e4a0-4755-99f0-9311b05945dd@rawbw.com","subject":"Re: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2024-06-11T01:46:45Z","receivedAt":"2024-06-11T01:46:58Z","isPatch":false,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Mon, Jun 10, 2024 at 6:22 PM Yuri <yuri@rawbw.com> wrote:\n> No, *only* the .nfsXXXX file exists in the xx directory when git runs.\n\nIn the case you showed, yes. However, there are *at least* two\n*different* problem cases, one of which gives Git no warning that\nsomething weird is going on.\n\nThe way \"NFS silly renames\" work is this:\n\n * an NFS client tells an NFS server to do operations, and this\n   is (nominally) stateless;\n\n * if an NFS client tells the server to remove a file, the server\n   attempts to remove the file;\n\n * but for POSIX-style operation, if a client knows that some file\n   is *open* and that *same client* intends to remove the file,\n   the client *must not* send a removal request.  Instead, the\n   client sends a \"rename\" request, renaming the original file\n   to \".nfs<unique-id>\".  When the client's last user of the file\n   closes its last file descriptor, the client *then* sends the\n   final remove for the renamed file.\n\nSo, the scenarios we must consider are these:\n\n 1. Nobody has the file open anywhere.  The client will send a\n    removal request and the server will obey or not depending on\n    permissions.\n\n 2. The server itself has the file open, but no client does.  The\n    client will send a removal request and the server (assuming it\n    is itself a POSIX system) will unlink the open file, really\n    deleting the file later on final close.\n\n 3. The server does not have the file open, but some client does.\n    This could be a *different* client, in which case your Git\n    process will result in a removal request, which will operate\n    as in cases 1 and 2 above.  Or this could be *your* client, in\n    which case your Git process will cause your client OS to send\n    a \"silly rename\" if it has not already done so, *or* will cause\n    your client *not* to send a removal request.\n\nSo, the main problem cases are case 3, where your own client is\nthe one that has the file open.  This causes your OS to *convert*\nan unlink() call into a rename() call for a \"silly rename\", in\neffect, *if* your OS has not yet done a silly rename.  But if your\nOS has *already done* a \"silly rename\", your OS knows that the\n\".nfs<unique-id>\" name is its own preserved name.\n\nIf the silly-rename operation has already occurred, your OS has\nthe option of making the unlink(\".nfs<unique-id>\") operation fail,\nor ignoring it entirely.  If not, however, your OS has only one\noption: to convert the unlink() to a silly rename and *report\nsuccess*.\n\nThat last case will definitely fool Git, which sees a successful\nresult of its unlink() call.  The other case -- the one where the\nsilly rename has already occurred -- will either report a failure\nto unlink the silly-name \".nfs<unique-id>\" file, which Git could\ndetect at that point, or will report success, lying to Git.\n\nIn both cases, of course, the directory will be non-empty at\nthe end of the series of unlink() calls, and the attempt to remove\nthe directory will fail with ENOTEMPTY.  Presumably Git should\ndetect this and warn, but there's nothing else Git can do here.\n\nAnyway, that's the OS view of this mess. I leave the work on\nGit itself to others. :-)\n\nChris\n"},{"id":"496835","messageId":"20240611064847.GC3248245@coredump.intra.peff.net","threadId":"61618","inReplyTo":"8fdc76e2-3de2-4312-956c-2662336fa54d@rawbw.com","subject":"Re: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-06-11T06:48:47Z","receivedAt":"2024-06-11T06:48:49Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jun 10, 2024 at 06:09:52PM -0700, 'Yuri' wrote:\n\n> \"touch .nfs12309\" isn't enough.\n> \n> Here is a reliable way to reproduce the problem:\n> 1. Have a git repository on an NFS disk.\n> 2. mkdir xx\n> 3. touch xx/x\n> 4. tail -f xx/x &\n> 5. rm xx/x\n> 6. git clean -df .\n> \n> The last operation reproduces the problem. The xx directory and the .nfsNNNN\n> file in it stay without warnings.\n> The .nfsNNNN file is created by the NFS client when the xx/x file is\n> removed.\n\nThat is not the behavior I get. I see:\n\n  $ git clean -df .\n  warning: failed to remove xx/.nfs0000000002c8197f00000002: Device or resource busy\n\nWhich makes sense, since the kernel fails our unlink() call. Maybe your\nsystem behaves differently at the syscall level?\n\nThis is a pretty standard Debian system with kernel 6.8.12. I set up the\nNFS mount with:\n\n   mkdir /mnt/{server,client}\n   exportfs -o rw,sync 127.0.0.1:/mnt/server\n   mount -t nfs 127.0.0.1:/mnt/server /mnt/client\n\nand then made the repository in /mnt/client. \"mount\" tells me it's using\nnfs4.\n\nRunning \"git clean\" on the server side does remove the files (no\nwarning, but the directories are actually removed).\n\n-peff\n"},{"id":"496838","messageId":"ed33cfa9-d0e2-4e98-95e9-e210b24ac337@rawbw.com","threadId":"61618","inReplyTo":"20240611064847.GC3248245@coredump.intra.peff.net","subject":"Re: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"'Yuri'","fromEmail":"yuri@rawbw.com","sentAt":"2024-06-11T07:43:51Z","receivedAt":"2024-06-11T07:44:05Z","isPatch":false,"sender":{"key":"yuri@rawbw.com","avatar":null},"body":"On 6/10/24 23:48, Jeff King wrote:\n> $ git clean -df . warning: failed to remove \n> xx/.nfs0000000002c8197f00000002: Device or resource busy Which makes \n> sense, since the kernel fails our unlink() call. Maybe your system \n> behaves differently at the syscall level?\n\n\nThe system I observed the problem is Centos with the kernel \n3.10.0-1160.76.1.el7.x86_64 (10 years old).\n\n\n\"rm -rf xx\" command also says Device or resource busy\nBut git-2.43.0 doesn't say anything.\n\n\n\n\nYuri\n\n\n"},{"id":"496924","messageId":"102101dabc06$16dfead0$449fc070$@nexbridge.com","threadId":"61618","inReplyTo":"20240611064847.GC3248245@coredump.intra.peff.net","subject":"RE: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-06-11T13:48:43Z","receivedAt":"2024-06-11T13:49:07Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Tuesday, June 11, 2024 2:49 AM, Jeff King wrote:\n>On Mon, Jun 10, 2024 at 06:09:52PM -0700, 'Yuri' wrote:\n>\n>> \"touch .nfs12309\" isn't enough.\n>>\n>> Here is a reliable way to reproduce the problem:\n>> 1. Have a git repository on an NFS disk.\n>> 2. mkdir xx\n>> 3. touch xx/x\n>> 4. tail -f xx/x &\n>> 5. rm xx/x\n>> 6. git clean -df .\n>>\n>> The last operation reproduces the problem. The xx directory and the\n>> .nfsNNNN file in it stay without warnings.\n>> The .nfsNNNN file is created by the NFS client when the xx/x file is\n>> removed.\n>\n>That is not the behavior I get. I see:\n>\n>  $ git clean -df .\n>  warning: failed to remove xx/.nfs0000000002c8197f00000002: Device or\n>resource busy\n>\n>Which makes sense, since the kernel fails our unlink() call. Maybe your system\n>behaves differently at the syscall level?\n>\n>This is a pretty standard Debian system with kernel 6.8.12. I set up the NFS mount\n>with:\n>\n>   mkdir /mnt/{server,client}\n>   exportfs -o rw,sync 127.0.0.1:/mnt/server\n>   mount -t nfs 127.0.0.1:/mnt/server /mnt/client\n>\n>and then made the repository in /mnt/client. \"mount\" tells me it's using nfs4.\n>\n>Running \"git clean\" on the server side does remove the files (no warning, but the\n>directories are actually removed).\n\nIt 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. \n\n"},{"id":"496936","messageId":"c98ac093-73a8-45eb-a82a-5274606de336@rawbw.com","threadId":"61618","inReplyTo":"102101dabc06$16dfead0$449fc070$@nexbridge.com","subject":"Re: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"'Yuri'","fromEmail":"yuri@rawbw.com","sentAt":"2024-06-11T17:46:27Z","receivedAt":"2024-06-11T17:46:34Z","isPatch":false,"sender":{"key":"yuri@rawbw.com","avatar":null},"body":"On 6/11/24 06:48, rsbecker@nexbridge.com wrote:\n> It has been a while since I did a self-mount in NFS, but I do not \n> think that will reproduce the issue. The mounts have to be on \n> different servers from the client to experience this silly rename \n> situation. On self-mount, IIRC, the client is aware that it is on its \n> own machine and will not try to detect the situation. \n\n\nYou can use a VirtualBox VM.\n\n\n\nYuri\n\n"},{"id":"497078","messageId":"ZmqpQ4FkfXRm2jAE@lan","threadId":"61618","inReplyTo":"ed33cfa9-d0e2-4e98-95e9-e210b24ac337@rawbw.com","subject":"Re: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"Gabor Gombas","fromEmail":"gombasg@digikabel.hu","sentAt":"2024-06-13T08:09:39Z","receivedAt":"2024-06-13T08:40:03Z","isPatch":false,"sender":{"key":"gombasg@digikabel.hu","avatar":null},"body":"On Tue, Jun 11, 2024 at 12:43:51AM -0700, 'Yuri' wrote:\n> The system I observed the problem is Centos with the kernel\n> 3.10.0-1160.76.1.el7.x86_64 (10 years old).\n> \n> \n> \"rm -rf xx\" command also says Device or resource busy\n> But git-2.43.0 doesn't say anything.\n\nOn RHEL7:\n\n$ mkdir foo\n$ cd foo\n$ git --version\ngit version 2.39.2\n$ git init\n$ mkdir xx\n$ touch xx/x\n$ tail -f xx/x\n$ git clean -dfx\nwarning: failed to remove xx/: Directory not empty\nRemovig xx/x\n$ git clean -dfx\nwarning: failed to remove xx/.nfs[... long hex number...]: Device or resource busy\n\nWell, try something:\n\n$ echo xx > .gitignore\n$ git add .gitignore\n$ git commit -m foo\n$ git clean -df\n[there is no output - bingo]\n$ git clean -dfx\nwarning: failed to remove xx/.nfs[... long hex number...]: Device or resource busy\n\nRegards,\nGabor\n"},{"id":"497081","messageId":"7fb83cd9-5a15-41d8-b047-c69e9026e4b2@rawbw.com","threadId":"61618","inReplyTo":"ZmqpQ4FkfXRm2jAE@lan","subject":"Re: [BUG] \"git clean -df .\" silently doesn't delete folders with stale .nfs* files","fromName":"'Yuri'","fromEmail":"yuri@rawbw.com","sentAt":"2024-06-13T09:21:18Z","receivedAt":"2024-06-13T09:21:30Z","isPatch":false,"sender":{"key":"yuri@rawbw.com","avatar":null},"body":"On 6/13/24 01:09, Gabor Gombas wrote:\n> $ git clean -df [there is no output - bingo] $ git clean -dfx warning: \n> failed to remove xx/.nfs[... long hex number...]: Device or resource busy\n\n\n'git -dfx' does warn about the .nfsNNN files.\n\nIt turns out that my git repository has .nfs* files in the ignore list.\n\nSo it silently keeps these files with the -df flags.\n\n\n\n\nYuri\n\n"}]}