On Fri, 4 Oct 2013 17:25:27 -0700, Charles Mills wrote:
>> prohibits names that are not valid UTF-8
>
>What is an example of a name that is not valid UTF-8? Names that include
>Tangut or Klingon characters? Or do you mean "broken" UTF-8 that contains
>bytes (NOT characters) that are not valid UTF-8, or the first byte of a 2-byte
>sequence but not the second? Should that be permitted?
>
The latter. The former must be permitted to allow future expansion
of Unicode by assigning curently unused code points.
>Should filenames be case-insensitive is a matter of taste. I happen to like
>the Windows scheme of preserving case but performing case-insensitive searches
>of file names -- but that's just me. I code in C and am perfectly happy that
>Foo is different from foo. Yes, a system should be consistent across English
>and Cyrillic, and yes, the "equivalency" (or not!) of año/ano is a completely
>different issue than año/Año.
>
I have seen the position taken by some in these lists (I won't bother with
an archive search) that the filesystem should be oblivious to orthographic
conventions; that "caesar" or "Cæsar" should be found alike in a search
(and not allowed to coexist in the same directory), while the orthography
should be preserved for display.
On Fri, 4 Oct 2013 21:35:56 -0400, Tony Harminc wrote:
>
>If, as Charles asks, you are talking about invalid (malformed) UTF-8,
>then that's akin to the discussion on DSNAMEs in JCL, and in the VTOC
>and catalog[ue]. The OS should make clear the domain of filenames, and
>enforce it. It's certainly a UNIXy thing to accept almost any binary
>values, and leave the end user to deal with the results. ...
>
The UNIX scheme is particularly catholic; its namespace is pretty
close to the union of all prevalent others. Mac OS Classic allowed
NUL and '/' in filenames (but reserved ':' as a directory level
separator). Programmers exploited the NUL in order to appear
first in directory lists. (I won't defend the convention of null-
terminated strings.) OS X swaps ':' and '/', depending on which
user interface is in use. Ugh!
> ... It's also
>reasonable to provide a lower level interface that skips the validity
>check, but there may be security/integrity concerns.
>
You're nearly contradicting your earlier statement: "The OS should
make clear the domain of filenames, and enforce it." I agree. And
I'll go further to say that it should not be the prerogative of user
interfaces to restrict it. If STOW lets me create a member named
"Foo_Bar!", or even "foo)Bar(" (I believe it does), TSO and JCL should
let me allocate it (that's what quoting is for). If it's desirable to
restrict the namespace for "security/integrity concerns", that should
be left to RACF.
"integrity"? Ob"Exploits of a Mom"? The control block interfaces of
OS/360 and after have made it pretty hard to work such spoofs at a
low level; parsers may be a different matter. And the greatest
hazard I see is quiet truncation, endemic in z/OS.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
