Re: Probably a bug with "~" symbol in filenames on Windows 7 x64 in git 1.9.5
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jan 8, 2015, 10:06 UTC
- Message-ID
- <alpine.DEB.1.00.1501081100570.21312@s15462909.onlinehome-server.info>
- In-Reply-To
- <CAPc5daVddkaMkx=43nCeQKbbkrV6nExOqvEBJNyugzDQB2n6kQ@mail.gmail.com>
Hi Junio,
On Wed, 7 Jan 2015, Junio C Hamano wrote:
> Dscho, this sounds to me like the additional "8.3 ambiguity > protection" (which is only in Git for Windows) in action. Any > thoughts?
First thought: the Git for Windows mailing list should be Cc:ed (I was traveling yesterday and somebody else might have been able to address Dmitry's problem).
Second thought below:
Show 7 quoted lines
> On Wed, Jan 7, 2015 at 3:26 PM, Dmitry Bykov <pvrt74@gmail.com> wrote: > > > > Recently I installed 1.9.5 git version and faced the problem that one > > of the files in my cloned repository with a name ICON~714.PNG is > > marked as deleted even repository was freshly cloned. Trying to do > > anything with that file resulted in constant "Invalid Path" errors. > > Reverting back to 1.9.4. fixed that problem.
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 ;-))
Ciao, Johannes