I'm assuming :purgelink is much the same as 'rm'.  We often do this to
remove files accessed by users in order to insert new versions of software.
Then often is the case, that we do another :purgelink and build a new file
which subsequent users then access.   IF the first user never closes the
program, you're saying the file is actually still on disk taking up room
with no directory entry.  I suppose we could have multiple chunks of disk
space for each purgelink.  As Spock would say "fascinating."
==========================================
Gavin writes:

Actually what rm does is to simply remove the entry for the file from the
directory.  If the file is not being accessed it will get purged at the same
time, but if it's being accessed, it will remain around until the last
process closes it at which point it will be deleted.  From a system
perspective, 'rm' of an in-use file is a perfectly safe and well defined
operation.  There is no time when a process can be accessing "deleted" disk
space for example.

In this particular case, it would be interesting to know if the disk space
got returned after the rm.  I suppose it's possible that after "unlink"ing
the file the system found it was still unable to purge the file and thus the
space is simply lost at this point (FSCHECK could probably be used to
determine if this is the case and *probably* clean up any mess that's still
remaining).

:PURGE operates by opening the file and then FCLOSEing it with the "delete"
option, so anything which prevents you from opening the file will also
prevent your getting rid of it with the :PURGE command.  I don't know how
the delete operation that follows a Posix "unlink" operation (i.e. 'rm')
works, so it may have worked because it didn't need to open the file the way
:PURGE wanted to.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *