[PATCH] Allow manipulating files with long names on Windows

Dan Villiom Podlaski Christiansen danchr at gmail.com
Tue Jan 25 11:40:12 CST 2011


On 25 Jan 2011, at 14:38, Jason Harris wrote:

>
> On Jan 25, 2011, at 10:17 PM, Sune Foldager wrote:
>
>> On 20-01-2011 18:02, Aaron Cohen wrote:
>>>
>>> Windows by default has a MAX_PATH of 260 characters. A while ago the
>>> "fncache" format was added which allows repositories on Windows to
>>> contain very long paths. At the time, a patch was proposed,
>>> "longpath.patch" which enabled handling of those files in the  
>>> working
>>> copy but it was tabled.
>>>
>>> From http://mercurial.selenic.com/bts/issue839, I infer that the
>>> reason for this is that many tools on Windows don't handle long file
>>> names gracefully. Time has passed though and more programs now work,
>>> including all Java programs.
>>
>> ...but excluding all Windows' built-in tools such as Explorer,  
>> cmd.exe, PowerShell.exe, compression and so on. In practice, I find  
>> it intolerable, as you need specialized tools for any work you need  
>> to do with files like these.
>>
>> If Microsoft would fix their damn tools, it would be a different  
>> story :)
>>
>>> + - cmd.exe has trouble manipulating long pathnames (del, move,  
>>> rename will all
>>> +    fail). Use powershell.
>>
>> In PowerShell:
>>
>> C:\ $ mkdir ('\lalalalalalalalalalalalalalalalalalala' * 20)
>> New-Item : The specified path, file name, or both are too long. The  
>> fully qualified file name must be less than 260 characters, and the  
>> dir
>> ectory name must be less than 248 characters.
>
> Just so everyone is aware on OSX which currently uses the HFS+ file  
> system, the file name components must be less than 255 characters  
> and the full path name must be less than 1024 characters.

Actually Mac OS X does support file names longer than 1024 characters.  
It does define MAX_PATH, though, and since many programs rely on it,  
they won't work with paths longer than it. For example, such  
directories cannot be opened in the Finder or deleted with it. The  
situation appears similar to Windows but with a higher maximum.

Attached below is a tarball which contains nested directories  
totalling more than 10,000 characters. It extracts fine. To delete it,  
I first used a line like this:

while test -d aaaaaaaaaaaaaaaaaaaa; do mv aaaaaaaaaaaaaaaaaaaa a && cd  
a; done

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: long.tar.bz2
Type: application/x-bzip2
Size: 7077 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110125/a3e4855b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110125/a3e4855b/attachment-0001.bin>


More information about the Mercurial-devel mailing list