Sam Steingold wrote:
> How should DELETE-FILE behave on open file streams?
I would have thought that, on Unix and Unixoid systems, this is a great
opportunity to do the standard `remove the last file name but leave the
(now nameless) file existing until the last file descriptor referring
to it goes away' trick. In fact, if you just find the file referred to
by the stream, at the Unix level, and do an unlink(2) on that, while
*not* closing the stream, this is the semantics you'll get for free.
This is really useful behaviour, although possibly not implementable on
other systems (it's hard enough on NFS), as it lets you get at truly
private temporary files.
I guess there would be problems if you then tried to ask for the
pathname associated with the stream - you'd need to make sure that you
returned NIL (is this allowed?) or at least *not* the original
pathname, since that isn't the name of the file any more (it doesn't
have a name any more, in fact).
In response to one of the other followups: no, it's not just a data
sink after you've removed the last name: it's a proper file, with an
inode and disk blocks, it just happens not to have a name any more, so
the only references to it are from opern file descriptors. Files are
first-classs objects in (most?) Unix filesystems. A classic unix
mysteriosity is when something is spewing data to a log file, which you
then unlink, without kicking the application. Shortly after, the disk
fills, but there are no (named) large files...
I definitely don't think that DELETE-FILE should operate on any file
other than the one that is actually open at the OS level, in any case.
--tim
From: Sam Steingold
Subject: Re: (DELETE-FILE open-file-stream)
Date:
Message-ID: <u4qnbayob.fsf@gnu.org>
> * ··········@tfeb.org <··········@gsro.bet> [2004-08-10 03:49:00 -0700]:
>
> In response to one of the other followups: no, it's not just a data
> sink after you've removed the last name: it's a proper file, with an
what I meant was that the _stream_ becomes a data sink.
if the original file was new (in particular, it has no hard links), then
after deleting it, the inode would have no names, so there would be
absolutely no way (known to me) to get to the data written to the stream.
> inode and disk blocks, it just happens not to have a name any more, so
> the only references to it are from opern file descriptors. Files are
> first-classs objects in (most?) Unix filesystems. A classic unix
> mysteriosity is when something is spewing data to a log file, which you
> then unlink, without kicking the application. Shortly after, the disk
> fills, but there are no (named) large files...
... but everything will be OK as soon as I kill the application, right?
very interesting.
thanks for the insight!
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Perl: all stupidities of UNIX in one.
Sam Steingold <···@gnu.org> wrote:
>> * ··········@tfeb.org <··········@gsro.bet> [2004-08-10 03:49:00 -0700]:
>> inode and disk blocks, it just happens not to have a name any more, so
>> the only references to it are from opern file descriptors. Files are
>> first-classs objects in (most?) Unix filesystems. A classic unix
>> mysteriosity is when something is spewing data to a log file, which you
>> then unlink, without kicking the application. Shortly after, the disk
>> fills, but there are no (named) large files...
>
> ... but everything will be OK as soon as I kill the application, right?
Yes, the filesystem's GC wakes up and reaps the storage. :)
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
Sam Steingold <···@gnu.org> writes:
> what I meant was that the _stream_ becomes a data sink.
> if the original file was new (in particular, it has no hard links), then
> after deleting it, the inode would have no names, so there would be
> absolutely no way (known to me) to get to the data written to the stream.
Just try it (not under slime!):
(with-open-file (test "/tmp/test"
:direction :io
:if-does-not-exist :create
:if-exists :supersede)
(let ((pos (file-position test)))
(princ "There is very little in the program that is not straightforward."
test)
(ext:shell "rm /tmp/test")
(file-position test pos))
(let ((*standard-input* test))
(when (= 0 (linux:fork))
(print (read-line))))) ;; that's so much not a sink that it can
;; even be read back by another process!
;; And we could provide more interesting example, where data
;; is further written by one process and read by others at the same time.
Unfortunately, replacing the implementation dependant part with the
either one of the following CLHS forms:
(delete-file test)
(delete-file "/tmp/test")
produces an unconforming error in clisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
Pascal Bourguignon <····@mouse-potato.com> writes:
> Sam Steingold <···@gnu.org> writes:
>> what I meant was that the _stream_ becomes a data sink.
>> if the original file was new (in particular, it has no hard links), then
>> after deleting it, the inode would have no names, so there would be
>> absolutely no way (known to me) to get to the data written to the stream.
>
> Just try it (not under slime!):
>
>
> (with-open-file (test "/tmp/test"
> :direction :io
> :if-does-not-exist :create
> :if-exists :supersede)
> (let ((pos (file-position test)))
> (princ "There is very little in the program that is not straightforward."
> test)
> (ext:shell "rm /tmp/test")
> (file-position test pos))
> (let ((*standard-input* test))
> (when (= 0 (linux:fork))
> (print (read-line))))) ;; that's so much not a sink that it can
> ;; even be read back by another process!
> ;; And we could provide more interesting example, where data
> ;; is further written by one process and read by others at the same time.
...and also /dev/fd/ in some systems.
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.