gregb@dowjone.UUCP (Gregory S. Baber) (01/09/90)
Hello, I moved some files from a Mac to a NeXT using a GatorBox, and then took the NeXT off the network. Some of the files that were on the Mac had a '/' as part of the actual filename. How do I delete these from the NeXT now without reconnecting to the network? When I try to delete the files by hand, the shell responds with "file does not exist" because it interprets the '/' as a directory indicator. I even tried to double quote the filename to no avail. Any ideas? Thanks, gregb -- Reply to: Gregory S. Baber Voice: (609) 520-5077 Dow Jones & Co., Inc. UUCP: ..princeton!dowjone!gregb Box 300 or ..uunet!warlock!gregb Princeton, N.J. 08543-0300 "So long, and thanks for all the fish"
szirin@cbnewsm.ATT.COM (seth.zirin) (01/10/90)
In article <646@warlock.UUCP> gregb@dowjone.UUCP (Gregory S. Baber) writes: >and then took the NeXT off the network. Some of the files that were >on the Mac had a '/' as part of the actual filename. How do I delete >these from the NeXT now without reconnecting to the network? When I >try to delete the files by hand, the shell responds with "file does >not exist" because it interprets the '/' as a directory indicator. You have several options: 1) reformat the disk (JUST KIDDING!!) :-) 2) fsck the filesystem. some versions of fsck will not permit illegal characters in names. if your version of fsck cannot fix it, complain to your vendor about the bug in their fsck. 3) use fsdb to locate and edit the disk block that contains the filename with the '/'. Change the '/' to a more palatable character. WARNING: this is not for the weak-hearted! 4) copy everything else from the parent directory to a safe spot and iclear or unlink the parent directory and run fsck. if the bad name is a file (as opposed to a subdirectory), fsck will copy it to the lost+found and give it a civilized name. if you have a directory tree of bad subdirectory names, this will become a recursive process. the above procedures assume that the filesystem is mounted/unmounted appropriately. when you're all done and you haven't roached the whole filesystem or the entire disk, hold your head high; you've earned one star towards becoming a wizard. discussion of the other stars should be referred to /dev/null as we just finished that topic. Seth Zirin
cowan@marob.masa.com (John Cowan) (02/01/90)
In article <2845@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >I presume you [previous poster] mean "'open' would take the inode of a directory >and the *name* of a file within that directory" - since you way it'd >take "the inode of a directory" I presume that by "inode" you mean some >reference to the inode, in which case the "inode of (the) file" is what >"open" would presumably (more-or-less) return. Not quite. What 'open' would really do under this scheme would be to accept a >capability< for a directory, plus a file name, and return a capability for the file in question. A capability differs from an inode because it contains coded information that validates the user's access rights. A program (or shared library) would be handed two capabilities to start with: one for the root, one for the current directory, and would be able to do filename parsing given those operations. A reasonable way to implement capabilities would be to use the inode plus some random bits. For each capability, the kernel must retain a copy of it, and whenever a capability is passed in, the kernel checks whether it is valid. This makes Unix permissions syntax easy to arrange by having different capability-bit combinations for the various permission rights. Naturally, the relation between the permissions themselves and the bits should be protected by a cryptographically strong transformation....
peter@ficc.uu.net (Peter da Silva) (02/06/90)
In article <25C7178C.6F8@marob.masa.com> cowan@marob.masa.com (John Cowan) writes: > A reasonable way to implement capabilities would be to use the inode plus > some random bits. A more reasonable way would be to hide them behind a file descriptor. See the related discussions about enhancing the UNIX system, in particular the part about o_open(fd, newmode), and open(name, O_TOKEN). -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
jfh@rpp386.cactus.org (John F. Haugh II) (02/06/90)
In article <25C7178C.6F8@marob.masa.com> cowan@marob.masa.com (John Cowan) writes: >Not quite. What 'open' would really do under this scheme would be to accept >a >capability< for a directory, plus a file name, and return a capability >for the file in question. A capability differs from an inode because it >contains coded information that validates the user's access rights. >A program (or shared library) would be handed two capabilities to start with: >one for the root, one for the current directory, and would be able to do >filename parsing given those operations. > >A reasonable way to implement capabilities would be to use the inode plus >some random bits. For each capability, the kernel must retain a copy of it, >and whenever a capability is passed in, the kernel checks whether it is >valid. This makes Unix permissions syntax easy to arrange by having different >capability-bit combinations for the various permission rights. Naturally, >the relation between the permissions themselves and the bits should be >protected by a cryptographically strong transformation.... There is no reason to get crypto with this problem, unless you plan on passing "capabilities" around like candy. Remember that a file descriptor is also a "capability" and it doesn't have to be encrypted to be kept from evil doers. In the scenario you suggest, the kernel is still performing the directory lookup, so it can maintain a table of "currently available capabilities". Kinda like the open file table, only different. A user requests a file name translation and receives back an index into their capability table. They can then hand that "capability" back and request a file descriptor or whatever. The in-core inode pointed to by the capability table would contain all of the permission bits, just as inodes do today. Two problems arise. First, we are back to having the kernel perform the filename to inode translation, so there are going to be "arbitrary" decisions which someone is going to complain about. Second, the number of currently active capabilities would have to be limited on a per-process basis simply to avoid having someone request a capability for every file on the system. The "find" command sounds like a candidate. Finally, the worst of all this mess is that each component in a filename must be translated separately, or else an array of pointers to pathname pieces is going to have to be passed in. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
guy@auspex.auspex.com (Guy Harris) (02/07/90)
>Not quite. What 'open' would really do under this scheme would be to accept >a >capability< for a directory, plus a file name, and return a capability >for the file in question. A capability differs from an inode because it >contains coded information that validates the user's access rights. I indicated that by "inode" I'd presumed they meant "reference to the inode"; one such reference could be a file descriptor opened to the file (modulo, presumably, ways of having file descriptors for directories "open for searching", and the like), which, in effect, is a capability to the inode - or, if you will, a reference to a capability to the inode, the actual capability being stored in the kernel. Inodes are rather big, so there's a saving from handing around references to them rather than handing them around directly. >A reasonable way to implement capabilities would be to use the inode plus >some random bits. For each capability, the kernel must retain a copy of it, >and whenever a capability is passed in, the kernel checks whether it is >valid. This makes Unix permissions syntax easy to arrange by having different >capability-bit combinations for the various permission rights. Naturally, >the relation between the permissions themselves and the bits should be >protected by a cryptographically strong transformation.... How is this better than just handing around what amounts to references to those capabilities? (There are several ways of protecting capabilities, including simply making them not writable by non-privileged code, which is what "file descriptors as capabilities" does.)