Hi Adam, On Thu, Feb 20, 2020 at 7:27 PM Adam Milazzo <Adam.Milazzo@xxxxxxxxxxxxx> wrote: > > Repro steps: > 1. git init > 2. mkdir d > 3. touch d/a > 4. chmod -w d > 5. git clean -fd > > Actual result: > Git doesn't remove anything, saying "warning: failed to remove d/a". > > > Expected result: > Git should remove the subdirectory 'd' along with its contents. Note that git can remove a read-only file (touch b; chmod -w b; git clean -f) with no problem. this is not a limitation of Git, but of how Linux Filesystems work. When you delete a file, you do not modify the file, but you change the directory which contains the file. In other words, if you have a directory which is write protected (you do not have the write permission), you cannot add, remove, or rename files. You may however still modify the content existing files. Your repro will yield the same result when executed without Git, i.e. plain shell commands: $ mkdir d ; touch d/a ; chmod a-w d $ rm -rf d rm: cannot remove 'd/a': Permission denied If the write permission were removed before touching the file, this would already fail: $ mkdir d ; chmod a-w d $ touch d/a touch: cannot touch 'd/a': Permission denied In summary: this is expected and I doubt Git can do much in such a case. After all, the directory is marked as read-only, so why should Git be able to write it? :) > […] > > * It seems inconsistent for "git clean" to be able to remove read-only files but not files from read-only directories. Again, deleting a file will modify its containing directory, not the file itself. Making a file read-only does not protect it from being renamed or deleted, that's what directory permissions are for. - Daniel -- typed with http://neo-layout.org
