Re: Git changes permissions on directories when deleting files.
- From
Chad Joan <chadjoan@gmail.com>
- Date
- Mar 1, 2011, 19:57 UTC
- Message-ID
- <AANLkTimCzBwsz4TV=jEGeSEScVtgwmGEiDWOomaeTgWD@mail.gmail.com>
- In-Reply-To
- <20110301194428.GD10082@sigill.intra.peff.net>
On Tue, Mar 1, 2011 at 2:44 PM, Jeff King <peff@peff.net> wrote:
Show 39 quoted lines
> On Tue, Mar 01, 2011 at 02:35:41PM -0500, Chad Joan wrote: > >> Something fairly interesting: >> >> $ mkdir foo >> $ mkdir foo/bar >> $ ls -dl foo/bar >> drwxr-x--x 1 cjoan cjoan 0 Mar 1 14:31 foo/bar >> $ ls -dl foo >> drwxr-x--x 1 cjoan cjoan 0 Mar 1 14:31 foo >> $ echo "test" > foo/bar/baz.txt >> $ echo "somestuff" > foo/bar/somefile.txt >> $ ls -dl foo/bar >> drwxr-x--x 1 cjoan cjoan 0 Mar 1 14:31 foo/bar >> $ ls -dl foo >> drwxr-x--x 1 cjoan cjoan 0 Mar 1 14:31 foo >> $ rmdir foo/bar >> rmdir: failed to remove `foo/bar': Directory not empty >> $ ls -dl foo/bar >> drw------- 1 cjoan cjoan 0 Mar 1 14:32 foo/bar >> $ ls -dl foo >> drwxr-x--x 1 cjoan cjoan 0 Mar 1 14:31 foo >> >> >> The rmdir fails of course, but it also changes the permissions. >> So I take it that git always runs an rmdir on the parent directory >> when it removes a file? Seems like it would be a sensible way to do >> it on a system without this behavior. > > Exactly. Rather than spend time figuring out if the directory is > removable (which would not be atomic, anyway), we just rmdir and ignore > the error condition. > > I would argue that your filesystem is broken. Even if we implemented a > workaround to opendir() and check for files, it would still have a race > condition that could cause this situation to occur. > > -Peff >
Ouch.
Would it work to do something like alias rmdir to a script or program that would call /bin/rmdir and then fix up the permissions?