bad filenames

der Mouse mouse at mcgill-vision.UUCP
Mon May 30 13:22:24 AEST 1988


In article <763 at ambush.UUCP>, kimcm at ambush.UUCP (Kim Chr. Madsen) writes:
>> Since this is a UNIX (tm) group I'm going to ask "how was a file
>> with a '/' in it's name created?" I *_CANT_* do it here (BSD 4.3).

> Well, last time it happened here it was due to a user's foot, by
> which he accidently turned off the power to the computer, while
> unbatching news!  [Thus a filename "what s/he said " appeared.]

> Trying to clean up the system after this wasn't easy, although a good
> job was performed by fsck(1M), but the file with a '/' in its name
> caused fsck to go into an infinite loop.

I hope you reported this as a bug.  *Nothing* in the filesystem should
*ever* cause fsck to fail (hang, crash, go nuts...).

> What we actually did was to backup as much of the /usr/spool disk,
> reformatted, and created a new filesystem on it and restored [...].

What I'd recommend is:

- create a parallel directory, call it ../salvage
	# mkdir ../salvage
- move all the "good" files/subdirectories into ../salvage
	# mv * ../salvage
	(error message about "what s/he said " goes here)
	(be careful - if you have any dot files in this directory, move
	 them too)
	(at this point there should be nothing but the bad entry left
	 in this directory)
- shuffle names
	# cd ..
	# mv old-name trashed
	# mv salvage old-name
	("old-name" is of course the name of the directory with the
	 bogus entry)
- get the inumber of the directory with the trashed entry
	# ls -id trashed
	23040 trashed
	(your number will probably differ)
- unmount the filesystem
	# cd /
	# umount /dev/ra0j
	(of course, substitute the real device name)
- nuke the directory with the bogus entry
	# clri /dev/ra0j 23040
	(change device name and inumber as appropriate)
- fix up the filesystem
	# fsck /dev/ra0j
	(normal fsck happenings....)

remount, and away you go.  There now, that wasn't so bad, was it?

An interesting little problem.  I shall have to experiment here
(4.3BSD) and see whether our fsck is as faulty, and whether the above
sequence works as it ought to get rid of the entry.  (Creating such is
fairly easy if you have access to the raw device.)

					der Mouse

			uucp: mouse at mcgill-vision.uucp
			arpa: mouse at larry.mcrcim.mcgill.edu



More information about the Comp.unix.questions mailing list