rdiff-backup-users
[Top][All Lists]
Advanced

[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: Tue, 28 Oct 2008 09:21:13 -0400

Ryan,

Good theory, but it does not always work in practice.

If you run a file server and you share D:\home\John.Doe as a private
share, then John Doe gets 255 chars + strlen("\home\John.Doe") to work
with from his local workstation.

So to backup a windows file server properly, you basically have to
address the 255 char issue.

Greg

On Mon, Oct 27, 2008 at 7:40 PM, Ryan How <address@hidden> wrote:
> Thanks for your input.
>
> It all makes a lot of sense.
>
> So, seems it would save more headaches to just not use long file paths :)
>
> Ryan
>
>
> Greg Freemyer wrote:
>>
>> 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
>>>
>>
>>
>>
>
>
> _______________________________________________
> 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
http://www.linkedin.com/in/gregfreemyer
First 99 Days Litigation White Paper -
http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com




reply via email to

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