Thank you for your explanations. I don't think "git clean" must necessarily mirror the behavior of the underlying filesystem and must be free of any options that implement a different behavior. What is the purpose of "git clean"? Broadly, it's "Perform a mass delete of untracked (or, with -X, ignored) files to put my repository back to a clean state". I would argue that paying too much respect to the permission bits within untracked directories that we're planning to delete anyway goes against this purpose. Consider: why pay such respect? If the answer is "to protect the user from accidental deletions", we already have interactive and dry run modes to do that, and at a logical level, one might expect a read-only file to also be protected. (For example, "rm" will prompt for confirmation before deleting a read-only file, though "rm -f" will not.) If the answer is "because that's how UNIX file systems works", then I'd wonder why we should be a slave to that. (If the unlink syscall returns EPERM or whatever, you can check if the permissions on the parent directory may be the cause and then change them and retry if 'git clean' would be deleting the parent anyway.) In short, when a user says to go ahead with the mass delete, and especially when they say to "force it", why not do so? -----Original Message----- From: Junio C Hamano <gitster@xxxxxxxxx> Sent: Thursday, February 20, 2020 10:48 AM To: Adam Milazzo <Adam.Milazzo@xxxxxxxxxxxxx> Cc: git@xxxxxxxxxxxxxxx Subject: [EXTERNAL] Re: BUG: git clean -d cannot remove files from read-only directories Junio C Hamano <gitster@xxxxxxxxx> writes: > Adam Milazzo <Adam.Milazzo@xxxxxxxxxxxxx> writes: > >> 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. > > It is how UNIX-like filesystem works, isn't it? > > As long as a directory D is writable/executable, any regular file > inside it can be removed regardless of the perm-bits of the file. > > mkdir d > touch d/a > chmod -w d > rm d/a > > would not let you remove the file d/a from d/, exactly because you > cannot modify d/ (it is not writable). I realize that the above is probably a bit too terse for those who are not familiar with the UNIX/POSIX-like filesystems. A directory is a record of what files (and subdirectories) are in it. If you add a file to or remove a file from a directory, you are updating that record---so you need to be able to write to the directory. You do not have to be able to write (or even to read for that matter) to the file you are adding or removing to the directory, because adding or removing a file from a directory involves only updating the record kept in the directory about what files and subdirectories are in that directory (hence you need to be able to write to the directory---but perm bits on the files you are adding or removing do not play a role in this operation). A collorary is that modifying an existing file in a directory does not have to change what is recorded in the directory---what files are in the directory does not change. You only need to be able to write the file, so you can edit a file in a read-only directory. Note that some editors, however, implement an "edit" as "rename the original file as a backup, create a new copy of a file, and edit that new copy". With such an editor, you cannot "edit" a writable file in a read-only directory and the reason would by now be obvious to you once you understand the explanation above. Both renaming the original and creating the new copy would be updating what files are in the directory, requiring you to be able to write to the directory. Hope this helps.
