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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:

> On Wed, Jan 7, 2015 at 3:26 PM, Dmitry Bykov <pvrt74@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]