Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!amdahl!pacbell!att-ih!gargoyle!oddjob!nucsrl!naim
From: naim@eecs.nwu.edu (Naim Abdullah)
Newsgroups: comp.unix.wizards
Subject: FileNames with the high bit set.
Message-ID: <8120010@eecs.nwu.edu>
Date: 9 Apr 88 11:24:47 GMT
Organization: Northwestern U, Evanston IL, USA
Lines: 27

On our 4.3+NFS (Mt. Xinu) system on a Vax780 and also on a Sun 3/60
running SunOS 3.5, open(2) and creat(2) return EINVAL if the pathname
supplied to them has a character with the high order bit set.

Why is this ? Has this behaviour been added by Berkeley Unix or has
it "always" been there in Unix ? Is it because sh(1) uses the parity
bit for it's own purposes and the kernel does not want to create
files that the shell might not be able to handle in this manner ?
(or is it, that sh(1) knows about this kernel idiosychracy and exploits
this behaviour for it's own advantage..). In other words, is the
kernel behaviour driven by the shell implementation or is the
shell implementation driven by the kernel behaviour? (is this
a chicken and egg question ?)

In any case, this seems like an arbitrary restriction. I can
imagine applications which might want to create files that have
names with arbitrary bytes in them (if you used a hashing function
on some key to come up with a filename, you can get an "invalid"
pathname).

		      Naim Abdullah
		      Dept. of EECS,
		      Northwestern University

		      Internet: naim@eecs.nwu.edu
		      Uucp: {ihnp4, chinet, gargoyle}!nucsrl!naim