HP3000-L Archives

August 2001, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Thu, 16 Aug 2001 13:06:58 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (31 lines)
Allen writes:
> I've found that rm from the POSIX shell will even purge files being
> accessed.

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 *

ATOM RSS1 RSS2