tims@uunet.uu.net (Tim Sesow (SSDS Rocky Mntn)) (02/07/91)
Having both had the bad experience of trying to restore a SunOS file system with Gatorbox/Macintosh slash file names in it and working on NFS software, I think the real problem lies in the designation of a UNIX system as an NFS file server, when it cannot handle the files that NFS is "allowed" to create. I am fairly sure that the NFS spec does not contain any limitations on the file names, therefore a slash is allowed. Given that, it seems that any system that is sold as a file server should have the utilities (other than just "dd") to handle the system administration of these files. I would like to hear suggestions for changes to the NFS spec. to solve this problem, since I can't think up any that work in the long run. Just to forestall some discussion: 1. Telling the Gatorbox to not allow slashes doesn't work. I see too many files with names like "Expense Report 12/14/90". 2. Translating the slash just moves the problem to another character. 3. Adding a directory delimiter to the NFS spec doesn't fit with the way NFS works for directories. Tim Sesow SSDS, Inc. Littleton, CO (303) 798-5520
barmar@think.com (Barry Margolin) (02/08/91)
It's quite obvious to anyone who has implemented NFS for non-Unix systems that NFS isn't quite as OS-independent as it was intended to be. The most obvious problem is that symbolic link targets are returned to the client as text, and the client must parse it; Unix clients expect to be able to parse them as Unix pathnames, so non-Unix servers must translate their symbolic links to Unix syntax if they want Unix clients to be able to use them, and non-Unix clients must be able to parse Unix pathnames in order In article <25881@adm.brl.mil> ssds!tims@uunet.uu.net (Tim Sesow (SSDS Rocky Mntn)) writes: [Regarding the fact that the NFS spec doesn't prohibit slashes in file names, therefore it's a Unix bug that such files are not usable:] >I would like to hear suggestions for changes to the NFS spec. >to solve this problem, since I can't think up any that work in >the long run. >Just to forestall some discussion: >1. Telling the Gatorbox to not allow slashes doesn't work. I >see too many files with names like "Expense Report 12/14/90". >2. Translating the slash just moves the problem to another >character. >3. Adding a directory delimiter to the NFS spec doesn't fit with >the way NFS works for directories. The NFS 3.0 specification, and the NeFS proposal that followed it, include ways for a client to query the server to find out which characters aren't allowed in file names. A Unix server would disallow "/", a Macintosh server would disallow ":", a Multics or Symbolics server would disallow ">", etc. It's up to the client how it deals with such limitations, but I expect it would simply translate the invalid characters to other characters. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
bzs@world.std.com (Barry Shein) (02/08/91)
>I am fairly sure that the NFS spec does not contain any limitations >on the file names, therefore a slash is allowed. Given that, >it seems that any system that is sold as a file server should >have the utilities (other than just "dd") to handle the >system administration of these files. > >I would like to hear suggestions for changes to the NFS spec. >to solve this problem, since I can't think up any that work in >the long run. The pre-emptive solution is fairly obvious. Many NFS servers or clients do various magic things to accommodate foreign file systems (such as for DOS.) Unix NFS servers just need the same kind of thing. File names could be scanned for "funny characters" on create requests and some convention could be used to indicate that it is to be translated back to slash on read-out by a client of the same sort. Or it could go in the client (I think this sort of thing is often done in the client, tho one can argue for doing this one in the server for self-defense reasons.) So, for example, "Expense Report 2/30/91" could be stored on Unix as "Expense Report 2##30##91" or some such thing, and the appropriate warning about file name length limitations (slashes count as two characters) could be issued. Whatever. They'd then be read back and the slashes re-inserted, and everyone lives happily ever after. -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
rcpieter@svin02.info.win.tue.nl (Tiggr) (02/08/91)
bzs@world.std.com (Barry Shein) writes: >So, for example, "Expense Report 2/30/91" could be stored on Unix as >"Expense Report 2##30##91" or some such thing, and the appropriate >warning about file name length limitations (slashes count as two >characters) could be issued. Whatever. They'd then be read back and >the slashes re-inserted, and everyone lives happily ever after. And then you log on to your UNIX machine and then *surprise* you see a funny name. You don't want conversion be done by the server, but by the client; the server could (in case of a UNIX server) simply reject names containing `/' characters (reporting: `No such file or directory'). In general it isn't difficult to choose a different name after having seen this error. Tiggr -- Doesn't fsck(1) remove `/' characters from directory entries?
guy@auspex.auspex.com (Guy Harris) (02/09/91)
>I am fairly sure that the NFS spec does not contain any limitations >on the file names, therefore a slash is allowed. Yup. It also allows backslashes, which will, I suspect really piss off a DOS NFS server (yes, they exist) or an OS/2 NFS server. It also allows colons, which might piss off a Mac NFS server. Etc., etc., etc.. >Given that, it seems that any system that is sold as a file server should >have the utilities (other than just "dd") to handle the >system administration of these files. Either that, or not let you create them; that's what Suns have done since SunOS 4.1, what Auspex boxes have done since whatever release I put that fix in (I think it may have been in our first release), or what some other UNIX-based NFS servers probably do as well. Many boxes sold as file servers aren't sold *ONLY* as file servers, and you may want to have files shared between machines with different OSes, not all of which can cope with the same sorts of file names. >I would like to hear suggestions for changes to the NFS spec. >to solve this problem, since I can't think up any that work in >the long run. At one point, the NFS version 3 protocol spec included a request the response to which enumerated which characters the server could *not* cope with in file names. If it had some other characters unlikely to appear in file names, the client could then, when sending file names to the server, use those characters in some way to replace the characters the server can't cope with, and UNdo that operation when *reading* file names from the server (e.g. in the "read directory" request). >Just to forestall some discussion: Sorry, it won't work. >1. Telling the Gatorbox to not allow slashes doesn't work. I >see too many files with names like "Expense Report 12/14/90". Yes, it'd be unfortunate to tell users "sorry, you can't use file names like that", but you may simply be stuck. Life isn't always fair.... >2. Translating the slash just moves the problem to another >character. Nope. If the Mac can't cope with colons in file names (I think it's the pathname separator on Macs, and a "Macintosh System Software User's Guide, Version 6.0" here indicates that you can't use a colon in a file name), if it replaces slashes in file names with colons (which UNIX can deal with quite nicely) when it sends the names to a UNIX server, and replaces colons with slashes when it gets names from a UNIX server, the user on the Mac doesn't see any problem unless they try to tell a user on some other system "please take a look at my file 'Expense Report 12/14/90'". In that case, one or more of the users would have to be aware that the name on their system might be 'Expense Report 12:14:90'".
dente@els.ee.man.ac.uk (Colin Dente) (02/11/91)
Forgive my ignorance in all this, but how *does* nfs create these
files with slashes in their names? It seems rather strange that nfs
doesn't go through the kernel to do it (and hence get pulled up short
by namei() etc.) Perhaps this should go to comp.nfs.clueless, but I
really don't understand!
Colin
--
Colin Dente | JANET: dente@uk.ac.man.ee.els
Manchester Computing Centre | ARPA: dente@els.ee.man.ac.uk
University of Manchester, UK | UUCP: ...!mcsun!ukc!manchester!dente
... I am the one you warned me of ...scs@adam.mit.edu (Steve Summit) (02/14/91)
I begin to understand why people have such passionately awful
things to say about NFS.
As far as I'm concerned, if the NFS server code can create an
illegal file (where "illegal" is defined by the host on which the
server is running), then that's a bug in the NFS server, period.
If the protocol doesn't include an error return of "I can't
create a file of that name" (not surprising; <errno.h> doesn't
define that specific error either, although it probably should),
then it should just say something halfway like "no such file or
directory."
If the client can help out by trying not to ask for illegal files
in the first place, that's fine; but in the final analysis the
server has got to protect itself. Having the client not ask for
illegal files is never going to work perfectly, anyway: even if a
negotiation is defined by which the client can learn which
characters are illegal, some operating system somewhere is going
to have rules that can't be encoded that simply.
Has anyone ever considered modifying namei so that it essentially
checks to see if the current path character matches a target
filename character *before* checking to see if the current path
character is a '/'? That would make the filesystem robust
against inadvertent /'s in filenames, because unlink("a/b/c")
would in fact unlink a file called "b/c" in directory "a", if one
somehow existed.
(To be sure, there would be idiosyncrasies associated with such
an algorithm. In the above example, if directory "a" also
contained a subdirectory "b" as well as a file "b/c" the behavior
would depend on which came first, or something. Still, it might
be a nice escape hatch. Note that by only attempting to match
existing files in this way, it would still never create a
filename with a slash.)
Steve Summit
scs@adam.mit.edusef@kithrup.COM (Sean Eric Fagan) (02/14/91)
In article <1991Feb14.070512.24190@athena.mit.edu> scs@adam.mit.edu writes: >If the protocol doesn't include an error return of "I can't >create a file of that name" (not surprising; <errno.h> doesn't >define that specific error either, although it probably should), It does. BSD has been using EINVAL to indicate an illegal filename (8-bit set in one or more of the characters), I believe. Thus, I think that's the error that should have been used, if possible. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.