cpf@lasspvax.UUCP (Courtenay Footman) (02/02/85)
I know there was an extensive discussion of this subject a little while ago; unfortunately I did not file it and I was hit by the bug. I tried to use Larry Wall's patch program for a group of files in seperate directories (I was trying to install all the fixes for f77 in one go), so I tried (from root) running patch from a higher level directory, while root Patch did not work, and after stopping it (^Z, kill %1) I discovered that I had a recursive directory entry: Script started on Sat Feb 2 14:04:00 1985 lnsvax# ls -ia junk junk/.orig junk: 34820 . 2 .. 34820 .orig junk/.orig: 34820 . 2 .. 34820 .orig lnsvax# mv junk/.orig junk2 mv: junk/.orig: rename: Invalid argument lnsvax# rmdir junk rmdir: junk: Directory not empty lnsvax# rm -r junk rm: cannot read junk/.orig/.orig/.orig/.orig/.orig/.orig/.orig/.orig/.orig/.orig/.orig/.orig/.orig/.orig/.orig/.orig/.orig? lnsvax# ^D script done on Sat Feb 2 14:04:55 1985 Is there any way to remove such a thing beside clri (followed, of course, by fsck)? Fsck did not find anything amiss with the file system! However, du did not work, and while I don't know what such a directory would do to dump, it doesn't look good. Also, does anyone have a patch for patch so it won't do such a thing? It seems that a link(2) was used, and since I was root, the system did not complain that a directory was involved. Some check should be made for this somewhere. -- Courtenay Footman arpa: cpf@lnsvax Newman Lab. of Nuclear Studies usenet: cornell!lnsvax!cpf Cornell University