> Along similar lines, I've discovered (through bad code) that certain > NFS implementations will allow you to create files with a / in their > names. > The only way I've found to get rid of these files is by using the > same NFS client code that was used to create them (whew!). Note that > this code has to be "buggy" in the sense that it doesn't correctly > parse paths. I don't see how that follows. Not all OSes use / as a pathname component separator. (I think the Mac uses :, for example.) For that matter, it's not clear to me that all OSes use file names that are formed - or partially formed - by concatenating component strings with a distinguished separator character. (As a simple example of what else could be used, consider a length-and-contents list of length-and-contents components.) I also don't *think* the NFS spec forbids slashes in pathname components, at least not back when I did my NFS implementation - RFC1094 doesn't seem to, anyhow - which means that an NFS server that *doesn't* allow this is arguably buggy. (For that matter, I don't think NULs are forbidden either.) And there's no error code for "everything looks fine except the "filename" you specified is unacceptable to me"; the only one I can see that could reasonably be used is NFSERR_IO, and that's a bit of a stretch. Put these together and the conclusion I come to is that the only reason this sort of problem hasn't been seen more is that all NFS implementations (except for a set of measure zero :) are on UNIXoid systems and hence are "well-behaved" with respect to slashes and NULs and the like. der Mouse mouseat_private 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:48:40 PDT