Repository navigation
Long file names (length > 260) should have special prefix #24
Description
...what i hate about java developers - is their love for redundant prefixes in every subfolder.
I thought it might be due to TortoiseGIT, yet the console git did me the same.
I thought my T-Git log would remain in clipboard, silly me.
Okay, i was cloning https://github.com/xwiki/xwiki-platform into c:\XWiki.src\xwiki-platform
It downloaded the pack checked delta's and then started checking out.
It then spitted one error that it cannot create file.
It then continued and finally said it is 100% okay.
To me it seems very strange - at elast one error happened, at least one file was not checked out, yet git reports cloning success. Maybe it is right, dunno, but looks strange.
I looked manually and yes, there was some file and some folder missed,
And git.exe could do northing about that.
See http://pastebin.ca/2172286
The problem is those redundant pathnames are crossing 260 length boundary - see http://jsfiddle.net/eaukk/
To access longer pathnames one should use special prefix and Unicode-aware version of function.
See http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath
Activity
sschuberth commentedon Jul 18, 2012
For reference, we had a discussion about lifting the 260 character limit before on the mailing list:
http://thread.gmane.org/gmane.comp.version-control.msysgit/14572
the-Arioch commentedon Jul 19, 2012
subscribing my @work account
Thank You for reference.
Archiving pastebin and jsfiddle logs: http://permalink.gmane.org/gmane.comp.version-control.msysgit/16367
However, apart from file length itself - the exit status is strange. I'd re-quote:
As far as got it, on UNIX git has 4KB length limit.
Maybe some could create 3900-length local path in Linux and try to clone some repositories into it ?
Would git/UNIX act the same, failing to create files, yet claiming cloning was 100% successfull ?
kblees commentedon Jul 19, 2012
Git only supports working directories up to 1024 characters (see abspath.c:27). This is probably for good reason, I don't know (so that hitting the 4k boundary on Unix is impossible?).
Anyway, I can confirm that 'git clone' on Windows returns success even if some files could not be checked out correctly. This is probably worth fixing.
However, supporting long path names in general is pointless as long as Windows shells and applications don't support this. Quote from the MSDN article linked above: "The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface is not able to interpret properly."
See also this discussion: http://thread.gmane.org/gmane.comp.version-control.msysgit/16284
the-Arioch commentedon Jul 19, 2012
The MSDN quotation is more about names like "12345 " or " 12345"
I recall some of that caused problems in GUI.
I also have doubts about case-sensitive names. Whle the core supports it, i guess both GUi and CLI does not.
Isn't it too early to declare somethign useless if some programs do not support it ?
If developer needs it, he would find better program or push for bug fixing. But even if some obstaclle would be fatal to him - let it be obstacle in another program. As of now the showstopper is Git. Git can be pointed at and claimed obsolete. Not some other program. And Git can harder get replacement than filemanager.
kusma commentedon Jul 19, 2012
I don't think anyone actually declared it as useless, only warned about possible issues along the road if someone dares to go down this path.
This is one of those issues you don't simply request and magically get granted, though. Someone who cares about it needs to pick it up and work on it. Luckily for whoever does (if any), Karsten's work on unicode pathnames already did a lot of the heavy lifting needed.
the-Arioch commentedon Jul 19, 2012
Okay, cmd.exe does not work with it, so no cmd/bat scripts.
PowerShell fails too.
I tried Notepad++ and it crashed, made bugreport.
I launched empty N++ and did File|Open and... it was clever trick. Windows or N++ dunno, but they suddenly converted name to short DOS 8.3 names. So, converting path to 8.3 and leaving only file itself long might be a clever trick even for older applications :-)
Java.exe finally read such files, hopefully any Java program as well
kblees commentedon Jul 19, 2012
Have you already tried paths that exceed the 260 limit even with 8.3 names?
The problem is not Notepad++ (or any other editor / IDE, for that matter), it is Windows Explorer and the shell's common file open dialog that cannot handle long names. That means that practically all Windows programs that work with files are affected.
That beeing said, there are a few workarounds that you might try:
nitram509 commentedon Jul 19, 2012
+1 for this issue.
It seems, that the underlying "old" cygwin has some influence.
My test setup is Windows7 64bit "Git version 1.7.8-preview20111206".
I've created some source folders with a length of 260+ long path names.
"git add" shows the following error:
fatal: unable to stat 'Adobe InDesign CS6 Server SDK/tools/benchmark/BenchmarkChartsConsole/src/com/adobe/ids/benchmark/
samples/dce/source/suribachi/src/suribachi/api/vo/action/tools/benchmark/BenchmarkChartsConsole/src/BenchmarkChartsConso
le-app.xml': No such file or directory
Of course, this file exists but has a long path.
Additionally I've throwed in this command:
"find . | wc -L"
Pops up this error (and much more):
find: ./Adobe InDesign CS6 Server SDK/tools/benchmark/BenchmarkChartsConsole/src/com/adobe/ids/benchmark/samples/samplec
lient-java-soap/src/com/adobe/ids/samples/sampleclient-aspnet-soap/sampleclient-aspnet-vb-soap/Default.aspx.vb: File or
path name too long
Than I've checked the find command within cygwin (CYGWIN_NT-6.1-WOW64 momo 1.7.15(0.260/5/3) 2012-05-09 10:25 i686 Cygwin)
Again "find . | wc -L" ... no errors,
result : 299
So maybe just linking git against a newer cygwin should work?
the-Arioch commentedon Jul 23, 2012
@kblees Have you already tried paths that exceed the 260 limit even with 8.3 names?
I told you, "I launched empty N++ and did File|Open and... it was clever trick"
It was that very standard FileOpen dialog of Windows (of Windows 7 x64). Maybe earlier Windows would fail and commandline would surely failand many standalone apps might, yet Windows GUI itself is ready for it!
Also both N++ and Delphi XE2 IDe mananged to read the file by 8.3 names
And why would not ? 8.3 names are not shortcuts but valid names for Win32 subsystem. And if filesystem driver then convert it, the drivers level are not affected by MAX_PATH bottleneck.
Also command-line java.exe (as of JRE 7b05 x64) does access those files. What interesting is Java approach at dir traversal: log shows it opens each time from root to a subfolder, then to sub-sub-folder and so on, one by one. Hopefully that allows them to alleviate lack of relating paths in extended-length strings.
the-Arioch commentedon Jul 23, 2012
If having no other choice and hopefully support from Tortoise, would try.
Java proven working so hopefully that makes sense.
Also, since Java works, i might be able to get this with Eclipse's Jit. Attempt at cloning failed, but maybe attempt to check-out would succeed.
Not the option i can make on 3rd-party repo.
And i don't know a bit of java and its build/deploy infrastructure and conventions. I just hope it "just works" so i can have a chance at "hit-and-run" patching.
Dunno how it is implemented. In DOS it was just a redirector after user code before actual File IO API.
If that would be the same, it would change nothing.
Well, it really seems to work even wit hrelative paths.
C:\Users\burov>cd \fs160.src\xwiki-platform-core\xwiki-platform-classloader\xwik
i-platform-classloader-protocols\xwiki-platform-classloader-protocol-attachmentj
ar\src\main\java
C:\fs160.src\xwiki-platform-core\xwiki-platform-classloader\xwiki-platform-class
loader-protocols\xwiki-platform-classloader-protocol-attachmentjar\src\main\java
C:\fs160.src\xwiki-platform-core\xwiki-platform-classloader\xwiki-platform-class
loader-protocols\xwiki-platform-classloader-protocol-attachmentjar\src\main\java
C:\fs160.src\xwiki-platform-core\xwiki-platform-classloader\xwiki-platform-class
loader-protocols\xwiki-platform-classloader-protocol-attachmentjar\src\main\java
L:>"c:\Notepad++\notepad++.exe" org\xwiki\classloader\internal\protocol\attachm
entjar\AttachmentURLStreamHandler.java\need13more\over260now\DLL_Load_Test.dpr
L:>dir org\xwiki\classloader\internal\protocol\attachmentjar\AttachmentURLStrea
mHandler.java\need13more\over260now\DLL_Load_Test.dpr
Том в устройстве L не имеет метки.
Серийный номер тома: B2AB-1E7A
Содержимое папки L:\org\xwiki\classloader\internal\protocol\attachmentjar\Attac
hmentURLStreamHandler.java\need13more\over260now
06.07.2012 15:47 2 482 DLL_Load_Test.dpr
1 файлов 2 482 байт
0 папок 164 744 040 448 байт свободно
L:>type org\xwiki\classloader\internal\protocol\attachmentjar\AttachmentURLStre
amHandler.java\need13more\over260now\DLL_Load_Test.dpr
program DLL_Load_Test;
uses
Vcl.Forms,
..........
the-Arioch commentedon Aug 2, 2012
Was it fixed ? or should extra ticket be created to make it not forgotten ?
kusma commentedon Aug 2, 2012
Is it a bug specific to Git for Windows? If so, are you experiencing issue #43?
the-Arioch commentedon Aug 2, 2012
don't know, at least it was reproduced there above
404 #43
kusma commentedon Aug 2, 2012
msysgit/msysgit#43
the-Arioch commentedon Aug 2, 2012
yes, happens in my Git-1.7.11-preview20120710.exe
10 remaining items
the-Arioch commentedon May 24, 2013
the mentioned link claims "However, git.exe is not an MSYS binary, and does not link to the MSYS-runtime."
sschuberth commentedon May 25, 2013
Which is perfectly true as you can easily verify with a tool like Dependency Walker.
the-Arioch commentedon May 26, 2013
No, DepWalk can detect statically bound dynamically loaded RTLs, but one needs different tools to detect statically compiled RTL (lib, obj) or dynamically bound one (Win32 LoadLibrary call). However that is just nitpicking.
The point is that since GIT is not MSYS application, it looks very strange to close this bug just because some other unrelated program (MSYS) also has one. MSYS is MSYS and GIT is GIT.
sschuberth commentedon May 27, 2013
If git.exe was an MSYS binary it would link against msys-1.0.dll dynamically, which can be checked with Dependency Walker. No need to play the wise guy by mentioning irrelevant cases where Dependency Walker would not work. That's just not helpful.
Also, I think there is no need to lecture us what MSYS is and what not. We got the point that some users would like to see support for long paths, and in order to do so we would need to fix both git.exe and the MSYS tools it relies on. IMHO, a single ticket is enough to track this feature request, and I've chosen msysgit/msysgit#52 instead of this one as it has a clearer comment history and is not spammed by nitpicking / irrelevant comments.
Merge pull request #24 from gitter-badger/gitter-badge
Merge pull request #24 from gitter-badger/gitter-badge
Merge pull request #24 from gitter-badger/gitter-badge
Merge pull request #24 from gitter-badger/gitter-badge
Merge pull request #24 from gitter-badger/gitter-badge