XPost: uk.d-i-y

On 6/5/25 08:49, Jeff Gaines wrote:

Why does Windows let me save a file (Little Ships return to Ramsgate)
with a path three miles long then not let me do anything with it?

I spent a day de-bugging my file manager before twigging the problem :-(

<https://www.reddit.com/r/Windows10/comments/wgea76/why_are_my_file_names_not_allowing_up_to_260/>

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

Why does Windows let me save a file (Little Ships return to Ramsgate) with
a path three miles long then not let me do anything with it?

I spent a day de-bugging my file manager before twigging the problem :-(

--
Jeff Gaines Dorset UK
George Washington was a British subject until well after his 40th birthday. (Margaret Thatcher, speech at the White House 17 December 1979)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

Jeff Gaines wrote:

Why does Windows let me save a file (Little Ships return to Ramsgate)
with a path three miles long then not let me do anything with it?

I spent a day de-bugging my file manager before twigging the problem :-(

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

Actually it's 'only' an Explorer issue.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On 05/06/2025 08:49, Jeff Gaines wrote:

Why does Windows let me save a file (Little Ships return to Ramsgate)
with a path three miles long then not let me do anything with it?

I spent a day de-bugging my file manager before twigging the problem :-(

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On 05/06/2025 11:45, Abandoned Trolley wrote:

On 05/06/2025 08:49, Jeff Gaines wrote:

Why does Windows let me save a file (Little Ships return to Ramsgate)
with a path three miles long then not let me do anything with it?

I spent a day de-bugging my file manager before twigging the problem :-(

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

--
I was brought up to believe that you should never give offence if you
can avoid it; the new culture tells us you should always take offence if
you can. There are now experts in the art of taking offence, indeed
whole academic subjects, such as 'gender studies', devoted to it.

Sir Roger Scruton

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On 6/5/25 12:59, Abandoned Trolley wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On Thu, 5 Jun 2025 13:21:59 +0100
Pancho <Pancho.Jones@protonmail.com> wrote:

On 6/5/25 12:59, Abandoned Trolley wrote:

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.

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.

--
Joe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On 05/06/2025 13:21, Pancho wrote:

On 6/5/25 12:59, Abandoned Trolley wrote:

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 is dangerous to be right in matters on which the established
authorities are wrong.”

― Voltaire, The Age of Louis XIV

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On 05/06/2025 13:48, Joe wrote:

On Thu, 5 Jun 2025 13:21:59 +0100
Pancho <Pancho.Jones@protonmail.com> wrote:

On 6/5/25 12:59, Abandoned Trolley wrote:

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.

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

--
“The urge to save humanity is almost always only a false face for the
urge to rule it.”
– H. L. Mencken

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On 05/06/2025 17:55, Chris wrote:

Pancho <Pancho.Jones@protonmail.com> wrote:

On 6/5/25 12:59, Abandoned Trolley wrote:

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On Thu, 6/5/2025 3:49 AM, Jeff Gaines wrote:

Why does Windows let me save a file (Little Ships return to Ramsgate) with a path three miles long then not let me do anything with it?

I spent a day de-bugging my file manager before twigging the problem :-(

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.

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

"the maximum path on drive D is "D:\some 256-character path string<NUL>"

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.

https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file

"Do not end a file or directory name with a space or a period.
Although the underlying file system may support such names,
the Windows shell and user interface does not."

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On Thu, 6/5/2025 11:03 AM, The Natural Philosopher wrote:

On 05/06/2025 13:48, Joe wrote:

On Thu, 5 Jun 2025 13:21:59 +0100
Pancho <Pancho.Jones@protonmail.com> wrote:

On 6/5/25 12:59, Abandoned Trolley wrote:

  

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.

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On Thu, 6/5/2025 12:55 PM, Chris wrote:

Pancho <Pancho.Jones@protonmail.com> wrote:

On 6/5/25 12:59, Abandoned Trolley wrote:

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.

But not on "security grounds"?

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

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 tits"
cd big tits
The system cannot find the path specified.

cd big tits
...My Documents\big tits>

cd ..
rd "big tits"

If I wrote my own utility...

.\lameutil.exe big tits

the environment gets

argv[0] lameutil.exe
argv[1] big
argv[2] tits

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 tits"

argv[0] lameutil.exe
argv[1] big tits (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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On 06/06/2025 17:54, Paul wrote:

On Thu, 6/5/2025 3:49 AM, Jeff Gaines wrote:

Why does Windows let me save a file (Little Ships return to Ramsgate) with a path three miles long then not let me do anything with it?

I spent a day de-bugging my file manager before twigging the problem :-(

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.

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation

"the maximum path on drive D is "D:\some 256-character path string<NUL>"

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.

https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file

"Do not end a file or directory name with a space or a period.
Although the underlying file system may support such names,
the Windows shell and user interface does not."

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."

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On 06/06/2025 23:24, Paul wrote:

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.

It all works, arcane rules and all.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On Sat, 6/7/2025 3:08 AM, Chris wrote:

Fredxx <fredxx@spam.invalid> wrote:

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

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

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".

https://images.tips.net/S15/Figs/T12859F1.png

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: uk.d-i-y

On 05/06/2025 13:21, Pancho wrote:

On 6/5/25 12:59, Abandoned Trolley wrote:

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.

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

--
mailto : news {at} admac {dot} myzen {dot} co {dot} uk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)