perl@rdin.UUCP (Robert Perlberg) (04/05/84)
<> I have on several occasions run into the problem of having a program create an unremovable file. If I try: rm a.out rm will respond: a.out: not removed. (I checked the permissions on the file and the directory - I should be able to remove it.) This did not even work when root tried to remove it. /etc/unlink fairs no better than rm. It can be moved: mv a.out duh but not removed: rm duh duh: not removed I am able to remove such files by the following method: mkdir tempdir mv a.out tempdir rm -r tempdir Does anyone know what causes a file like this to be created and why the system behaves as it does when I try to remove it? I am running UNIX System III. I checked the directory with "od -c" and the link entry has no strange characters in it. Robert Perlberg Resource Dynamics Inc. New York philabs!rdin!rdin2!perl
sanders@aecom.UUCP (04/06/84)
You will get that message when someone is running that file. Moving it into a directory shouldn't help. Maybe by the time you create the directory and move it, the process is no longer active. -- Jeremy Sanders {spike|rocky2|philabs|pegasus|esquire|cucard}!aecom!{sanders|jsanders|sander}
mrl@drutx.UUCP (04/06/84)
<> The file is probably in use by you or someone else. If the file is listed as being open, unix won't allow it to be removed until the file is released. It is the same problem you run into when you try to remove or remake /bin/sh, /etc/getty, etc. M. Longo Denver
gwyn@brl-vgr.ARPA (Doug Gwyn ) (04/08/84)
Two possible reasons for an a.out to be unremovable are: (1) "text busy" -- someone is executing it (2) "stuck" -- need to turn off sticky bit and execute first
guy@rlgvax.UUCP (Guy Harris) (04/10/84)
> The file is probably in use by you or someone else. If the > file is listed as being open, unix won't > allow it to be removed until the file is released. It is the same > problem you run into when you try to remove or remake /bin/sh, /etc/getty, > etc. Actually, this isn't the case for open files - UNIX will happily let you unlink open files; the directory entry referencing the file will go away, but the file will remain until the last process using the file closes it. If the file is a shared-text executable image, however, UNIX will not let you remove the last link to it until the last process using that shared text goes away. The reason the latter step was taken, I am told, is that if the system crashed after the directory entry was removed but before the last process finished with it, it would leave an "orphaned" file which "fsck" would complain about. This problem also occurs, however, in the first case (an open file), so it's not clear that the restriction on unlinking active shared-text executables (which arrived in V7, and continued in USG UNIX) is really useful. Berkeley decided it wasn't useful, so 4.xBSD permits you to remove the last link to the file, which makes it easier to remake programs like "/bin/sh". It does mean, however, that you have to remember that any process currently using that executable image will continue to use the old image - only processes invoking the new executable image will get it (which may have been another reason for not permitting the last link to be removed - but, then again, you could rename "/bin/sh" to "/bin/OLDsh" and drop in a new "/bin/sh" anyway). I also removed it recently from our own UNIX port. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy