G.Eustace@massey.ac.nz (Glen Eustace) (12/20/90)
Some time ago I posted a query about files with names that were of zero length. No one responded so I assumed that the problem was unique to us. I have just read a posting in comp.unix.questions, Message-ID: 1410@forty2.physik.unizh.ch, which sounds very similiar. Based on that and my earlier query, can someone enlighten me on the following. Is it possible to create a file with no-name ( zero length ) via NFS intentionally. If files can be created ought not this be a bug or is it a feature. The common denominator in both queries appears to be PCs running NFS. Although not specifically mentioned I am guessing that the other poster may be using PC-NFS and if so is passing a request to the server to create a file with no name a bug in PC-NFS? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen Eustace, Software Manager, Computer Centre, Massey University, Palmerston North, New Zealand. EMail: G.Eustace@massey.ac.nz Phone: +64 63 69099 x7440, Fax: +64 63 505 607, Timezone: GMT-12
barmar@think.com (Barry Margolin) (12/20/90)
In article <1990Dec20.035507.20698@massey.ac.nz> G.Eustace@massey.ac.nz (Glen Eustace) writes: >Some time ago I posted a query about files with names that were of >zero length. No one responded so I assumed that the problem was >unique to us. I have just read a posting in comp.unix.questions, >Message-ID: 1410@forty2.physik.unizh.ch, which sounds very similiar. Here's a suggestion that might work: Use "clri" to clear the inode corresponding to the file, and then fsck the partition. Hopefully this will remove the directory entry, but it's possible that fsck will simply reconstruct the inode. >Based on that and my earlier query, can someone enlighten me on the >following. Is it possible to create a file with no-name ( zero >length ) via NFS intentionally. If files can be created ought not >this be a bug or is it a feature. I haven't seen zero-length directory entries, but I've seen file names containing slashes. In our case, I think it was TOPS that created the files, when someone backed up a Macintosh to a Sun, but I've also heard of it happening with PC NFS clients. The bug is related to the fact that the Sun NFS server is implemented in the kernel, and the NFS protocol operations map directly to internal file system operations; e.g. the create-file operation passes a directory handle and a name, so there's no need to parse the pathname, and that is what prevents such files from being created by normal processes. The bug is that the NFS server doesn't perform sanity checks on the file name. >The common denominator in both queries appears to be PCs running NFS. >Although not specifically mentioned I am guessing that the other >poster may be using PC-NFS and if so is passing a request to the >server to create a file with no name a bug in PC-NFS? While it's probably not a great idea for any client to create zero-length file names, I don't think there's anything in the protocol spec that forbids it. For all the PC knows, the server (which need not be a Unix system) actually supports such names. I think the slash problem we have is a better example of this possibility, as there are many OSes that allow slashes in their file names (probably most non-Unix-derived systems), but the NFS protocol doesn't provide any way to find out whether a particular server is one of them (the proposed NeFS protocol does provide a way to find out the restricted characters). And even if the protocol did prohibit such names, a robust server must be prepared to deal with broken or malicious clients that break the rules, especially if failing to detect the error can impact other clients and local users. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
G.Eustace@massey.ac.nz (Glen Eustace) (12/21/90)
I would have thought that an NFS server implementation should have performed some form of sanity checking on what a client passed it to ensure that the requested operation was possible in the server environment, or rather didn't lead to problems. i.e. filenames were acceptable, or if not a mapping was done. We are running the 'aufs' part of CAP to provide a network file system for MACIntosh clients. We were bitten by the '/' in the name problem as well. Unix was quite happy with a '/' in the name. It was the utilities that really had problems as they, rightly, assumed that the '/' was a directory seperator and treated it as such. The cure, if my memory serves me correctly, for this was to ensure that the '/' was included in the set of characters that were mapped to ':xxx' where xxx is the octal character code. This mapping was necessary for other characters as MAC users seem to love having 'graphic' characters in filenames. Bearing in mind the above example, surely it would be sensible to place the onus of ensuring a sane, robust filesystem should be the responsibility of the server side of NFS as it is it would appear that any irregularity on the part of a client can stuff things well and truly. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Glen Eustace, Software Manager, Computer Centre, Massey University, Palmerston North, New Zealand. EMail: G.Eustace@massey.ac.nz Phone: +64 63 69099 x7440, Fax: +64 63 505 607, Timezone: GMT-12
guy@auspex.auspex.com (Guy Harris) (01/04/91)
>Unix was quite happy with a '/' in the name. It was the utilities that >really had problems as they, rightly, assumed that the '/' was a >directory seperator and treated it as such. Well: 1) "UNIX" includes the utilities; it's not just the kernel. 2) In most UNIX implementations, even the kernel isn't "happy" with a '/' in the name, in that the code that implements "open()", "stat()", etc., etc., etc. assumes that '/' is a directory separator and treats it as such, so there's not much any utility that doesn't directly access the raw disk can do about it. The problem is that the NFS server code typically goes around the code in the kernel that assumes that '/' is a directory separator; the file system implementation doesn't treat "/" specially in systems with SunOSish vnode implementations, as it's handed one component at a time. >Bearing in mind the above example, surely it would be sensible to >place the onus of ensuring a sane, robust filesystem should be the >responsibility of the server side of NFS as it is it would appear >that any irregularity on the part of a client can stuff things well >and truly. Yup. Our NFS server implementation slaps the client's wrist (with EINVAL, at least if it's a UNIX client) if the client hands it a component name containing a "/"; I think the SunOS 4.1 server implementation may do so as well. Ours also rejects zero-length file names (again, with EINVAL), and I think the 4.1 server implementation does the same.