From: Sam Steingold
Subject: (DELETE-FILE open-file-stream)
Date:
Message-ID: <uhdrckp1f.fsf@gnu.org>
How should DELETE-FILE behave on open file streams?
<http://www.lisp.org/HyperSpec/Body/fun_delete-file.html>:
If the filespec designator is an open stream, then filespec and
the file associated with it are affected (if the file system
permits), in which case filespec might be closed immediately,
and the deletion might be immediate or delayed until filespec is
explicitly closed, depending on the requirements of the file
system.
If *DEFAULT-PATHNAME-DEFAULTS* is set to something silly and the file
which is actually to be deleted is different from the argument, then the
argument stream should not be closed, right?
e.g.,
(setq stream (open "foo" :direction :output))
(let ((*default-pathname-defaults* (make-pathname :type "tmp")))
(delete-file stream))
should delete "foo.tmp" and leave the STREAM and "foo" alone, right?
With non-silly *DEFAULT-PATHNAME-DEFAULTS* there are other issues:
DELETE-FILE & RENAME-FILE are the only(?) pathname functions which
appear not to satisfy the condition
(X Y) == (X (PATHNAME Y))
What do people expect from
(setq stream (open "foo" :direction :output))
(delete-file stream)
stream closed, "foo" deleted?
how about
(setq stream (open "foo" :direction :output))
(delete-file "foo")
same as above (stream closed, "foo" deleted)
or an error "cannot delete a file to which there is an open stream"?
or maybe "foo" deleted but stream remains open and serves as a "data sink"?
what about
(setq stream (open "foo" :direction :output))
(setq strea1 (open "foo" :direction :output))
(delete-file stream)
should strea1 be automatically closed?
--
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>
Those who value Life above Freedom are destined to lose both.
In article <·············@gnu.org>, Sam Steingold <···@gnu.org> wrote:
> How should DELETE-FILE behave on open file streams?
> <http://www.lisp.org/HyperSpec/Body/fun_delete-file.html>:
> If the filespec designator is an open stream, then filespec and
> the file associated with it are affected (if the file system
> permits), in which case filespec might be closed immediately,
> and the deletion might be immediate or delayed until filespec is
> explicitly closed, depending on the requirements of the file
> system.
>
> If *DEFAULT-PATHNAME-DEFAULTS* is set to something silly and the file
> which is actually to be deleted is different from the argument, then the
> argument stream should not be closed, right?
>
> e.g.,
> (setq stream (open "foo" :direction :output))
> (let ((*default-pathname-defaults* (make-pathname :type "tmp")))
> (delete-file stream))
> should delete "foo.tmp" and leave the STREAM and "foo" alone, right?
I don't think so. If you use a stream as the argument, it operates on
the file that the stream is opened to. *DEFAULT-PATHNAME-DEFAULTS* is
not used at all in this case, since no filename parsing is being done.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Sam Steingold
Subject: Re: (DELETE-FILE open-file-stream)
Date:
Message-ID: <u7js8kkig.fsf@gnu.org>
> * Barry Margolin <······@nyhz.zvg.rqh> [2004-08-09 18:03:41 -0400]:
>
> In article <·············@gnu.org>, Sam Steingold <···@gnu.org> wrote:
>
>> (setq stream (open "foo" :direction :output))
>> (let ((*default-pathname-defaults* (make-pathname :type "tmp")))
>> (delete-file stream))
>> should delete "foo.tmp" and leave the STREAM and "foo" alone, right?
>
> I don't think so. If you use a stream as the argument, it operates on
> the file that the stream is opened to. *DEFAULT-PATHNAME-DEFAULTS* is
> not used at all in this case, since no filename parsing is being done.
oops! thanks a lot!
Now, how about
(setq stream (open "foo" :direction :output))
and
(delete-file stream)
vs
(delete-file "foo")
???
--
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>
Whether pronounced "leenooks" or "line-uks", it's better than Windows.
In article <·············@gnu.org>, Sam Steingold <···@gnu.org> wrote:
> > * Barry Margolin <······@nyhz.zvg.rqh> [2004-08-09 18:03:41 -0400]:
> >
> > In article <·············@gnu.org>, Sam Steingold <···@gnu.org> wrote:
> >
> >> (setq stream (open "foo" :direction :output))
> >> (let ((*default-pathname-defaults* (make-pathname :type "tmp")))
> >> (delete-file stream))
> >> should delete "foo.tmp" and leave the STREAM and "foo" alone, right?
> >
> > I don't think so. If you use a stream as the argument, it operates on
> > the file that the stream is opened to. *DEFAULT-PATHNAME-DEFAULTS* is
> > not used at all in this case, since no filename parsing is being done.
>
> oops! thanks a lot!
>
> Now, how about
>
> (setq stream (open "foo" :direction :output))
>
> and
> (delete-file stream)
> vs
> (delete-file "foo")
> ???
The second will perform pathname defaulting, since that's part of
converting a string to a filename.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <······@alum.mit.edu> writes:
> The second will perform pathname defaulting, since that's part of
> converting a string to a filename.
You seem to be neglecting the other part of pathname defaulting,
described in CLHS 19.2.3:
Except as explicitly specified otherwise, for functions that
manipulate or inquire about files in the file system, the pathname
argument to such a function is merged with
*default-pathname-defaults* before accessing the file system (as if
by merge-pathnames).
*DEFAULT-PATHNAME-DEFAULTS* is not just about parsing strings to
filenames.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
In article <··············@cam.ac.uk>,
Christophe Rhodes <·····@cam.ac.uk> wrote:
> Barry Margolin <······@alum.mit.edu> writes:
>
> > The second will perform pathname defaulting, since that's part of
> > converting a string to a filename.
>
> You seem to be neglecting the other part of pathname defaulting,
> described in CLHS 19.2.3:
>
> Except as explicitly specified otherwise, for functions that
> manipulate or inquire about files in the file system, the pathname
> argument to such a function is merged with
> *default-pathname-defaults* before accessing the file system (as if
> by merge-pathnames).
But if a pathname is fully specified, this doesn't do anything. And the
pathname associated with a stream is fully specified.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <······@alum.mit.edu> writes:
> In article <··············@cam.ac.uk>,
> Christophe Rhodes <·····@cam.ac.uk> wrote:
>> Except as explicitly specified otherwise, for functions that
>> manipulate or inquire about files in the file system, the pathname
>> argument to such a function is merged with
>> *default-pathname-defaults* before accessing the file system (as if
>> by merge-pathnames).
>
> But if a pathname is fully specified, this doesn't do anything. And the
> pathname associated with a stream is fully specified.
Ah, now that's interesting! Thank you for raising this; it hadn't
occurred to me. Is the pathname associated with the stream returned
by
(open (make-pathname :directory '(:absolute "tmp") :name "foo"))
fully specified, even given the lack of :type and :version components?
That is, does being associated with a file "trump" the normal rules of
merging with merge-pathnames, which treats NIL fields as unspecified?
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
In article <··············@cam.ac.uk>,
Christophe Rhodes <·····@cam.ac.uk> wrote:
> Barry Margolin <······@alum.mit.edu> writes:
>
> > In article <··············@cam.ac.uk>,
> > Christophe Rhodes <·····@cam.ac.uk> wrote:
> >> Except as explicitly specified otherwise, for functions that
> >> manipulate or inquire about files in the file system, the pathname
> >> argument to such a function is merged with
> >> *default-pathname-defaults* before accessing the file system (as if
> >> by merge-pathnames).
> >
> > But if a pathname is fully specified, this doesn't do anything. And the
> > pathname associated with a stream is fully specified.
>
> Ah, now that's interesting! Thank you for raising this; it hadn't
> occurred to me. Is the pathname associated with the stream returned
> by
> (open (make-pathname :directory '(:absolute "tmp") :name "foo"))
> fully specified, even given the lack of :type and :version components?
> That is, does being associated with a file "trump" the normal rules of
> merging with merge-pathnames, which treats NIL fields as unspecified?
If OPEN succeeded, the pathname must have specified everything the OS
requires to uniquely identify a file. What does
(pathname (make-pathname :directory '(:absolute "tmp") :name "foo")))
return?
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <······@alum.mit.edu> writes:
> If OPEN succeeded, the pathname must have specified everything the
> OS requires to uniquely identify a file.
Right, but it need not specify all the fields mandated by the Common
Lisp specification to identify the file to the OS.
> What does
> (pathname (make-pathname :directory '(:absolute "tmp") :name "foo")))
> return?
I'm unsure of what you're driving at with this, but I would suggest
that on a Unix OS, it would return a pathname with components
HOST: "" ; or something else
DEVICE: NIL ; opaque object; not terribly interesting
DIRECTORY: (:ABSOLUTE "tmp")
NAME: "foo"
TYPE: NIL
VERSION: NIL ; or maybe :NEWEST
This uniquely identifies the file named (in Unix terms) by "/tmp/foo".
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Barry Margolin wrote:
> In article <··············@cam.ac.uk>,
> Christophe Rhodes <·····@cam.ac.uk> wrote:
>
>
>>Barry Margolin <······@alum.mit.edu> writes:
>>
>>
>>>In article <··············@cam.ac.uk>,
>>> Christophe Rhodes <·····@cam.ac.uk> wrote:
>>>
>>>> Except as explicitly specified otherwise, for functions that
>>>> manipulate or inquire about files in the file system, the pathname
>>>> argument to such a function is merged with
>>>> *default-pathname-defaults* before accessing the file system (as if
>>>> by merge-pathnames).
>>>
>>>But if a pathname is fully specified, this doesn't do anything. And the
>>>pathname associated with a stream is fully specified.
>>
>>Ah, now that's interesting! Thank you for raising this; it hadn't
>>occurred to me. Is the pathname associated with the stream returned
>>by
>> (open (make-pathname :directory '(:absolute "tmp") :name "foo"))
>>fully specified, even given the lack of :type and :version components?
>>That is, does being associated with a file "trump" the normal rules of
>>merging with merge-pathnames, which treats NIL fields as unspecified?
>
>
> If OPEN succeeded, the pathname must have specified everything the OS
> requires to uniquely identify a file. What does
>
> (pathname (make-pathname :directory '(:absolute "tmp") :name "foo")))
>
> return?
IMHO, the question raised is whether for CL implemetation A and CL
implememtation B, both under UNIX (implementation X version Y, I'll
grant you that) the two pathnames are "equalp," for a suitable
definition of "equalp."
In the current state of affairs, there is very little in the standard
that ensures a proper definition of "equalp" in this case.
Cheers
--
Marco
Christophe Rhodes <·····@cam.ac.uk> writes:
> Barry Margolin <······@alum.mit.edu> writes:
>
>> In article <··············@cam.ac.uk>,
>> Christophe Rhodes <·····@cam.ac.uk> wrote:
>>> Except as explicitly specified otherwise, for functions that
>>> manipulate or inquire about files in the file system, the pathname
>>> argument to such a function is merged with
>>> *default-pathname-defaults* before accessing the file system (as if
>>> by merge-pathnames).
>>
>> But if a pathname is fully specified, this doesn't do anything. And the
>> pathname associated with a stream is fully specified.
>
> Ah, now that's interesting! Thank you for raising this; it hadn't
> occurred to me. Is the pathname associated with the stream returned
> by
> (open (make-pathname :directory '(:absolute "tmp") :name "foo"))
> fully specified, even given the lack of :type and :version components?
> That is, does being associated with a file "trump" the normal rules of
> merging with merge-pathnames, which treats NIL fields as unspecified?
You may recall that some months back I posted a bunch of notes about
how different implementations deal with pathnames[1]. One idea that
occured to me while writing those notes but that I didn't mention in
them is that in an ideal world *DEFAULT-PATHNAME-DEFAULTS* would not
contain any NIL components; any components not needed by the
implementation/filesystem should be :UNSPECIFIC in the default
*DEFAULT-PATHNAME-DEFAULTS*. That way any pathname designator, after
being merged with *DEFAULT-PATHNAME-DEFAULTS*, either by default or
explicitly, will be "fully specified" in the sense that it will have
no NIL components.
I didn't mention it in my notes because, IIRC, none of the
implementations I looked at used this strategy and I didn't want to
take on the challenge of trying to get any of them to do it either by
suasion or contributing code. But I think it would actually make a lot
of the pathname stuff work out more consistently--DIRECTORY for
instance could be thought of as performing a merge with
*DEFAULT-PATHNAME-DEFAULTS* first and then upgrading NIL with wild
which would make it "consistent with" PATHNAME-MATCH-P (which doesn't
merge with *DEFAULT-PATHNAME-DEFAULTS* since it doesnt "manipulate or
inquire about files in the filesystem"(Sec 19.2.3)) without requiring
it to treat NIL components as :WILD.
I may have forgotten some of the details but if any implementors are
interested in mucking with their pathname code (yeah right) I can try
to put together a more coherent writeup of what I was thinking back
then.
-Peter
[1] Message-ID: <··············@javamonkey.com>
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Juan Jose Garcia Ripoll
Subject: Re: (DELETE-FILE open-file-stream)
Date:
Message-ID: <2ns86lF443poU1@uni-berlin.de>
Peter Seibel wrote:
I may have forgotten some of the details but if any implementors are
> interested in mucking with their pathname code (yeah right) I can try
> to put together a more coherent writeup of what I was thinking back
> then.
I would be very happy to see a summary of the dark corners of the
pathname system, and use it to improve ECL's implementation -- in other
words, you put the thoughts, I might put some code during these holidays :-)
Regards,
Juanjo
From: Sam Steingold
Subject: Re: (DELETE-FILE open-file-stream)
Date:
Message-ID: <ullgl7kjc.fsf@gnu.org>
> * Peter Seibel <·····@wninzbaxrl.pbz> [2004-08-10 15:22:41 +0000]:
>
> You may recall that some months back I posted a bunch of notes about
> how different implementations deal with pathnames[1]. One idea that
> occured to me while writing those notes but that I didn't mention in
> them is that in an ideal world *DEFAULT-PATHNAME-DEFAULTS* would not
> contain any NIL components; any components not needed by the
> implementation/filesystem should be :UNSPECIFIC in the default
> *DEFAULT-PATHNAME-DEFAULTS*. That way any pathname designator, after
> being merged with *DEFAULT-PATHNAME-DEFAULTS*, either by default or
> explicitly, will be "fully specified" in the sense that it will have
> no NIL components.
note that MERGE-PATHNAMES is _MERGE_ and _NOT_ _OR_.
<http://clisp.cons.org/impnotes/filename-dict.html#pathmerge>
This means that even with *DEFAULT-PATHNAME-DEFAULTS* having no NIL
components, merging it repeatedly may be detrimental if
*DEFAULT-PATHNAME-DEFAULTS* has a silly (non-trivial relative) directory
value.
--
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>
If you're beeing passed on the right, you're in the wrong lane.
Christophe Rhodes <·····@cam.ac.uk> writes:
> Barry Margolin <······@alum.mit.edu> writes:
>
>> The second will perform pathname defaulting, since that's part of
>> converting a string to a filename.
>
> You seem to be neglecting the other part of pathname defaulting,
> described in CLHS 19.2.3:
>
> Except as explicitly specified otherwise, for functions that
> manipulate or inquire about files in the file system, the pathname
> argument to such a function is merged with
> *default-pathname-defaults* before accessing the file system (as if
> by merge-pathnames).
>
> *DEFAULT-PATHNAME-DEFAULTS* is not just about parsing strings to
> filenames.
How did what Barry said neglect that? I assumed when he said "pathname
defaulting" he meant exactly the merging with
*DEFAULT-PATHNAME-DEFAULTS*. Is there some other kind of pathname
defaulting?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Sam Steingold <···@gnu.org> writes:
> How should DELETE-FILE behave on open file streams?
> <http://www.lisp.org/HyperSpec/Body/fun_delete-file.html>:
> If the filespec designator is an open stream, then filespec and
> the file associated with it are affected (if the file system
> permits), in which case filespec might be closed immediately,
> and the deletion might be immediate or delayed until filespec is
> explicitly closed, depending on the requirements of the file
> system.
>
> If *DEFAULT-PATHNAME-DEFAULTS* is set to something silly and the file
> which is actually to be deleted is different from the argument, then the
> argument stream should not be closed, right?
>
> e.g.,
> (setq stream (open "foo" :direction :output))
> (let ((*default-pathname-defaults* (make-pathname :type "tmp")))
> (delete-file stream))
> should delete "foo.tmp" and leave the STREAM and "foo" alone, right?
Hmmm. I'd expect it to delete the file that is actually being written
to by STREAM. The argument to DELETE-FILE is a pathname designator.
Per the glossary entry for "pathname designator" a "stream associated
with a file" designates "the pathname used to open the file". To me
that means the actual pathname, as resolved at OPEN time, not some new
pathname created now in a different context.
> With non-silly *DEFAULT-PATHNAME-DEFAULTS* there are other issues:
>
> DELETE-FILE & RENAME-FILE are the only(?) pathname functions which
> appear not to satisfy the condition
> (X Y) == (X (PATHNAME Y))
Why do you say that? They are both specified to take a pathname
designator as their first argument.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
From: Sam Steingold
Subject: Re: (DELETE-FILE open-file-stream)
Date:
Message-ID: <ud620kkvq.fsf@gnu.org>
> * Peter Seibel <·····@wninzbaxrl.pbz> [2004-08-09 21:40:09 +0000]:
>
> Sam Steingold <···@gnu.org> writes:
>
>> With non-silly *DEFAULT-PATHNAME-DEFAULTS* there are other issues:
>>
>> DELETE-FILE & RENAME-FILE are the only(?) pathname functions which
>> appear not to satisfy the condition
>> (X Y) == (X (PATHNAME Y))
>
> Why do you say that? They are both specified to take a pathname
> designator as their first argument.
after
(setq stream (open "foo" :direction :output))
form
(delete-file stream)
is not the same as
(delete-file (pathname stream))
because the former will close STREAM and delete "foo"
while the latter might signal an error about deleting a file with an
open stream open to it (or it might delete the file and leave STREAM
alone, or it might magically close STREAM and delete the file - but do
people expect that?)
--
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>
The difference between genius and stupidity is that genius has its limits.
Sam Steingold <···@gnu.org> wrote:
> because the former will close STREAM and delete "foo"
> while the latter might signal an error about deleting a file with an
> open stream open to it (or it might delete the file and leave STREAM
> alone, or it might magically close STREAM and delete the file - but do
> people expect that?)
I'd expect the DELETE-FILE on pathname with an open stream to delete the
file, but leave the stream alone iff the platform can deal with that, and
signal a error (continuable for preference) otherwise.
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
From: Sam Steingold
Subject: Re: (DELETE-FILE open-file-stream)
Date:
Message-ID: <upt5zc1zs.fsf@gnu.org>
> * <·········@enaqbz-fgngr.arg> [2004-08-09 22:47:15 +0000]:
>
> Sam Steingold <···@gnu.org> wrote:
>
>> because the former will close STREAM and delete "foo"
>> while the latter might signal an error about deleting a file with an
>> open stream open to it (or it might delete the file and leave STREAM
>> alone, or it might magically close STREAM and delete the file - but do
>> people expect that?)
>
> I'd expect the DELETE-FILE on pathname with an open stream to delete
> the file, but leave the stream alone iff the platform can deal with
> that, and signal a error (continuable for preference) otherwise.
UNIX "can deal with that" by turning the stream into a data sink.
Win32 signals an error.
Since Common Lisp should provide consistent behavior across platforms
(IMHO), there are actually only two options: always signal an error when
there is an open stream or magically close all such streams.
--
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>
Why use Windows, when there are Doors?
Sam Steingold <···@gnu.org> writes:
> > * <·········@enaqbz-fgngr.arg> [2004-08-09 22:47:15 +0000]:
> >
> > Sam Steingold <···@gnu.org> wrote:
> >
> >> because the former will close STREAM and delete "foo"
> >> while the latter might signal an error about deleting a file with an
> >> open stream open to it (or it might delete the file and leave STREAM
> >> alone, or it might magically close STREAM and delete the file - but do
> >> people expect that?)
> >
> > I'd expect the DELETE-FILE on pathname with an open stream to delete
> > the file, but leave the stream alone iff the platform can deal with
> > that, and signal a error (continuable for preference) otherwise.
>
> UNIX "can deal with that" by turning the stream into a data sink.
I'm not sure what you mean here.
int fd=open("file",O_RDWR|O_CREAT);
unlink("file");
turns no inode into any data sink!
In UNIX, there's no "file", only inodes and (names,inode) associations
stored in directory inodes.� A regular-file inode with no association
is still a regular-file inode and data can be written and read like in
any other regular-file inode.
> Win32 signals an error.
>
> Since Common Lisp should provide consistent behavior across platforms
> (IMHO), there are actually only two options: always signal an error when
> there is an open stream or magically close all such streams.
UNIX behavior is useful. Win32 is not (well perhaps it is in in the
frame of its file system semantics). Common-Lisp says the behavior of
DELETE-FILE depends on the file system.
I don't see that an implementation has any choice here: it should do
what the file system does. Therefore;
- on UNIX unlink and wait for the CLOSE/close to have the inode
effectively deleted.
- on Win32, catch the MS-Windows the error and forward it.
The only choices an implementation has with respect of DELETE-FILE are:
- the result of DELETE-FILE applied to an inexistant name,
- the behavior when :wild or nil pathname components are provided.
--
__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.
Sam Steingold <···@gnu.org> wrote:
> Since Common Lisp should provide consistent behavior across platforms
> (IMHO), there are actually only two options: always signal an error when
> there is an open stream or magically close all such streams.
I disagree. The operatios should make as much sense as possible for the
given platform. If the an open stream to a deleted file is possible, it
should be provided.
If you really want to do the same thing on all platforms for the sake of
purity, then signalling an error immediately would be the way to go.
Magically closing the streams would impo be the worst option in any
case: you still get an error, but at the wrong location, leading to
reduced debuggability. That's just Wrong.
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
Sam Steingold <···@gnu.org> writes:
>> * Peter Seibel <·····@wninzbaxrl.pbz> [2004-08-09 21:40:09 +0000]:
>>
>> Sam Steingold <···@gnu.org> writes:
>>
>>> With non-silly *DEFAULT-PATHNAME-DEFAULTS* there are other issues:
>>>
>>> DELETE-FILE & RENAME-FILE are the only(?) pathname functions which
>>> appear not to satisfy the condition
>>> (X Y) == (X (PATHNAME Y))
>>
>> Why do you say that? They are both specified to take a pathname
>> designator as their first argument.
>
> after
> (setq stream (open "foo" :direction :output))
>
> form
> (delete-file stream)
>
> is not the same as
> (delete-file (pathname stream))
TRUENAME is also like this: see CLHS 20.1.1.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
From: Christopher C. Stacy
Subject: Re: (DELETE-FILE open-file-stream)
Date:
Message-ID: <un013k3s2.fsf@news.dtpq.com>
>>>>> On Mon, 09 Aug 2004 16:57:32 -0400, Sam Steingold ("Sam") writes:
Sam> How should DELETE-FILE behave on open file streams?
I'll paraphrase your questions as I understand them, and provide what
I think are the right answers. In short, it's all platform dependant.
This stems from the meaning of "deleted file" being platform dependant.
1. If DELETE-FILE is called on a stream, what happens to the stream?
The stream may or may not be closed at this point.
If it's open, output bits may or may not be going down a sink.
2. If DELETE-FILE is called on a stream, what happens to the file?
The file may or may not be "actually deleted" (whatever that means)
at this point. Possibly none of this "delete" operation takes effect
until the stream is closed. And whether that means "closed normally"
or not is also probably open to interpretation.
3. If DELETE-FILE is called on pathname while there is a stream OPEN on it,
what happens to the stream (and what happens to the file)?
The stream is not probably not automatically closed by this.
However, it's platform dependant what happens when you try to do
something to the stream. Whether the file is "deleted" at this
point is also platform dependant.
All these questions come down to what the platform does.
Some operating systems support a file operation called "Delete While Open",
which takes a stream. It is platform dependant whether this operation
is allowed on a stream that was not opened for output. What happens is that
the file is marked as deleted in the directory, which means the file may not
be normally opened by name again. All open streams to the file remain open
until explicitly closed. When the last open stream (on the whole system) to
the file is closed, the file is deleted. On some of these systems, this
deleted file may then later be opened by name again by specifying certain
parameters in the OPEN (and there's typically an "Undelete File" operation).
You have to decide what semantics you want to implement and are
possible to implement, and especially whether your semantics model
what the platform really does. (The strategy on the Lisp Machine,
which supported many different networked file systems, usually tried
to implement some ideal file system semantics, rather than exactly
model what the platform did.)