10 ms·

This is a great example of something else about software. As software grows in usage and use cases, it starts bumping up against edge conditions which need to b

This is a great example of something else about software. As software grows in usage and use cases, it starts bumping up against edge conditions which need to be handled for various reasons. Cargo now is becoming stronger and more stable because of bugs like this being discovered. All software goes through this growth cycle. It's great to see these things worked out in the various projects that support Rust. There is another point here though; anytime the question comes up to just rewrite a piece of software, throw out all the technical debt, it's not as straightforward as it seems. Remember, together with that technical debt lies a lot of valuable learnings written into the code. I haven't worked on Windows directly in years, but I never knew that NUL was a reserved word as a file. I would, and probably still will make this mistake in the future. Which makes me wonder, has anyone written a file name validation crate that guarantees that you're not writing to any reserved words on a filesystem of the host OS? A quick search of crate.io doesn't turn anything up.

pjc50 10y ago
> I never knew that NUL was a reserved word as a file. I would, and probably still will make this mistake in the future While we're here: NUL, COM<n>, LPT<n> and AUX are reserved.
- akavel 10y ago
  And CON, as Macha mentions in a sister comment. An idiom I remember from old times in DOS, for quickly writing some contents into a file - equivalent to `cat > myfile.txt` on Linux: COPY CON MYFILE.TXT
  - ConfucianNardin 10y ago
    You can also do type con > myfile.txt
- cesarb 10y ago
  > While we're here: NUL, COM<n>, LPT<n> and AUX are reserved. Worse: they're reserved with any extension. Have a file in your repository called "aux.rs"? It will cause problems on Windows.
  - teh_klev 10y ago
    It's swings and roundabouts. Say I create an app or tool that happily resides in c:\proc\whatever then I turn my attention to creating a Linux version and specify /proc/whatever then ... boom? Sure, it's maybe a convoluted example, but for the creator of this "nul" package they got burned by something that's actually common knowledge in the MS world. I think you need to be a wee bit pro-active and take a look at your potential deployment targets and try and guard against these types of naming issues. Unix and Linux aren't the only (one true) operating systems in the world.
    - majewsky 10y ago
      The right solution, actually, is to use a library that gives you the right path for the thing that you need to do depending on the conventions of the platform. For example QStandardPaths in Qt: http://doc.qt.io/qt-5/qstandardpaths.html http://doc.qt.io/qt-5/qstandardpaths.html QString appDataDir = QStandardPaths::writableLocation(QStandardPaths::AppDataLocation); // ~/Library/Application Support/<APPNAME> on macOS // C:/Users/<USER>/AppData/Roaming/<APPNAME> on Windows // ~/.local/share/<APPNAME> on Linux
      - teh_klev 10y ago
        Still doesn't solve the case where the developer just wants to slap something in the root of the C: drive on windows from the outset (Cygwin I seem to remember defaults to c:\Cygwin for example...again slightly convoluted). Also those locations are user specific, there's nothing there to support the use-case of an app that's available to all users, or might just be a system service (/daemon).
  - metajack 10y ago
    Which happened in Servo already: https://github.com/servo/servo/issues/1226 https://github.com/servo/servo/issues/1226
- krylon 10y ago
  IIRC, CON was reserved, too, at one point (which would mean it most likely would be reserved today)? Also, have fun trying to delete C:\Program Files\Xerox ;-)
Macha 10y ago
I've done con.py on a Linux system a few times for net code in different projects and then realised I couldn't clone it on windows. It comes up infrequently enough that you can forget
curun1r 10y ago
It also shows how necessary it is to have some sort of deprecation process. Maintaining nonsensical landmine features for compatibility with an operating system released 36 years ago is putting the interests of MS's lazy long-term users ahead of the interests of its current users. Even if MS maintained a policy of only removing functionality after a 10-year deprecation period, this "feature" would have been gone long ago. Transitions must be orderly, but they should still happen. It's nice that Rust's toolchain is better able to live Windows crazy ecosystem, but that doesn't make Windows any less crazy.
- vvanders 10y ago
  If you think Microsoft supports features long-term out of lazyness then you haven't been paying attention. It's a very deliberate choice that helped them grow their business and keep customers. Transitions are nice from a development perspective but I can guarantee you'll never hear someone who uses your library happy that they need to rewrite parts of it. Also Windows doesn't have a monopoly bizarre filenames/features/etc you can find plenty of things in the nix family as well. Lastly, Rust is one of the few projects I've seen that has phenomenal Windows support. It's something that's really appreciated and is going to help them capture markets that other software won't.
  - koolba 10y ago
    > Also Windows doesn't have a monopoly bizarre filenames/features/etc you can find plenty of things in the nix family as well. Like what? I'm not aware of special file names in arbitrary directories. Only in known/documented ones like /proc or /dev. I'd say *nix OSes are too lax in what they allow as anything without a zero byte is valid.
    - comex 10y ago
      Well, Windows technically supports files with the reserved names - if you use the right APIs - but they break many programs including Explorer. You could make an analogy to Unix filenames with spaces or newlines, which can be created but don't work properly with some tools. (For spaces, try 'make CFLAGS="-I/path/with spaces/"' - there is no way to escape it or otherwise make it work. Newlines break a lot of stuff.)
akira2501 10y ago
> I haven't worked on Windows directly in years, but I never knew that NUL was a reserved word as a file. It's not. It's a reserved word through the MS-DOS file redirection facilities. If you use the newer file API or you use the \\?\[path] convention; the reserved words are not an issue and you can create files named for them.
- ygra 10y ago
  You have to use both, actually. The Unicode API and the \\?\ path prefix. It also astonishes me sometimes how many applications nowadays still choke on Unicode paths.
Vinnl 10y ago
I came across the concept of "Chesterton's fence" a while ago here on Hacker News, which I really like: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

pjc50 10y ago

> I never knew that NUL was a reserved word as a file. I would, and probably still will make this mistake in the future While we're here: NUL, COM<n>, LPT<n> and AUX are reserved.

akavel 10y ago
And CON, as Macha mentions in a sister comment. An idiom I remember from old times in DOS, for quickly writing some contents into a file - equivalent to `cat > myfile.txt` on Linux: COPY CON MYFILE.TXT
- ConfucianNardin 10y ago
  You can also do type con > myfile.txt
cesarb 10y ago
> While we're here: NUL, COM<n>, LPT<n> and AUX are reserved. Worse: they're reserved with any extension. Have a file in your repository called "aux.rs"? It will cause problems on Windows.
- teh_klev 10y ago
  It's swings and roundabouts. Say I create an app or tool that happily resides in c:\proc\whatever then I turn my attention to creating a Linux version and specify /proc/whatever then ... boom? Sure, it's maybe a convoluted example, but for the creator of this "nul" package they got burned by something that's actually common knowledge in the MS world. I think you need to be a wee bit pro-active and take a look at your potential deployment targets and try and guard against these types of naming issues. Unix and Linux aren't the only (one true) operating systems in the world.
  - majewsky 10y ago
    The right solution, actually, is to use a library that gives you the right path for the thing that you need to do depending on the conventions of the platform. For example QStandardPaths in Qt: http://doc.qt.io/qt-5/qstandardpaths.html http://doc.qt.io/qt-5/qstandardpaths.html QString appDataDir = QStandardPaths::writableLocation(QStandardPaths::AppDataLocation); // ~/Library/Application Support/<APPNAME> on macOS // C:/Users/<USER>/AppData/Roaming/<APPNAME> on Windows // ~/.local/share/<APPNAME> on Linux
    - teh_klev 10y ago
      Still doesn't solve the case where the developer just wants to slap something in the root of the C: drive on windows from the outset (Cygwin I seem to remember defaults to c:\Cygwin for example...again slightly convoluted). Also those locations are user specific, there's nothing there to support the use-case of an app that's available to all users, or might just be a system service (/daemon).
- metajack 10y ago
  Which happened in Servo already: https://github.com/servo/servo/issues/1226 https://github.com/servo/servo/issues/1226
krylon 10y ago
IIRC, CON was reserved, too, at one point (which would mean it most likely would be reserved today)? Also, have fun trying to delete C:\Program Files\Xerox ;-)

Macha 10y ago

I've done con.py on a Linux system a few times for net code in different projects and then realised I couldn't clone it on windows. It comes up infrequently enough that you can forget

curun1r 10y ago

It also shows how necessary it is to have some sort of deprecation process. Maintaining nonsensical landmine features for compatibility with an operating system released 36 years ago is putting the interests of MS's lazy long-term users ahead of the interests of its current users. Even if MS maintained a policy of only removing functionality after a 10-year deprecation period, this "feature" would have been gone long ago. Transitions must be orderly, but they should still happen. It's nice that Rust's toolchain is better able to live Windows crazy ecosystem, but that doesn't make Windows any less crazy.

vvanders 10y ago
If you think Microsoft supports features long-term out of lazyness then you haven't been paying attention. It's a very deliberate choice that helped them grow their business and keep customers. Transitions are nice from a development perspective but I can guarantee you'll never hear someone who uses your library happy that they need to rewrite parts of it. Also Windows doesn't have a monopoly bizarre filenames/features/etc you can find plenty of things in the nix family as well. Lastly, Rust is one of the few projects I've seen that has phenomenal Windows support. It's something that's really appreciated and is going to help them capture markets that other software won't.
- koolba 10y ago
  > Also Windows doesn't have a monopoly bizarre filenames/features/etc you can find plenty of things in the nix family as well. Like what? I'm not aware of special file names in arbitrary directories. Only in known/documented ones like /proc or /dev. I'd say *nix OSes are too lax in what they allow as anything without a zero byte is valid.
  - comex 10y ago
    Well, Windows technically supports files with the reserved names - if you use the right APIs - but they break many programs including Explorer. You could make an analogy to Unix filenames with spaces or newlines, which can be created but don't work properly with some tools. (For spaces, try 'make CFLAGS="-I/path/with spaces/"' - there is no way to escape it or otherwise make it work. Newlines break a lot of stuff.)

akira2501 10y ago

> I haven't worked on Windows directly in years, but I never knew that NUL was a reserved word as a file. It's not. It's a reserved word through the MS-DOS file redirection facilities. If you use the newer file API or you use the \\?\[path] convention; the reserved words are not an issue and you can create files named for them.

ygra 10y ago
You have to use both, actually. The Unicode API and the \\?\ path prefix. It also astonishes me sometimes how many applications nowadays still choke on Unicode paths.

Vinnl 10y ago

I came across the concept of "Chesterton's fence" a while ago here on Hacker News, which I really like: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence