6 ms·

And the path length limitation

guy1543 10y ago
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.
- chris-at 10y ago
  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)
  - kej 10y ago
    I just did exactly that on Windows 10 and it worked just fine.
    - sp332 10y ago
      It didn't work for me either.. huh.
      - kej 10y ago
        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.
- sebtoast 10y ago
  I just tried and it works in Windows... I didn't know that despite using cmd/powershell everyday.
- Mithaldu 10y ago
  Depends on what you're doing. `dir relative/path` does not work.
- hackuser 10y ago
  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-windows-start-accepting-forward-slash-path-separator https://bytes.com/topic/python/answers/23123-when-did-window... [2] https://stackoverflow.com/questions/10523708/why-does-the-cmd-exe-shell-on-windows-fail-with-paths-using-a-forward-slash https://stackoverflow.com/questions/10523708/why-does-the-cm... [3] https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why-is-the-dos-path-character/ https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...
  - pwg 10y ago
    > 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/why-is-the-dos-path-character/ 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]
- sixothree 10y ago
  Unfortunately it does not work when specifying a server name like \\server1.
mikestew 10y ago
(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. :-)
- teh_klev 10y ago
  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
  - skykooler 10y ago
    Interestingly, your post showed a reply link for me.
    - rcthompson 10y ago
      I think the reply links on rapidly-growing threads are hidden temporarily as a rate-limiting mechanism.
maxxxxx 10y ago
Yes, that needs to go. We are spending tons of time making file names arbitrarily shorter to stay under 255 characters.
- labster 10y ago
  Right. Who wants to use a platform where you can't base64 the file's data into the filename?
  - teddyh 10y ago
    Not the base file name, the entire path to the file must be 255 characters or less.
    - labster 10y ago
      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.
    - wolfgke 10y ago
      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 http://stackoverflow.com/a/31142839/497193
      - ygra 10y ago
        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/aa365247%28v=vs.85%29.aspx#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
peelingoranges 10y ago
Path length limit is 32767 characters, do you need more? See: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
- techthroway443 10y ago
  From the first sentence of the page you linked to: > In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. Reading comprehension, do you need more?
  - deleted 10y ago
    [deleted]
  - tremon 10y ago
    Yes, I need more. Is that defined as 260 bytes or 260 characters? The following paragraphs do mention Unicode normalization and storage (USC-2 probably, given Microsoft's penchant for backwards compatibility), but not how that affects the path length. Are combining characters counted separately for MAX_PATH purposes? Do surrogate pairs count as one or two characters? This is 2016, we really shouldn't need to be asking these byte-vs-character questions any more :(
    - techthroway443 10y ago
      > Is that defined as 260 bytes or 260 characters? > MAX_PATH, which is defined as 260 characters. bruh
  - saulr 10y ago
    Continuing to read the exceptions: > The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".
tobias3 10y ago
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.

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.

chris-at 10y ago
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)
- kej 10y ago
  I just did exactly that on Windows 10 and it worked just fine.
  - sp332 10y ago
    It didn't work for me either.. huh.
    - kej 10y ago
      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.
sebtoast 10y ago
I just tried and it works in Windows... I didn't know that despite using cmd/powershell everyday.
Mithaldu 10y ago
Depends on what you're doing. `dir relative/path` does not work.
hackuser 10y ago
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-windows-start-accepting-forward-slash-path-separator https://bytes.com/topic/python/answers/23123-when-did-window... [2] https://stackoverflow.com/questions/10523708/why-does-the-cmd-exe-shell-on-windows-fail-with-paths-using-a-forward-slash https://stackoverflow.com/questions/10523708/why-does-the-cm... [3] https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/why-is-the-dos-path-character/ https://blogs.msdn.microsoft.com/larryosterman/2005/06/24/wh...
- pwg 10y ago
  > 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/why-is-the-dos-path-character/ 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]
sixothree 10y ago
Unfortunately it does not work when specifying a server name like \\server1.

mikestew 10y ago

(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. :-)

teh_klev 10y ago
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
- skykooler 10y ago
  Interestingly, your post showed a reply link for me.
  - rcthompson 10y ago
    I think the reply links on rapidly-growing threads are hidden temporarily as a rate-limiting mechanism.

maxxxxx 10y ago

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

labster 10y ago
Right. Who wants to use a platform where you can't base64 the file's data into the filename?
- teddyh 10y ago
  Not the base file name, the entire path to the file must be 255 characters or less.
  - labster 10y ago
    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.
  - wolfgke 10y ago
    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 http://stackoverflow.com/a/31142839/497193
    - ygra 10y ago
      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/aa365247%28v=vs.85%29.aspx#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

peelingoranges 10y ago

Path length limit is 32767 characters, do you need more? See: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

techthroway443 10y ago
From the first sentence of the page you linked to: > In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. Reading comprehension, do you need more?
- deleted 10y ago
  [deleted]
- tremon 10y ago
  Yes, I need more. Is that defined as 260 bytes or 260 characters? The following paragraphs do mention Unicode normalization and storage (USC-2 probably, given Microsoft's penchant for backwards compatibility), but not how that affects the path length. Are combining characters counted separately for MAX_PATH purposes? Do surrogate pairs count as one or two characters? This is 2016, we really shouldn't need to be asking these byte-vs-character questions any more :(
  - techthroway443 10y ago
    > Is that defined as 260 bytes or 260 characters? > MAX_PATH, which is defined as 260 characters. bruh
- saulr 10y ago
  Continuing to read the exceptions: > The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".

tobias3 10y ago

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.