GF has been running Windows under Parallels on a Mac Mini, we’re transitioning her to a Boot Camp partition to run Windows w/o it being a process within MacOS (some incompatibilities, long story).
Somehow she seems to have placed a file or two within a subfolder of a subfolder of a subfolder etc/etc/etc/etc/etc/etc/… so deep that XP, although it displays a file icon with file name etc, won’t open it or copy it, and MacOS X says it “does not have permission to copy it” and will not display them as being in existence. (In list view, hitting the disclosure triangle makes a momentary glimpse of a file occur then it pops back up to show nothing in the problematic folder).
Umm, I assume it’s the “deeply buried” aspect that the two such files I’ve run across have in common. The file names themselves don’t look worrisome. Right-clicking file in XP shows a reduced set of right-click options; the “Open With” menu is empty (they are WORD documents for pete’s sake) and picking it causes Conversions Plus window to pop up saying the document format is unknown.
Does XP let you drag and drop valid folders into other folder and so on, thus allowing you to bury files WITHIN those folders too deep for the OS and/or the disk formatting scheme (NTFS for what it’s worth) to “understand” the file location?
Any way to rescue these suckers?
I’m not sure offhand, but I suspect it’s not the NTFS formatting that’s going wrong, but possibly some of the OS commands involved in explorer.exe that only have a limited amount of space for ‘full path of file involved’ and are failing to run.
First rescue strategy would be attempting the reverse of your conjecture for how they got buried so deeply - go down the folder tree about halfway, and ‘move’ one of the containing folders up to a location more proximate to the drive root. That should reduce the necessary pathnames to reach the deep files and obviate the problem.
Incidentally, windows doesn’t need to access the full pathname of every file in every subfolder in order to move a folder as I understand it - a folder is just a special type of file on the disk, which happens to contain the names and FAT information for its member files.
Go to a folder a few levels above the affected files, right click and select Sharing…
Tick to say “Share this folder” and set a name. Click OK.
Next open Explorer and type \localhost<share name>
This will give you a new view on the files and the path will have shortened (now \localhost\share\folder\file1 instead of c:\blah\blah\blah\blah\blah\blah\blah\blah\blah\blah\blah\blah\ and so on).
You should be able to copy it to where you want now.
I’m pretty sure, however, that the limitation is on the length (in characters) of the “full path” [that is, “C:\folder1\folder1\folder3…\file”] to the file, rather than the “depth.” So Another possibility – if there are any longish folder names along the way – is to rename those folders to something significantly shorter.
IIRC the full path length is limited to either 256 or 512, not sure.
Not to suggest a solution you’ve already tried, but why don’t you just grab one of the sub-folders and move it up a few branches up the tree and shorten the file path considerably.
There used to be a maximum path length in Windows of 260 chars. That’s long gone, and it’s now 32k characters max. But there’s still quite a bit of software (including Explorer!) that can’t handle very long paths.
I ran into a similar problem when archiving directory trees from other computers, some of which contained directory trees archived from other computers. The total path length (>256) was too long for many programs.