Re: Probably a bug with "~" symbol in filenames on Windows 7 x64 in git 1.9.5

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 8, 2015, 19:08 UTC
Message-ID: <xmqqegr5f5ts.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150108102815.GA4806@peff.net>

Jeff King <peff@peff.net> writes:

Show 14 quoted lines

> On Thu, Jan 08, 2015 at 11:06:18AM +0100, Johannes Schindelin wrote:
>
>> ICON~714.PNG is a valid short name for a long name (such as
>> 'icon.background.png') because it fits the shortening scheme (8.3 format,
>> the base name ends in ~<n>). As this can clash with a validly shortened
>> long name, Git for Windows refuses to check out such paths by default.
>> 
>> If you want the old -- unsafe -- behavior back, just set your
>> core.protectNTFS to false (this means that you agree that the incurred
>> problems are your own responsibility and cannot be blamed on anybody else
>> ;-))
>
> I wonder if it is worth having a "git-only" mode for core.protectNTFS.
> Turning it off entirely would make him susceptible to GIT~1 attacks.

Yes, I think having distinctions would make sense, but I am not sure if "git-only" vs "every questionable included" should be the classification.

To classify various funniness of paths by the extent of damage they may cause for Windows:

 - ".Git" and "GIT~1" would be the worst level;

 - "CON.c" and the like would be the next bad level; and

 - "ICON~714.PNG" would be in "to be avoided in an ideal world but
   as long as the project is comfortable with having it in, Git is
   in no position to complain" level.

that is just my knee-jerk reaction.

And if we were to go with just two level, I'd throw "CON.c" into the same level as ".Git"; they both are to break the host that checks out such paths. The former may break Git on the host, and the latter may break something that is not Git on the host, but they are not that different in that the end user on that host is harmed.

"8.3 ambiguity" does not directly harm individual hosts, but the reason to flag is primarily because such a path may make the project's contents unreliable (e.g. "icon1234234.png" may alias "ICON~714.PNG" on somebody's machine, causing confusion). The same reason should make us flag a tree object as suspect if it contains two paths that are the same case-insensitively (e.g. a tree that represents the "net/netfilter" part of the Linux kernel source would be flagged because it contains both "xt_tcpmss.c" and "xt_TCPMSS.c").

Let's call the former Harmful and the latter Questionable. "CON.c" is Harmful on Windows, while "net/netfilter" is Questionable on Windows. Orthogonal to this, we earlier discussed what to do in fsck and receive.fsckObjects. I think we want to be express different shades of grays between the two extremes:

 - A repository of a mono-culture project would want to flag
   Harmfuls and Questionables that apply to the project's intended
   platform as errors.  By definition, a mono-culture project would
   not care about paths that may only be Harmful on others'
   platforms.

 - A repository for a cross-platform project would want to flag
   paths that may be Harmful or Questionable on some platform, and
   does not care if these paths are Harmful or Questionable on the
   platform that happens to host the repository.  By definition, a
   cross-platform project wants to make sure everybody involved will
   not get hurt.