Hacker News Reader

Comment by throweway | Hacker News Reader

And the path length limitation

Windows already does accept forward slash in paths and has for a while. The back slash still lives for legacy applications and unfortunately probably will for a long long time.

I just tried and it works in Windows... I didn't know that despite using cmd/powershell everyday.

Depends on what you're doing. `dir relative/path` does not work.

Did you try it on Windows 10? If I try to open a file `i:/foo/bar/test.txt` I get `The file name is not valid` (from Notepad)

I just did exactly that on Windows 10 and it worked just fine.

It didn't work for me either.. huh.

We're trying different things, I think. I was doing notepad i:/whatever on the command line and you're using the file open dialog within notepad, which doesn't work. Sorry for the confusion.

How is it possible I didn't know that? Thank you. Does anyone know the history of it? I did a little research:

* I found someone asking the same question as me in 2005 (!) [1]

* Per someone on Stack Overflow: "/ can be used as a path separator at the API level, but you aren't calling the API directly. You're using cmd.exe, and cmd.exe parses the / as a command line option" [2]

* Later in the same Stack Overflow discussion someone performs a series of tests on Vista, with some inconsistent results. [2]

* Here's a history by veteran Microsoft developer Larry Osterman, which takes us back to the developers of MS-DOS and also mentions other undocumented ways MS-DOS can/could be made Unix friendly. [3]

-----

[1] https://bytes.com/topic/python/answers/23123-when-did-window...

[2] https://stackoverflow.com/questions/10523708/why-does-the-cm...

[3] https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...

> How is it possible I didn't know that? Thank you. Does anyone know the history of it? I did a little research:

According to the history, DOS 2.0:

https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...

[begin quote] Here’s a little known secret about MS-DOS. The DOS developers weren’t particularly happy about this state of affairs – heck, they all used Xenix machines for email and stuff, so they were familiar with the nix command semantics. So they coded the OS to accept either “/” or “\” character as the path character (this continues today, btw – try typing “notepad c:/boot.ini” on an XP machine (if you’re an admin)). And they went one step further. They added an undocumented system call to change the switch character. And updated the utilities to respect this flag.

And then they went and finished out the scenario: They added a config.sys option, SWITCHAR= that would let you set the switch character to “-“.

Which flipped MS-DOS into a nix style system where command lines used “-switch”, and paths were / delimited. [end quote]

Unfortunately it does not work when specifying a server name like \\server1.

Yes, that needs to go. We are spending tons of time making file names arbitrarily shorter to stay under 255 characters.

Right. Who wants to use a platform where you can't base64 the file's data into the filename?

Not the base file name, the entire path to the file must be 255 characters or less.

Really? That sounds like a huge PITA. And here I've been complaining about HFS+ all this time, but the OS X APIs are better than that.

Not true: They must be less than 2^15 characters long. If you use the standard file APIs on Windows (most applications do) there exists a limit of 260 characters for the path. To access longer paths you have to use the Shell API (only few applications do):

> http://stackoverflow.com/a/31142839/497193

Uhm, Shell APIs are necessary when you're dealing with shell objects, but all filesystem APIs can work with paths longer than MAX_PATH iff you use the Unicode API (e.g. CreateFileW) and prefix the path with \\?\ [½].

They can't retroactively change MAX_PATH because it's a constant that's compiled in every application that uses it. Well-written applications these days will just do the \\?\ thing and be done with it. The downside of that is that you can get paths Explorer doesn't like. And I'm guessing Explorer explicitly doesn't allow you to create paths longer than MAX_PATH to prevent people complaining about »I created a folder in Explorer and copied a file there, but now I cannot open it.«. Keep in mind that (usually) developers can be expected to find solutions, but making it easy to frustrate regular users (of which the OS has at least a few hundred million) is not the best strategy to keep them using the OS.

Of course, there are also heaps of software that cannot use above method to allow for longer paths because they don't use the Unicode APIs. Maybe because some developers think supporting Windows 98 is a good idea nowadays, or because they just don't know any better. And in that heap there's a lot of poorly-ported open-source software, too.

[½] https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

The problem is deeply nested directory structures and sanely named directories. I got around this limitation at one job by mapping a drive deep into the directory structure, but it meant people going to the root on the network file server couldn't access the content I could (I used this work around because someone else had already done it and was cleaning it up).

The directory structure made some sense, that is, it was sane and rational. But it should've been split across several network drives to keep things shallower given the limitation.

In the Win32 API you can either have

* Forward slashes in paths but only 260 characters as max path length

* Maximum total path length of 32,767 characters but not forward slashes as path separator

Pick your poison.

(Three levels of comments, and one can no longer reply? Sorry, throweway, I have to hijack your comment to reply to guy1543.)

Guy1543, thanks, I did not know that. And I wish I had known it sooner. :-)

Click on (or open in a new tab) the comment timestamp link of the comment you wish to reply to and you'll see the reply link. I think HN stops showing the reply link after three levels into a thread to discourage possible flamewars/threads going off the reservation

Interestingly, your post showed a reply link for me.

I think the reply links on rapidly-growing threads are hidden temporarily as a rate-limiting mechanism.

Path length limit is 32767 characters, do you need more?

See: https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

Reply on news.ycombinator.com