What are 7zip's limits on
- number/lengths of paths
Mark's Blog : The Case of the Failed File Copy
ACCESSED: Mon Jul 06 2009 22:54:24 GMT-0400 (EDT)
PAGE URL: http://blogs.technet.com/markrussinovich/archive/2007/10/01/2087460.aspx#comments
# re: The Case of the Failed File Copy
The path-length problem is completely unrelated to the FAT limitation.
NTFS can actually support pathnames up to 32,000 characters in length.
Microsoft's tools, on the other hand (explorer.exe, dir, etc.) are coded to the ANSI spec for writing paths, so they crap-out at 260 characters. I'm not even sure if that failure will show up in Filemon. I think the call craps out before it even gets down to the filter driver.
Anyway, there's a few tools you can get to work around the 260 character limit that has been with us since 1994. Delimon, Win32Explorer, and about the ONLY tool that is capable of archiving or zipping long paths is the "jar.exe" that ships with Sun's Java SDK. (other tools like winzip will fail, sometimes reporting an error, sometimes silently skipping long path items, cabarc.exe actually crashes when it encounters long paths).
It was disappointing when Microsoft decided that the 260 character path limitation wasn't important enough to fix in Windows 2000. Frustrating when they kiboshed it for XP. Maddening when they left it alone for Server 2003. But, when they decided to work around the problem by including a Database File System in Longhorn, well, I guess that was semi-acceptable, until they yanked that feature from Vista, and now Vista suffers from this same NTFS limitation left over from 1994.
(those of us with serious OS needs, switched to Macintosh or Linux - but still make a living supporting people dumb enough to use toy OSes).
Keep fighting the good fight Mark!
yes, this is a real issue for me, been a problem for years and delimon is the only lib that does the job properly even if some of the functions dont work properly e.g. directory.create. What makes me laugh is that Microsoft's own software e.g. Visual studio (projects) will create paths in excess of the 260 char limitation so they have the problem too. unfortunatly to get this to work outside of .Net you have no choice but to use the API and use the wide versions of the API calls. This is a poor show for Microsoft, they keep on promising that it will be fixed but nothing ever happens.....
On a side note, 7-zip does work with long paths and file names as long as you use list files rather than direct command line, don't know about the gui. I found that using list files and storing the full paths in the archive worked properly.
- NTFS can actually support pathnames up to 32,000 characters in length.
7-zip also support such long names.
But it's disabled in SFX code. Some users don't like long paths, since they don't understand how to work with them. That is why I have disabled it in SFX code.
I agree that NTFS supports the long paths/file names, but it is not the default, the default is ANSI, for you to support 32,000 you have had to use the CreateFileW rather than CreateFileA in your code. Then the command line does not support long commands so without the use of list files you cannot specify a long pathed file from the command line, this is not a limitation of 7-zip but an OS limitation....
Could you please tell me in detail how you are able to store the full paths in the archive? (With or without drive letter...) Currently I am running the following from a command prompt:
7z.exe a -tzip C:\test.zip @"C:\list.txt"
list.txt contains the following:
When looking in the archive, all the files are there, but the paths for the files are either 'Documents' or 'Code' (instead of 'Files\Backup\Documents' or 'Backup\Code'). I am looking to have the full original path stored.
Any help would be appreciated!
You can use Long Path Tool to overcome this problem.
We have a similar problem. Is it possible, to disable the support for the long pathes in 7-zip?
We disabled for performance reasons the 8dot3 name creation on the W2k12 filserver (from user perspective it is a network share). Due the Microsoft limitations, it is not possible from explorer, Word, etc. to use the long pathes (supported by NTFS). But one Problem exist. Users extract archives with 7-zip in a subdirectory and with the pathes from archive, the resulting path is longer than 260 chars ... Can I disable the long path support on 7-zip, so that the user gets a error message like "Path longer then 260 chars, please select a other root"? (or similar)?
There is no such feature now.
is it possible, to add such a feature?
The hack, that Microsoft is running to support longer names for its incompatible Applications is, to enable 8do3 feature. If it is enabled, the NTFS creates for each component in a path which is longer than 8.3 a short name like longna~1, longna~2, etc an add them additional to real long name to the ntfs database. That is annoying and makes the databases a lot larger and slower. By default 8dot3 feature is disabled on w2k12 servers.
We don't use 8dot3, because we like to have a clean NTFS database for future ... If the user uses "normal Applications", he get an error message if the path is too long.
But 7-zip does not have such warning and after unpack a archive, it can happen that the user can't access the unzipped files, because the resulting path exceeds the 260 chars that Microsoft applications support.
PS: I've seen, that for example bandizip supports such a option: https://www.bandisoft.com/bandizip/help/longpath/
NTFS itself is "clean" and allows up to 32'767 characters, so does each Windows kernel. I wonder when Microsoft products will ever "fix" their 260 character legacy limitation (and add regular expression support in searches). There should be other file managers out there which are able to handle "long" paths and filenames.
And no: 8.3 names are also created when the original name has more than 3 characters after the dot, so "1.text" will get "12944~1.TEX" (which effectively is longer).
recent win10 builds support long filenames for usual win apps, you just need to set up key in registry
Thanks for that hint, but we use 7-zip in a lager native Windows 7 environment. Migration to Win 10 maybe takes until end of 2019, so that is no solution for us!
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.