Hacker News Reader

Comment by mholt | Hacker News Reader

I would just like to take this opportunity to complain about Windows file paths and especially parsing them in cross-platform software like a web server that joins request paths that always use / to Windows filepath roots that may or may not use \. I also hate that Windows paths are limited to 260 characters !?

Seriously, in Caddy, I have some of the most bizarre special code paths for Windows. For example: https://github.com/caddyserver/caddy/blob/c6eb186064091c79f4...

Can someone who understands and appreciates the way Windows does files please help me appreciate it too?

This article did not help me have gratitude for Windows: https://www.fileside.app/blog/2023-03-17_windows-file-paths/

> we realise that we can construct an almost unlimited number of different path strings that all refer to the same directory.

View on HN

Coding with file system paths means accepting just a few difficult facts.

- a path is not a unique identifier of a file system object. They don’t have canonical names.

- don’t make any assumptions about case sensitivity, what file names are valid, or what the longest possible path is.

- avoid baking paths from strings as as much as possible. Use constructs like PathBuf (Rust) that prevent footguns like duplicated or incorrect dir separators. Never use a literal path separator char ‘/‘ or ‘\’ in code is a good rule of thumb.

I remember one article about someone porting code from *nix to windows and having almost no issue due to the author leveraging pathlib. Just a side note.

Same applies to C#. The standard library has pretty good APIs for dealing with file names and paths.

In my experience, a program written in modern .NET 5+ and tested on Windows has a high probability to run flawlessly on Linux, without even a recompilation.

The high level Win32 API does this to be helpful because a trailing space is usually not what the user wants. You can argue it's stupid if you want, but the OS supports files that end with dots and spaces just fine if you call the right APIs.

I guess Go hooks into too high level of an API. But you can prefix all your paths with "\\?\" to "force it" to be evaluated as is.

Consider the following program:

    package main
    import "os"
    func main() {
       os.Mkdir(os.Args[1], 0777)
    }

Invoking test.exe c:\test... will create c:\test Invoking test.exe \\?\c:\test... will create c:\test...

See: https://learn.microsoft.com/en-ca/windows/win32/fileio/namin...

The link also explains why the file path length limit and details how to disable the limit.

Personally, I don't see the value in building server/tooling software for Windows these days. The market share just isn't there, and it ends up requiring a lot of work and testing to maintain.

I would peruse such software.

I can rely on Windows to still be running nice and happy a year later with no attention paid.

I can rely on Linux to die to a stiff breeze.

(Note: I'm probably cursed.)

It's odd. I often hear this, yet I have been professionally supporting Windows in production since version 2.01 in 1988, including deploying NT 3.1, in prod, before any service packs, in 1993.

It is the direct opposite of 36 years of extensive professional experience.

Linux is pretty tough. It will run on anything, and can cope with a lot of changes and damage.

21st century Windows is the most fragile OS I've worked with since classic MacOS.

> I also hate that Windows paths are limited to 260 characters !?

Easily changed in the registry/ with group policy, though 256 should not be the default today.

Can you assume your users do that?

if they installed windows they knew exactly what they were signing up for

Was going to say the situation with path lengths on Windows is mostly gone today, but it does still pop up on the odd occasion.

For example the built in .zip file support can’t extract long paths (7-zip however has no issue).

Also my Git client of choice (TortoiseGit) doesn’t fully handle long paths.

But day to day long paths on Windows is fortunately not really an issue any more and they’ve been steadily improving support over the years.

Despite generally being a fan of Windows, before Windows 10 the long path situation was infuriating, they even had a blog post acknowledging it’s a problem, but also stating it was going to be very non trivial to fix and as such they didn’t have any particular plans to fix it.

I suspect that WSL made the limitation more regularly painful enough that they could convince managers that it’s something that had to get fixed.

Windows Terminal was probably also motivated by WSL.

MAX_PATH used to be 260 characters but was changed fairly early in Windows 10 life to 32k.

NTFS has always supported 32k characters in the path with each part being no more than 255 characters.

Office, OTOH, does not respect/observe MAX_PATH. Do not exceed ~240 characters in the path + filename for an Office document as Office will be unable to open it.

How in the world is your rant in linked file supposed to work?

* It seems you decide whether to execute a file by its extension, e.g. `.php`

* You are complaining that Windows is stripping away spaces, so `.php ` becomes `.php`

* And supposedly this could lead the file being served as static text if you didn't have a Windows workaround?

It rather seems to me that POSIX accepting `.php ` as a filename, and this not being picked up by a `.php` check is problematic here.

No, look at the associated unit test: https://github.com/caddyserver/caddy/blob/c6eb186064091c79f4...

If that test fails we could serve PHP source code instead of having it be evaluated, a potential security flaw.

Reply on news.ycombinator.com