3 ms·

The simple thing to go about this is to make assumptions that do not always hold technically. And to be ok when these assumptions break - in this case you simpl

The simple thing to go about this is to make assumptions that do not always hold technically. And to be ok when these assumptions break - in this case you simply can't deliver your promises anymore. Another way to put this is "shit in, shit out". So: When receiving a filename that is not UTF-8, one could just emit a warning and ignore the file. That's what I would do if I wrote a music tagger, at least. When someone else modifies a directory tree at the same time, we're bound to run into problems. That's just how it is. Actually there are synchronization facilities (e.g. flock()) for some of these types of problems. But these are seldom used because they lead to other problems. I think they knew all that in the 70s, and just chose to be pragmatic about it.

fiedzia 9y ago
> So: When receiving a filename that is not UTF-8, one could just emit a warning and ignore the file. The problem with invalid filenames is that doing anything at all with them might be impossible (without escaping of fixing). Your output (gui or terminal) most likely uses utf8, you can't pass invalid filename to it, so you can't even display it. Also in most situation you can't just ignore something. Imagine a text editor where user tries to open invalid file, how do you "ignore" that? Many (if not most) application that process filenames do rely on those being valid text at least in some codepaths and they simply cannot work otherwise. The proper solution is to fail and let the user fix the problem.
- jstimpfle 9y ago
  > Many (if not most) applications that process filenames do rely on those being valid text at least in some codepaths and they simply cannot work otherwise. The proper solution is to fail and let the user fix the problem. Yep, that's what I meant. You need to do what is appropriate to the situation. Ignoring / warning are only two possible handling strategies. In many situations, straight-out failing is another valid one. A file copy program should just not care and copy the darn thing. A text editor, basically the same, but maybe issue a warning. Different tasks have different requirements, like the filename being text, the filename not containing spaces, etc. Given that these requirements are somewhat arbitrary, I think it's a fine choice to just not put any non-technical constraints in the guts. There's an expression for it: Mechanism, not policy. You can always add policy on top, be it in the VFS layer, or as additional programs / classes of programs. So many potential bugs would be easily fixed if the shell glob ('*') was more configurable.
JdeBP 9y ago
Actually, these Unix-alike conventions of filenames just being NUL-terminated sequences of bytes/16-bit words come from the same thinking that gave us the concepts of files just being length-counted sequences of bytes that it was up to applications softwares to interpret and impose structure upon. They were reactions to the more structured access methods of the day.

fiedzia 9y ago

> So: When receiving a filename that is not UTF-8, one could just emit a warning and ignore the file. The problem with invalid filenames is that doing anything at all with them might be impossible (without escaping of fixing). Your output (gui or terminal) most likely uses utf8, you can't pass invalid filename to it, so you can't even display it. Also in most situation you can't just ignore something. Imagine a text editor where user tries to open invalid file, how do you "ignore" that? Many (if not most) application that process filenames do rely on those being valid text at least in some codepaths and they simply cannot work otherwise. The proper solution is to fail and let the user fix the problem.

jstimpfle 9y ago
> Many (if not most) applications that process filenames do rely on those being valid text at least in some codepaths and they simply cannot work otherwise. The proper solution is to fail and let the user fix the problem. Yep, that's what I meant. You need to do what is appropriate to the situation. Ignoring / warning are only two possible handling strategies. In many situations, straight-out failing is another valid one. A file copy program should just not care and copy the darn thing. A text editor, basically the same, but maybe issue a warning. Different tasks have different requirements, like the filename being text, the filename not containing spaces, etc. Given that these requirements are somewhat arbitrary, I think it's a fine choice to just not put any non-technical constraints in the guts. There's an expression for it: Mechanism, not policy. You can always add policy on top, be it in the VFS layer, or as additional programs / classes of programs. So many potential bugs would be easily fixed if the shell glob ('*') was more configurable.

JdeBP 9y ago

Actually, these Unix-alike conventions of filenames just being NUL-terminated sequences of bytes/16-bit words come from the same thinking that gave us the concepts of files just being length-counted sequences of bytes that it was up to applications softwares to interpret and impose structure upon. They were reactions to the more structured access methods of the day.