From: "brian m. carlson" <email@example.com>
To: Junio C Hamano <firstname.lastname@example.org>
Cc: Mark Amery <email@example.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: Bug: Changing folder case with `git mv` crashes on case-insensitive file system
Date: Tue, 4 May 2021 11:20:38 +0000 [thread overview]
Message-ID: <YJEuBqVVa/7x+jrZ@camp.crustytoothpaste.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 1922 bytes --]
On 2021-05-04 at 03:46:12, Junio C Hamano wrote:
> "brian m. carlson" <firstname.lastname@example.org> writes:
> > Yeah, this is because your operating system returns EINVAL in this case.
> > POSIX specifies EINVAL when you're trying to make a directory a
> > subdirectory of itself. Which, I mean, I guess is a valid
> > interpretation here, but it of course makes renaming the path needlessly
> > difficult.
> > ...
> > I suspect part of the problem here is two fold: on macOS we can't
> > distinguish an attempt to rename the path due to it folding or
> > canonicalizing to the same thing from a real attempt to move an actual
> > directory into itself. The latter would be a problem we'd want to
> > report, and the former is not. Unfortunately, detecting this is
> > difficult because that means we'd have to implement the macOS
> > canonicalization algorithm in Git and we don't want to do that.
> I agree we'd probably need to resort to macOS specific hack (like we
> have NFS or Coda specific hacks), but it may not be too bad.
> After seeing EINVAL, we can lstat src 'foo' and dst 'FOO', and
> realize that both are directories and have the same st_dev/st_ino,
> which should be fairly straightforward, no?
> For that, we do not exactly have to depend on any part of macOS-ism;
> we do depend on the traditional "within the same device, inum is a
> good way to tell if two filesystem entities are the same".
Yes, although that won't work on Windows, which I don't believe has the
concept of inodes and almost certainly has the same problem. CCing
Dscho in case he has some ideas on how we can make this more resilient
In any event, I'm not planning on writing a patch for this since I have
no way to test it, but I'm sure someone who uses macOS could probably
write one reasonably easily.
brian m. carlson (he/him or they/them)
Houston, Texas, US
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2021-05-04 11:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-03 17:25 Bug: Changing folder case with `git mv` crashes on case-insensitive file system Mark Amery
2021-05-03 22:58 ` brian m. carlson
2021-05-04 3:46 ` Junio C Hamano
2021-05-04 11:20 ` brian m. carlson [this message]
2021-05-05 13:51 ` Johannes Schindelin
2021-05-06 0:38 ` Junio C Hamano
2021-05-04 15:19 ` Torsten Bögershausen
2021-05-05 0:23 ` Junio C Hamano
2021-05-05 2:12 ` brian m. carlson
2021-05-06 4:34 ` Torsten Bögershausen
2021-05-06 9:12 ` Mark Amery
2021-05-06 13:11 ` Bagas Sanjaya
2021-05-06 14:53 ` Torsten Bögershausen
2021-05-06 21:03 ` Junio C Hamano
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).