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
release.
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.
HTH
Greg
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