Length of File Path

"It's always been like that, sir."

Actually it's 'only' an Explorer issue.

Interesting comment from BCProgramming

I interpret it to mean that there are multiple file APIs, some allow more than 260 byte filepath, some do not. Explorer only allows 260.

I've not checked, so take with a pinch of salt.

On secrurity grounds some unix variants do not like file names which include spaces

1. Windows is not a Unix variant
2. Ive not come across any unix or linux falavour that does not allow spaces in filenames

OK

I don't think he is contradicting you. Linux allows it, but we all know spaces in filenames are really annoying. So people advise against it.

People who run GUIs in Linux couldn't give a thingummy.

Its just that when using a command line shell its pretty complicated to type '\ ' for every space as in e.g.

The\ Sound\ Of\ Music.mp4 or even "The Sound Of Music.mp4"

So if you use the shell all the time, don't put spaces in.

But if you simply use a GUI file browser, who cares?

Just keep within the 255 byte filename length of EXT4...

It depends on whether you use a command line frequently. Both Windows and *nix require filenames with spaces to be quoted in a command, and that gets tedious after a while.

So don't use the command line

But not on "security grounds"?

It's just sloppy programming that some applications can't handle spaces.

I've come across applications where there's a Linus variant, where filenames with spaces fail in Windows.

At least with Windows you can put quote-marks around strings.

I suppose the issue is where you have a Trojan called "The.exe" that can be run inadvertently.

On an OS like Windows 7, the bug was likely left there.

File Explorer cannot delete a MAX_PATH file. There is one precise path length that causes a problem, and then File Explorer cannot move it or delete it. You could write a short PERL script, and if it handled the file, it could delete it.

On maybe a W10/W11, that was fixed. That specific path length no longer presented a challenge to File Explorer. It could handle 260 character paths.

And speaking in broad general terms, files which violate the rules for filename, extension, or path, they generally come from browsers. Even if the browser presents a file saving dialog, that might not be sufficient to guarantee that some trick is not played.

You would expect a browser to ignore such entreaties.

There is a feature called LongPathsEnabled (max ~32767?).

Office does not support LongPath. File Explorer does not support LongPath. The OS can have LongPath enabled. Applications can be LongPathAware. It is apparently possible to craft exploits that are more likely to be attempted when LongPaths are present.

The long and the short of that feature, is don't use it. In certain scanning scenarios, it can radically slow down the scan (junctions perhaps).

The default on a clean install, is for that to be disabled (gives 260).

The feature may have "existed" in the filesystem for a number of years, without any LongPathAware capability having been developed. The support at some point in Win10, is mere wallpaper, with the feature not really being supported in a practical way. I gather no one wants to change all the string definitions to handle paths that big :-) The behavior on Junctions would be egregiously bad. "Pitch the PC out the window" bad.

Bill Gates once said "640,000 characters is enough for anyone", and he was right. That's why War and Peace stopped at 640,000 characters :-) Some of the other things Bill Gates said, such as utterances about MAX_PATH, were likely only said to the bathroom mirror. "If only we could make paths that were ridiculously long."

Paul

This does not work, in Windows Powershell.

cd My Documents

This works in Windows Command Prompt (quotes not needed).

cd My Documents

For some things, they know that only one parameter is expected so the whole arg string is treated as a group.

If I were writing my own utility, each "word" would be a separate arg entry. Thus, my own utility writing projects, are more likely to have double quotes around the folder I'm after.

On Linux, you would also have to match the case of the characters.

cd "My Documents" # works cd "my documents" # not work

Paul

That's funny. They handle spaces just fine.

First your command is analyzed by the shell, before it is launched by the loader, and the ENV gets passed to the executable. The magic (...your program logic), happens after that.

In the shell, the details matter. For sure, you know that using the double quotes, your intentions are made apparent. For the lazy at heart though, you know that certain things have a different behavior.

cd this is a disaster

ChangeDir knows it has to gather the four arguments together and make a string with some number of space characters in it. (The experiment shows it is absorbing the entire thing as one chunk. Number of spaces matter!)

Let's try an experiment for fun, and see if any additional "magic" is involved. OK, so the number of spaces has to match the number of spaces in the spacey-name.

Command Prompt

md "big t*ts" cd big t*ts The system cannot find the path specified.

cd big t*ts ...My Documents\big t*ts>

cd .. rd "big t*ts"

If I wrote my own utility...

.\lameutil.exe big t*ts

the environment gets

argv[0] lameutil.exe argv[1] big argv[2] t*ts

The number of spaces is lost, unless I can access a copy of the shell string for analysis. Since "cd" is a built-in, in Command Prompt, the developer has different opportunities than the lameutil.exe does. Thus, for my utility, only quoting supports my intent. The "cd" built-in developer can just chomp the string and absorb "this is a disaster" as the intent.

Whereas when lameutil does it, and the shell passes the arguments to my program, I have to be aware of what the ENV will look like when it arrives.

.\lameutil.exe "big t*ts"

argv[0] lameutil.exe argv[1] big t*ts (at least the 12 characters are there, and some delimiter scheme)

and then if the utility is expecting a folder name for argv[1], it's getting one.

It all works, arcane rules and all.

Paul

It's a problem in industry. I've hit it a few times, with directory structures such as /server_name/project_group/projects/project_number/work_pack_number/process/deliverables/system_number/superseded/filename

One way around it is to drop into command prompt, use subst to create a drive letter pointing to /server_name/project_group/projects/project_number/work_pack_number/process and then delete drive_letter:/deliverables/system_number/superseded/filename in file explorer.

That's what I mean by sloppy programming.

You can in linux as well.

That's not a space in filenames issue, though.

Where arcane rules might include things like: pushd c:\program files( followed by 'Tab' on the same line, without pressing 'Enter'

Windows does not use the correct default, for displaying file extension.

In File Explorer is an "Options" thing, and in there you can select to turn on the display of Extensions, and "Apply" and "Apply To Folders", and that may improve your awareness of your surroundings, and whether you are about to execute some malware.

Untick "Hide extensions for known file types".

One reason I always used an underscore rather than a space.