Filesystem Paths: How Long is Too Long?

The programmer in me hopes they ignore the 1% that actually care about this and at least there are some heavy API restrictions to stop them doing it. Even on linux which can handle longer pathnames runs into the restriction that you can’t transfer those long pathnames onto anything with FAT32 (so like most USB drives). Last time I saw when someone tried to copy one of those stupid linux deep directory projects onto a FAT32 it just cut all the names off and trashed the drive, I assume it’s been patched to at least just warn it can’t do the transfer now.

It seems to escape peoples grasp that the longer you make the filenames the slower disk access becomes just based on having to parse thru the stupidly long strings on trying to find and open a file. So the change for 1% that actually want this affects the 99% that never want it or use it.

I think a realistic alternative that people who want to do this rubbish is make a cabinet structure that they mount and use. If you don’t know what that means it’s like how you can open and go inside zip files like they are a normal disk drive and the same with ISO files. The cabinet would have the long names and an API that supported those long names and you don’t effect everyone else. Really all your long directory junk is just in a file that fits on a normal drive. It isn’t like your going to be able to copy of move that directory structure anywhere else anyhow if you don’t do it in that format. So I have solved two problems allow you to have the stupidly deep and long filesname you want and you can move your data onto a normal external USB drive for backup as it looks just like a single file.

1 Like

Perhaps, but 256 is clearly too short of a limit and based on old DOS values not any rational modern value. Something like 1024 is at least a reasonable modern starting point.

Especially since something like this is used by Microsoft long_ass_name_and.{xxxx-xxxx-xxxx-xxxx}

I’m trying to copy a file with no extension (perfc) to the windows folder on remote PCs. I’m using a robocopy command that works fine in other deployment packages, but with this one I get the following error in the log:

Result: Deployment ended: The directory cannot be removed. Stop(Failure). Credential: (halquist\perryh). ShareCredential: (lansweep). Command: robocopy \server\Installers\perfc C:\Windows

I’m not sure if the problem is that there is no extension or a permissions issue writing to the Windows folder. I’ve tried installing with both ‘scanning credentials’ which is an admin account, and with ‘Currently Logged In’ and get the same results.