Long Path Names leading to file access problems???

[OatMan]

Cursory research has left me frustrated.

NTFS volume on WinXP Pro
System has been stable and in good working order for three+ years with regular maintanence.

BACKGROUND:

My Lawyer brother keeps his files very well organized in his "my documents" directory.

He has grown a huge and deep tree of nested directories.
I am concerned that this is resulting in long path name issues.
He began getting various error windows when trying to open certain documents.
All such errors were for files with very long path names. I noticed no other common factors.
I was unable to even copy the files directly as it would give errors and deny access/copy.
I shortned the path names and succesfully copied and accessed all files.

My remedy to the situation was to remove the first several levels of the directory structure by taking his main directory out of "My documents" and placing it on the root.

I have also asked him to further shorten bath names by both renaming directories to be less desctiptive and much shorter and reorganizing the directory tree to be wider and shallower (Like me🙂

I also gave a cursory overview of the entire structure to make sure all the longest path name files would now work, which they did.

I left the original Directory in its original place untouched except to rename the directory as "Back up". Pending installation of a new back up solution.

He is now working exclusively from the directory copied to the root with shortened path names.

NOW MY CURRENT ISSUE

It now seems that the new directory is missing files.
He has confirmed that there are files in the original now "Back up" that do not exist in the new working copy of said directory.
This might make sense if there were still long path name issues at the time of copying I think. What I don't understand is why there were no error messages at the time of the directory copy???

Basically I'm not sure how to go about first remedying the situation; second varifying that all files have been found, coppied, and confirmed as working; and third managing the situation going forward.

So I once again beseech the AT community and humbly appologize that my skills are so far eroded that I must suck bandwith for so inane and simple an issue.

A great many thanks in advance.

 

[greylica]

The solution I found for this problem in Windows is here:
If the tree is too long , you cannot access the files, ( explorer limits your address character space ) so, you can go deep as four directories for sample and share them.
After this, you can simply access your machine in the network and map the share as a drive.
Mapping the share will make windows explorer to do not show a big tree in the adress Tab, and the deep areas can be accessed.
Normally, if you did backups or something, Windows get all of the data structures without any problems, and then you can decompress a backup onto any hard drive and access them with the only solution I've found to recover the files or access them to move to another tree structure not so deep.

This is common to happen where the MY Docs folder is shared and then the users create their own structure, but for explorer, it will be so deep that cannot be accessed by local machine.

 

[greylica]

You can try ( I did not tried ), to go to the Tools -> Fiolder Options . and set not to show a complete address in the explorer too. 🙂

 

[greylica]

Originally posted by: OatMan

NOW MY CURRENT ISSUE

It now seems that the new directory is missing files.
He has confirmed that there are files in the original now "Back up" that do not exist in the new working copy of said directory.
This might make sense if there were still long path name issues at the time of copying I think. What I don't understand is why there were no error messages at the time of the directory copy???

Basically I'm not sure how to go about first remedying the situation; second varifying that all files have been found, coppied, and confirmed as working; and third managing the situation going forward.

So I once again beseech the AT community and humbly appologize that my skills are so far eroded that I must suck bandwith for so inane and simple an issue.

A great many thanks in advance.

Studing better your problem I can also sai that is better to use the Windows Backup Tool than copy teh directory structures. The problems is that the Windows act like an Iso File System for copying files, but when you create or navigate trough an directiory with relative paths that do not show the entire name, the navigation will act normally. But when you move/copy The Iso restrictions of 8 subdirectories and 256 characters Long act in the folders too. Not a normal behavior and yes, you are right, no signals to advise you are doing something wrong for you directory structure.

It appears to be a problem not with the NTFS itself, but with the approach Explorer takes when managing the file system.

Simply Call it MORE ONE BUG FROM WINDOWS
I simply don know if when you are using Vista this behavior still occurs.

Another thing we allways waited from Microsoft and is so simple, and do not need an Win ZIp to do, is to secure a folder with a password, they never did that and we don't know why if it's so simple. And is far more simply to the end user to secure a folder with a password than secure file one by one like we have today.

 

[VirtualLarry]

There are a myriad of various little buglets when dealing with files, from extra-long pathnames, to "special character" issues, that affect copying, archiving with WinZip and WinRAR, etc. A royal PITA. Btw, did you know that "dotfiles", don't show up in the count of files that Explorer.exe does when you right-click a path and select "properties"? At least they didn't last time I checked. Perhaps this will be fixed with Vista.

My solution? Use XCOPY for file copies, using my special batch file, or use Norton Ghost 2003 for backup/imaging.
XCOPYALL batch file:

@ECHO OFF
IF "%windir%"=="" GOTO ERR_NO_DOS_BOX
XCOPY /S/E/V/C/I/H/R/K/Y %1 %2 %3 %4 %5 %6 %7 %8 %9
GOTO END
:ERR_NO_DOS_BOX
ECHO Error - XCOPYALL must be run inside a DOS box.
:END

This will copy all files, but if they are too long or have special characters, the special characters will get converted to underscores, and too-long filenames will either lose characters, or drop to the short filename. Errors in copying should be reported. XCOPYALL is automatically recursive too. Just specify the source path and the destination path on the cmd line.

 

[greylica]

This will copy all files, but if they are too long or have special characters, the special characters will get converted to underscores, and too-long filenames will either lose characters, or drop to the short filename.

This can be avoided when using windows backup tool. decompressing the backup will get all of the data structures, files and the directories intact. After this he can use a trick like I did, to share the 4th or 5th level folder and map it to access the path by a relative point. He can reorganize the data into a root directories again respecting the ISO Standards.

 

[jameswhite1979]

Might be worth suggesting a document management application for your bro many good free ones. Do not want to be messing with those deep folders and file names...

 

[Smilin]

Using xcopy, robocopy, or explorer you will be told if a file fails to copy.

If you are running into path limitations you can map a share somewhere into the directory structure as a workaround. Honestly though if you're running into path limitations you should revisit your folder structure as it's probably very innefficient to navigate.

Another cause of path too deep error messages is dropped network frames (if you are going across a network). I'm not sure if this applies to you or not.

Also, be sure NTFS is intact with a chkdsk.

If you need to verify after the copy there are three ways that come to mind:
simply get properties on the topmost folder you copied. The files, folders, and bytes should all add up on both sides. The second way is to use robocopy or xcopy with the verify option. The third way is ntbackup. It's quite nice for such things.

 

[OatMan]

Thanks a ton for all the suggestions. I've been trying to get my bro to develop the directory structure to no avail. At least I'm getting him to abandon descriptive folder names. Some are like full sentences!

I was concerned that folder properties would be unreliable in a long pathname circumstance. Is this not so?

Any suggestions for a free file management program? I'm not familiar, but I'll start looking into it.

Not a network situation and no volumes/directories are shared or mapped. I'll play with these suggested work arounds, and see...

Thanks again!

 

[Smilin]

you can use the workaround even in a non-network environment. Just map back to yourself.

Instead of C:\windows you can use \\machinename\admin$ for instance (poor example but you see what I mean).


I'm not sure what you mean by folder properties being unreliable?


Going forward the best thing you can do is remove the "full control" permission from non-admins. Use "change" permissions if you need to. The #1 cause of mass data moves failing is some monkey putting a deny permission or something on a folder buried deep in godknowswhere. Stop this from the start and things will be smooth. Again..ntbackup is the universal workaround for this.

Not sure about file managment programs really. Sequoiaview is about as far as I go.

Good luck!

 

[OatMan]

I'm not sure what you mean by folder properties being unreliable?

I'm not sure I do either. When I right click on a folder to get properties sometimes all the files in that folder and subfolders are included in the information given, sometimes they are NOT all included. Hence unreliable.

I can not easily deturmine if there is a long path/file name issue using the folder properties. IE compare the duplicate backup folder to the working folder to make sure everything was copied.

 

[OatMan]

Trying to create workaround as suggested by Smilin...

non-network environment.

"Just map back to yourself."

I have the \\machinename

then all that I have available is \Printers and Faxes
and \Scheduled tasks

How do I map back to a directory on the root of C:\ ???

Backups seem to be running fine via NTbackup to a firewire external drive.

I just want to make sure the long pathname problem is put to bed.

thnx

 

[wibambau]

With regards to a workaround, I've had some success using the SUBST dos command to get part of the path replaced with a new drive letter.

So say you have c:\Stuff\More Stuff

This would get that to drive V:

SUBST V: "C:\Stuff\More Stuff"

(To delete this substitution you would just enter SUBST V: /D)

I hope this helps.