fast-import fails with case sensitive tags due to case insensitive lock files

fast-import fails with case sensitive tags due to case insensitive lock files

[Wendeborn, Jonathan]

Hi,

I have a problem with fast-import on an NTFS drive: If I try to import tags which are identical apart from their casing a failure due to identical lock file names occurs.

I am running git for windows 2.15.1.2 x64 on a Windows 10 machine (10.0.15063):
$ git --version --build-options
git version 2.15.1.windows.2
built from commit: 5d5baf91824ec7750b103c8b7c4827ffac202feb
sizeof-long: 4
machine: x86_64

MCVE:
 (echo "commit refs/heads/master" && 
 echo "mark :1" &&
 echo "committer me <> 0 +0000" &&
 echo "data 0" &&
 echo "" &&
 echo "tag tag_A" &&
 echo "from :1" &&
 echo "tagger me <> 0 +0000" &&
 echo "data 0" &&
 echo "" &&
 echo "tag tag_a" &&
 echo "from :1" &&
 echo "tagger me <> 0 +0000" &&
 echo "data 0" &&
 echo "") | git fast-import

Instead of having 1 commit with two tags ("tag_A" and "tag_a") I get his error message:
Unpacking objects: 100% (4/4), done.
error: cannot lock ref 'refs/tags/tag_a': Unable to create 'C:/tmp/.git/refs/tags/tag_a.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

Best regards,
Jonathan

Re: fast-import fails with case sensitive tags due to case insensitive lock files

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]

On Fri, Mar 01, 2019 at 06:19:48AM +0000, Wendeborn, Jonathan wrote:
> Hi,
> 
> I have a problem with fast-import on an NTFS drive: If I try to import tags which are identical apart from their casing a failure due to identical lock file names occurs.
> 
> I am running git for windows 2.15.1.2 x64 on a Windows 10 machine (10.0.15063):
> $ git --version --build-options
> git version 2.15.1.windows.2
> built from commit: 5d5baf91824ec7750b103c8b7c4827ffac202feb
> sizeof-long: 4
> machine: x86_64
> 
> MCVE:
>  (echo "commit refs/heads/master" && 
>  echo "mark :1" &&
>  echo "committer me <> 0 +0000" &&
>  echo "data 0" &&
>  echo "" &&
>  echo "tag tag_A" &&
>  echo "from :1" &&
>  echo "tagger me <> 0 +0000" &&
>  echo "data 0" &&
>  echo "" &&
>  echo "tag tag_a" &&
>  echo "from :1" &&
>  echo "tagger me <> 0 +0000" &&
>  echo "data 0" &&
>  echo "") | git fast-import
> 
> Instead of having 1 commit with two tags ("tag_A" and "tag_a") I get his error message:
> Unpacking objects: 100% (4/4), done.
> error: cannot lock ref 'refs/tags/tag_a': Unable to create 'C:/tmp/.git/refs/tags/tag_a.lock': File exists.

The reason you're seeing this error is because refs can be stored in the
file system. In order to update a reference, Git takes a lock on it, and
as you've seen, Git can't take a lock on the same reference twice.

It's known that multiple references that differ only in case can't be
stored in a case-insensitive file system, and there is a design for a
different system (reftable) which nobody has yet implemented in Git but
does not have this problem.

Even if we accepted this situation in fast-import, we'd destroy one of
your tags, which would be undesirable.

Sometimes this happens to work because when we pack references, we store
them in a file instead, which does not suffer from case-sensitivity
problems.

Right now, you have some choices:

• Volunteer to implement reftable.
• Since you're on Windows 10, set your Git repository directory as
  case-sensitive.
• Use Windows Subsystem for Linux, which is case sensitive and creates
  directories with that flag (even on NTFS), to do your import.
• If you control the fast-export output, adjust the arguments you pass
  such that the output does not contain one of the offending tags.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

AW: fast-import fails with case sensitive tags due to case insensitive lock files

[Wendeborn, Jonathan]

> Right now, you have some choices: 
> • Volunteer to implement reftable. 
> • Since you're on Windows 10, set your Git repository directory as 
>   case-sensitive. 
> • Use Windows Subsystem for Linux, which is case sensitive and creates 
>   directories with that flag (even on NTFS), to do your import. 
> • If you control the fast-export output, adjust the arguments you pass 
>   such that the output does not contain one of the offending tags. 

Hi Brian,

Thank you very much for your answer!

Unfortunately I am stuck with Windows 10 1703 which neither supports case-sensitivity nor any Linux subsystem from the Microsoft Store :( Also, my employer unfortunately doesn’t allow me to invest the time to implement reftable, so I guess I go with manually leaving out the one conflicting label I found and tagging it manually afterward.

One thing I still would like to encourage to is to improve the error message which is really misleading in this case.

Best regards and thanks again,
Jonathan

Re: AW: fast-import fails with case sensitive tags due to case insensitive lock files

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

Hi Jonathan,

On Mon, 4 Mar 2019, Wendeborn, Jonathan wrote:

> > Right now, you have some choices: 
> > • Volunteer to implement reftable. 
> > • Since you're on Windows 10, set your Git repository directory as 
> >   case-sensitive. 
> > • Use Windows Subsystem for Linux, which is case sensitive and creates 
> >   directories with that flag (even on NTFS), to do your import. 
> > • If you control the fast-export output, adjust the arguments you pass 
> >   such that the output does not contain one of the offending tags. 
> 
> Hi Brian,
> 
> Thank you very much for your answer!
> 
> Unfortunately I am stuck with Windows 10 1703 which neither supports
> case-sensitivity nor any Linux subsystem from the Microsoft Store :(

Too bad.

> Also, my employer unfortunately doesn’t allow me to invest the time to
> implement reftable,

Even worse!

> so I guess I go with manually leaving out the one conflicting label I
> found and tagging it manually afterward.

That is a valid workaround.

> One thing I still would like to encourage to is to improve the error
> message which is really misleading in this case.

Well, that is at least something you could do. After all, you use a
volunteer-driven project, so you could at least volunteer a little time to
improving it yourself.

Ciao,
Johannes

AW: AW: fast-import fails with case sensitive tags due to case insensitive lock files

[Wendeborn, Jonathan]

Hi Johannes,

>> One thing I still would like to encourage to is to improve the error 
>> message which is really misleading in this case.

> Well, that is at least something you could do. After all, you use a volunteer-driven project, so you could at least volunteer a little time to improving it yourself.

That's true :)

Thank you!
Jonathan

-----Ursprüngliche Nachricht-----
Von: Johannes Schindelin <Johannes.Schindelin@gmx.de> 
Gesendet: Montag, 4. März 2019 16:29
An: Wendeborn, Jonathan <Jonathan.Wendeborn@bruker.com>
Cc: brian m. carlson <sandals@crustytoothpaste.net>; git@vger.kernel.org
Betreff: Re: AW: fast-import fails with case sensitive tags due to case insensitive lock files

Hi Jonathan,

On Mon, 4 Mar 2019, Wendeborn, Jonathan wrote:

> > Right now, you have some choices: 
> > • Volunteer to implement reftable. 
> > • Since you're on Windows 10, set your Git repository directory as
> >   case-sensitive. 
> > • Use Windows Subsystem for Linux, which is case sensitive and 
> > creates
> >   directories with that flag (even on NTFS), to do your import. 
> > • If you control the fast-export output, adjust the arguments you 
> > pass
> >   such that the output does not contain one of the offending tags. 
> 
> Hi Brian,
> 
> Thank you very much for your answer!
> 
> Unfortunately I am stuck with Windows 10 1703 which neither supports 
> case-sensitivity nor any Linux subsystem from the Microsoft Store :(

Too bad.

> Also, my employer unfortunately doesn’t allow me to invest the time to 
> implement reftable,

Even worse!

> so I guess I go with manually leaving out the one conflicting label I 
> found and tagging it manually afterward.

That is a valid workaround.

> One thing I still would like to encourage to is to improve the error 
> message which is really misleading in this case.

Well, that is at least something you could do. After all, you use a volunteer-driven project, so you could at least volunteer a little time to improving it yourself.

Ciao,
Johannes