[Top][All Lists]

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

Re: [rdiff-backup-users] long file path support for windows

From: Greg Freemyer
Subject: Re: [rdiff-backup-users] long file path support for windows
Date: Mon, 27 Oct 2008 15:09:10 -0400

I have never used rdiff-backup from Windows, but I am a little
familiar with the long path issue.

History (as I understand it):

NTFS has supported long paths from day 1

Way back when (the 90's), the windows kernel only had one API for
accessing files.

That API was restricted to 255 chars (or so).

When Windows 2000 was released a new alternate Unicode API was
included.  With that API you can in theory access paths up to 32K.  So
in a sense Windows has supported long paths for a long time now, BUT
few if any applications used the new API for years after that original

In particular the 3 most fundamental tools for accessing files are:
Windows File Explorer, Open File Dialog Box, and the Command Prompt.
For Win2000/Win2003/XP all 3 use the original restricted file API.

When VISTA/Win2008 was released a new default File Explorer and Open
File Dialog Box were provided that uses the new API and thus you can
access long paths via them.

The Command Prompt still does NOT provide access to long paths.

Microsoft apparently still thinks creating files with long paths is a
bad idea, so the new file explorer will not let you do that, nor does
the Save As dialog box.


On Fri, Oct 24, 2008 at 10:34 PM, Ryan How <address@hidden> wrote:
> Hmmm... maybe this isn't a bug at all? I was just trying to create long path
> in explorer and it has a limit also (round about the 260 it would seem). I
> used the UNC path and I couldn't even navigate to the deepest level getting
> an error.
> I used the subst command to go beyond the path limit. When going back to the
> original path you simply can't access the files from explorer!
> I just tried it on vista too!. Doesn't work either!.
> It seems long paths on windows are stuffed anyway. If you create a file you
> can't access it anyway. (I know if rdiff-backup worked with long paths then
> it could access it, but I like the idea of manually being able to get to the
> backup files if needs be)
> So the rules would just be, don't backup to a folder which is too deep, and
> don't backup from a folder that goes too deep! (because the added
> rdiff-backup-data folder will add extra onto the path and cause the error)
> Ok... so... can we just change rdiff-backup to instead of crashing to print
> out a warning that the path is too long and skip the file? The error would
> be originating in os.makedirs ? So if we can try catch (does python have
> that?) any calls then skip the file.
> Thanks for listening to my thinking out loud.
> Ryan How wrote:
>> Hmm.. The current cygwin head has unicode and long file path support I
>> believe. I wonder about going down that path again until windows python
>> catches up...
>> According to http://bugs.python.org/issue542314 the long file path issue
>> is resolved in python 2.5 if using UNC paths ?
>> I'm gonna do some investigating :)
>>>> And I don't know about long file paths on Windows happening in the 1.2.x
>>>> branch.... I think you're going to need to wait for Python 3 and an
>>>> updated
>>>> WinPython with Unicode operations. :-/
>>> As a possible workaround, from the Windows CLI you can try to use
>>> subst to map a new drive letter into the middle of you longpath.
>>> ie.
>>> if you know you have long paths within "c:\documents and
>>> settings\administrator\documents" you should be able to do:
>>> subst x: "c:\documents and settings\administrator\documents"
>>> rdiff-backup x:
>>> And gain 40 or so chars.
>> _______________________________________________
>> rdiff-backup-users mailing list at address@hidden
>> http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
>> Wiki URL:
>> http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
>> __________ Information from ESET NOD32 Antivirus, version of virus
>> signature database 3553 (20081024) __________
>> The message was checked by ESET NOD32 Antivirus.
>> http://www.eset.com
> _______________________________________________
> rdiff-backup-users mailing list at address@hidden
> http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
> Wiki URL:
> http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

Greg Freemyer
Litigation Triage Solutions Specialist
First 99 Days Litigation White Paper -

The Norcross Group
The Intersection of Evidence & Technology

reply via email to

[Prev in Thread] Current Thread [Next in Thread]