Pathlimit over 255 characters

[Dizzy]

Hi All,

i am searching for a solution:

Some users store files in a specific manner.

They create a long path and save files in it. But - they don't want to navigate through the directories.

They are creating new mappings.

For expample: C:\this is a veeeeeeeeery long dic\year 2009\something else\and so on\foo.txt

Now they are mapping the last dir "and so on" and are creating more and more directories from this point ....

It didn't take long time, and the last file resides in a over 255 character long path.

No problem for the backup - but for the restore.

So my idea is: when it is possible to backup the files, the hole path information have to be stored somewhere - but where?

Maybe this is a point to get started for a script ...

Every idea is welcome!

Thanks

[KaFu]

What a coincidence ... just looked this up today too... this might work for you:

If StringLen($sFilename) > 259 Then
    If StringLeft($sFilename, 4) <> "\\?\" Then $sFilename = "\\?\" & $sFilename
EndIf

with $sFilename something like 'C:\this is a veeeeeeeeery long dic\year 2009\something else\and so on\foo.txt'.

Edit:

Oh, just realize that this is good for reading files but not writing ... A workaround might be to split long paths and then do temp. SUBST to a free drive-letter?

Edited January 27, 2009 by KaFu

[trancexx]

Hi All,

i am searching for a solution:

Some users store files in a specific manner.

They create a long path and save files in it. But - they don't want to navigate through the directories.

They are creating new mappings.

For expample: C:\this is a veeeeeeeeery long dic\year 2009\something else\and so on\foo.txt

Now they are mapping the last dir "and so on" and are creating more and more directories from this point ....

It didn't take long time, and the last file resides in a over 255 character long path.

No problem for the backup - but for the restore.

So my idea is: when it is possible to backup the files, the hole path information have to be stored somewhere - but where?

Maybe this is a point to get started for a script ...

Every idea is welcome!

Thanks

You cannot create file, directory with path+it over 259 characters.

I probably misunderstood you.

[KaFu]

You cannot create file, directory with path+it over 259 characters.

I probably misunderstood you.

Easy, some archive programs often have this kind of misbehavior (*doooh*). Just take a long path and subst it to a new drive, in that new drive than create a folder+file combo with a length of 240, then subst /d the drive and take a look at the org. location...

[Dizzy]

Here is a short example how you can made a bad directory structure.

Keep in mind, that you have to delete a few dirs on your X: drive

#include <GuiConstantsEx.au3>
#include <NetShare.au3>
#include <WindowsConstants.au3>
#Include <File.au3>

DIM $a, $i
DIM $sShareName = "Share-200-1"

For $i = 1 to 20
    $a = $a & "\" & "1234567890"
Next

DirCreate("c:" & $a)
_Net_Share_ShareAdd (@ComputerName, $sShareName, 0, "c:" & $a, "Share-200-1")
RunWait(@ComSpec & ' /c ' & 'net use X: \\' & @computername & '\' & $sShareName )

DirCreate("x:" & $a)
_FileWriteLog("x:" & $a & "\new_log_file.log","Info")

So it is possible to store files in a path greater than 255 characters - and they will be captured by backup-programs BUT the restore won't function.

I'm looking for a workaround

Ideas?

Edited January 27, 2009 by Dizzy

[Dizzy]

Yes - i know the workaround with "subst" but if you have xxx files in yyy directories this is a really work.

So - more ideas?

Thanks Dizzy

@KaFu: Can you explain this a little bit more?

If StringLen($sFilename) > 259 Then
    If StringLeft($sFilename, 4) <> "\\?\" Then $sFilename = "\\?\" & $sFilename
EndIf

Edited January 27, 2009 by Dizzy

[KaFu]

@KaFu: Can you explain this a little bit more?

If StringLen($sFilename) > 259 Then
    If StringLeft($sFilename, 4) <> "\\?\" Then $sFilename = "\\?\" & $sFilename
EndIf

Found this here:

http://help.lockergnome.com/vista/size-lim...opict38090.html

Tried it and it works for reading files , no more info, sorry.