From: Richard M Kreuter
Subject: PROBE-FILE and open FILE-STREAMs
Date:
Message-ID: <8763y5qxj7.fsf@progn.net>
From the specification for PROBE-FILE:
| If the PATHSPEC designator is an open stream, then ‘probe-file’
| produces the truename of its associated file. If PATHSPEC is a
| stream, whether open or closed, it is coerced to a pathname as if by
| the function ‘pathname’.
I'm having a problem trying to make these two sentences consistent.
The second sentence seems to suggest that PROBE-FILE is supposed to do
something like this:
(defun probe-file (pathspec)
(typecase pathspec
(stream (truename (pathname stream)))
...))
I think it's relatively clear that PATHNAME on a file-stream is
supposed return the defaulted pathname supplied to OPEN, and that
TRUENAME on a pathname should do some kind of poking around in the
file system to resolve things like symbolic links, symbolic version
specifiers like "newest" or "previous", logical devices, etc.
But the first sentence cited above says that PROBE-FILE produces the
truename of the file associated with the stream. I see no reason why
the truename of the name used to open a stream is required to name the
file associated with the stream. There are a number of ways that the
name used to open a file can fail to name the file while the stream is
open:
(1) If the name used to open the file named the file through a
symbolic link, and the symbolic link is altered while the stream
is open, then the file associated with the stream will not be
named by the name used to open the file.
(2) If the name used to open the file was a logical pathname and the
pathname's host's translations change, then the file associated
with the stream will not be named by the name used to open the
stream.
(3) While I've never worked with a file system with versions, it's
possible to imagine a file system for which
(open "foo.txt.newest" :direction :output)
returns an open stream associated with "foo.txt.1", and which
permits another program to create a "foo.txt.2" while that stream
associated with "foo.txt.1" is open. In this case, the file
associated with the stream will not be named by the truename of
the pathname used to open the file.
And so on. Notice that points 1 and 3 are properties of file systems
outside the control of Lisp, and so I don't think it plausible that
the two cited sentences are supposed to imply that an implementation
is required to ensure that the pathname of a stream be a name for the
file associated with the stream for the duration of the stream's
open-ness.
So is it just me, or are the two sentences above inconsistent?
Thanks,
RmK
In article <··············@progn.net>,
Richard M Kreuter <·······@progn.net> wrote:
> From the specification for PROBE-FILE:
>
> | If the PATHSPEC designator is an open stream, then ‘probe-file’
> | produces the truename of its associated file. If PATHSPEC is a
> | stream, whether open or closed, it is coerced to a pathname as if by
> | the function ‘pathname’.
>
> I'm having a problem trying to make these two sentences consistent.
> The second sentence seems to suggest that PROBE-FILE is supposed to do
> something like this:
>
> (defun probe-file (pathspec)
> (typecase pathspec
> (stream (truename (pathname stream)))
> ...))
>
> I think it's relatively clear that PATHNAME on a file-stream is
> supposed return the defaulted pathname supplied to OPEN, and that
> TRUENAME on a pathname should do some kind of poking around in the
> file system to resolve things like symbolic links,
Symbolic Links?
> symbolic version
> specifiers like "newest" or "previous", logical devices, etc.
>
> But the first sentence cited above says that PROBE-FILE produces the
> truename of the file associated with the stream. I see no reason why
> the truename of the name used to open a stream is required to name the
> file associated with the stream. There are a number of ways that the
> name used to open a file can fail to name the file while the stream is
> open:
>
> (1) If the name used to open the file named the file through a
> symbolic link, and the symbolic link is altered while the stream
> is open, then the file associated with the stream will not be
> named by the name used to open the file.
>
> (2) If the name used to open the file was a logical pathname and the
> pathname's host's translations change, then the file associated
> with the stream will not be named by the name used to open the
> stream.
>
> (3) While I've never worked with a file system with versions, it's
> possible to imagine a file system for which
>
> (open "foo.txt.newest" :direction :output)
>
> returns an open stream associated with "foo.txt.1", and which
> permits another program to create a "foo.txt.2" while that stream
> associated with "foo.txt.1" is open. In this case, the file
> associated with the stream will not be named by the truename of
> the pathname used to open the file.
Command: (open ">joswig>foo1.text.newest" :direction :output)
#<SI:STRING-CHAR-EPSILON-OUTPUT-STREAM "RJNXP:>joswig>foo1.text.newest" 401000340>
Command: (setf foo1 *)
#<SI:STRING-CHAR-EPSILON-OUTPUT-STREAM "RJNXP:>joswig>foo1.text.newest" 401000340>
Command: (probe-file foo1)
#P"RJNXP:>joswig>foo1.text.1"
Command: (open ">joswig>foo1.text.newest" :direction :output)
#<SI:STRING-CHAR-EPSILON-OUTPUT-STREAM "RJNXP:>joswig>foo1.text.newest" 401002727>
Command: (setf foo1a *)
#<SI:STRING-CHAR-EPSILON-OUTPUT-STREAM "RJNXP:>joswig>foo1.text.newest" 401002727>
Command: (probe-file foo1a)
#P"RJNXP:>joswig>foo1.text.2"
PROBE-FILE is not returning the pathname that was used to
the call to OPEN (which interpretation might change later),
but the pathname of actual the file that was
created.
>
> And so on. Notice that points 1 and 3 are properties of file systems
> outside the control of Lisp, and so I don't think it plausible that
> the two cited sentences are supposed to imply that an implementation
> is required to ensure that the pathname of a stream be a name for the
> file associated with the stream for the duration of the stream's
> open-ness.
>
> So is it just me, or are the two sentences above inconsistent?
>
> Thanks,
> RmK
--
http://lispm.dyndns.org/
From: Richard M Kreuter
Subject: Re: PROBE-FILE and open FILE-STREAMs
Date:
Message-ID: <871w8tqtkw.fsf@progn.net>
Rainer Joswig <······@lisp.de> writes:
> In article <··············@progn.net>,
> Richard M Kreuter <·······@progn.net> wrote:
>
>> There are a number of ways that the name used to open a file can
>> fail to name the file while the stream is open...
>
> Command: (open ">joswig>foo1.text.newest" :direction :output)
> #<SI:STRING-CHAR-EPSILON-OUTPUT-STREAM "RJNXP:>joswig>foo1.text.newest" 401000340>
> Command: (setf foo1 *)
> #<SI:STRING-CHAR-EPSILON-OUTPUT-STREAM "RJNXP:>joswig>foo1.text.newest" 401000340>
> Command: (probe-file foo1)
> #P"RJNXP:>joswig>foo1.text.1"
>
> Command: (open ">joswig>foo1.text.newest" :direction :output)
> #<SI:STRING-CHAR-EPSILON-OUTPUT-STREAM "RJNXP:>joswig>foo1.text.newest" 401002727>
> Command: (setf foo1a *)
> #<SI:STRING-CHAR-EPSILON-OUTPUT-STREAM "RJNXP:>joswig>foo1.text.newest" 401002727>
> Command: (probe-file foo1a)
> #P"RJNXP:>joswig>foo1.text.2"
Please note that appealing to what implementations do is irrelevant
when reasoning about the meaning of the standard, since
implementations can fail to conform.
> PROBE-FILE is not returning the pathname that was used to
> the call to OPEN (which interpretation might change later),
> but the pathname of actual the file that was
> created.
I did not suggest that PROBE-FILE should return the pathname used to
open the file, but that it is to return the truename of the pathname
used to open the file, which, as I explained, can fail to name the
file associated with the stream over time.
In any case, your example is not sufficient to demonstrate the
conclusion you draw. You're calling PROBE-FILE on streams for which
the pathname used to open the stream is likely to name the file
associated with the stream. That is, given only what you've shown
above, these two forms
(truename (pathname stream))
(truename stream)
will return the same result. But my point is that that these two
concepts can come apart. Specifically, what /should/ (not /does/)
PROBE-FILE return for FOO1 after the second OPEN, i.e., when
#P">joswig>foo1.text.newest" is a name for the file whose truename is
"RJNXP:>joswig>foo1.text.2"?
Nevertheless, your claim might be a correct characterization of the
behavior of PROBE-FILE on a LispM. How would that behavior be
consistent with
| If PATHSPEC is a stream, whether open or closed, it is coerced to a
| pathname as if by the function `pathname'.
since PATHNAME returns the name used to open the file, and not a name
of the file associated with the stream?
--
RmK
In article <··············@progn.net>,
Richard M Kreuter <·······@progn.net> wrote:
> Rainer Joswig <······@lisp.de> writes:
> > In article <··············@progn.net>,
> > Richard M Kreuter <·······@progn.net> wrote:
> >
> >> There are a number of ways that the name used to open a file can
> >> fail to name the file while the stream is open...
> >
> > Command: (open ">joswig>foo1.text.newest" :direction :output)
> > #<SI:STRING-CHAR-EPSILON-OUTPUT-STREAM "RJNXP:>joswig>foo1.text.newest" 401000340>
> > Command: (setf foo1 *)
> > #<SI:STRING-CHAR-EPSILON-OUTPUT-STREAM "RJNXP:>joswig>foo1.text.newest" 401000340>
> > Command: (probe-file foo1)
> > #P"RJNXP:>joswig>foo1.text.1"
> >
> > Command: (open ">joswig>foo1.text.newest" :direction :output)
> > #<SI:STRING-CHAR-EPSILON-OUTPUT-STREAM "RJNXP:>joswig>foo1.text.newest" 401002727>
> > Command: (setf foo1a *)
> > #<SI:STRING-CHAR-EPSILON-OUTPUT-STREAM "RJNXP:>joswig>foo1.text.newest" 401002727>
> > Command: (probe-file foo1a)
> > #P"RJNXP:>joswig>foo1.text.2"
>
> Please note that appealing to what implementations do is irrelevant
> when reasoning about the meaning of the standard, since
> implementations can fail to conform.
You need to understand in which context the spec has been created.
The whole pathname stuff came mostly from Zetalisp and
was a simplification. For example in Zetalisp there is a hierarchy
of different pathname types with different attributes.
>
> > PROBE-FILE is not returning the pathname that was used to
> > the call to OPEN (which interpretation might change later),
> > but the pathname of actual the file that was
> > created.
>
> I did not suggest that PROBE-FILE should return the pathname used to
> open the file, but that it is to return the truename of the pathname
> used to open the file, which, as I explained, can fail to name the
> file associated with the stream over time.
The same file? foo.lisp.1 is a different file than foo.lisp.2 .
foo.lisp.newest points to what ever is newest. So while
a stream is open, I'd expect PROBE-FILE to return something
which names the file and does not change (or does change less likely).
> In any case, your example is not sufficient to demonstrate the
> conclusion you draw. You're calling PROBE-FILE on streams for which
> the pathname used to open the stream is likely to name the file
> associated with the stream. That is, given only what you've shown
> above, these two forms
>
> (truename (pathname stream))
> (truename stream)
>
> will return the same result. But my point is that that these two
> concepts can come apart. Specifically, what /should/ (not /does/)
> PROBE-FILE return for FOO1 after the second OPEN, i.e., when
> #P">joswig>foo1.text.newest" is a name for the file whose truename is
> "RJNXP:>joswig>foo1.text.2"?
foo1.text.1 . That is the file that is currently open with
the first stream. If I want to apply other functions, for example
get the file-author, I need the correct file (the one with the
version number), not newest - which is another file.
>
> Nevertheless, your claim might be a correct characterization of the
> behavior of PROBE-FILE on a LispM. How would that behavior be
> consistent with
>
> | If PATHSPEC is a stream, whether open or closed, it is coerced to a
> | pathname as if by the function `pathname'.
>
> since PATHNAME returns the name used to open the file, and not a name
> of the file associated with the stream?
It just coerces the thing to a pathname as it would call PATHNAME.
You get a pathname object back.
>
> --
> RmK
--
http://lispm.dyndns.org/
From: Richard M Kreuter
Subject: Re: PROBE-FILE and open FILE-STREAMs
Date:
Message-ID: <87wsqlp9w7.fsf@progn.net>
Rainer Joswig <······@lisp.de> writes:
> In article <··············@progn.net>,
> Richard M Kreuter <·······@progn.net> wrote:
>
>> Please note that appealing to what implementations do is irrelevant
>> when reasoning about the meaning of the standard, since
>> implementations can fail to conform.
>
> You need to understand in which context the spec has been created.
> The whole pathname stuff came mostly from Zetalisp and
> was a simplification. For example in Zetalisp there is a hierarchy
> of different pathname types with different attributes.
I do understand the context in which the spec was created, albeit only
second-hand from reading manuals and communicating with other Lispers.
However, I maintain that what the LispM did is not neither normatively
binding nor particularly relevant: the standard we have is the
standard we have, and I maintain that no matter how magical the LispMs
were, Symbolics Common Lisp can intentionally or accidentally fail to
conform to it just as any implementation can, which is why I reject
reasoning from the behaviors of implementations.
>> > PROBE-FILE is not returning the pathname that was used to
>> > the call to OPEN (which interpretation might change later),
>> > but the pathname of actual the file that was
>> > created.
>>
>> I did not suggest that PROBE-FILE should return the pathname used to
>> open the file, but that it is to return the truename of the pathname
>> used to open the file, which, as I explained, can fail to name the
>> file associated with the stream over time.
>
> The same file? foo.lisp.1 is a different file than foo.lisp.2 .
> foo.lisp.newest points to what ever is newest. So while
> a stream is open, I'd expect PROBE-FILE to return something
> which names the file and does not change (or does change less likely).
I think that's the reasonable thing for PROBE-FILE to do, and the
standard does say it should do that, but it also says that PROBE-FILE
coerces a stream to a pathname as if by PATHNAME, and that PATHNAME
returns a pathname that "corresponds to the filename used to open the
file", which I take to mean the defaulted argument to open, and not
the truename of the file associated with the stream. And this is my
problem: the two sentences in the specification for PROBE-FILE are not
consistent.
>> In any case, your example is not sufficient to demonstrate the
>> conclusion you draw. You're calling PROBE-FILE on streams for which
>> the pathname used to open the stream is likely to name the file
>> associated with the stream. That is, given only what you've shown
>> above, these two forms
>>
>> (truename (pathname stream))
>> (truename stream)
>>
>> will return the same result. But my point is that that these two
>> concepts can come apart. Specifically, what /should/ (not /does/)
>> PROBE-FILE return for FOO1 after the second OPEN, i.e., when
>> #P">joswig>foo1.text.newest" is a name for the file whose truename is
>> "RJNXP:>joswig>foo1.text.2"?
>
> foo1.text.1 . That is the file that is currently open with
> the first stream. If I want to apply other functions, for example
> get the file-author, I need the correct file (the one with the
> version number), not newest - which is another file.
That's fine, just note that PROBE-FILE is not using what PATHNAME
would return for the stream, but instead the name of the file actually
associated with the stream. That is what I'm writing about in this
thread.
Regards,
RmK
In article <··············@progn.net>,
Richard M Kreuter <·······@progn.net> wrote:
> Rainer Joswig <······@lisp.de> writes:
> > In article <··············@progn.net>,
> > Richard M Kreuter <·······@progn.net> wrote:
> >
> >> Please note that appealing to what implementations do is irrelevant
> >> when reasoning about the meaning of the standard, since
> >> implementations can fail to conform.
> >
> > You need to understand in which context the spec has been created.
> > The whole pathname stuff came mostly from Zetalisp and
> > was a simplification. For example in Zetalisp there is a hierarchy
> > of different pathname types with different attributes.
>
> I do understand the context in which the spec was created, albeit only
> second-hand from reading manuals and communicating with other Lispers.
> However, I maintain that what the LispM did is not neither normatively
> binding nor particularly relevant: the standard we have is the
> standard we have, and I maintain that no matter how magical the LispMs
> were, Symbolics Common Lisp can intentionally or accidentally fail to
> conform to it just as any implementation can, which is why I reject
> reasoning from the behaviors of implementations.
I think it is equally useless to reason from the spec
only, without trying to understand what real systems
do or did and why. You talked about version numbers
and I gave you an example. The Spec alone is useless. Especially
since the whole pathname stuff is underspecified
in the spec. At some places one can only guess what is
useful.
> >> > PROBE-FILE is not returning the pathname that was used to
> >> > the call to OPEN (which interpretation might change later),
> >> > but the pathname of actual the file that was
> >> > created.
> >>
> >> I did not suggest that PROBE-FILE should return the pathname used to
> >> open the file, but that it is to return the truename of the pathname
> >> used to open the file, which, as I explained, can fail to name the
> >> file associated with the stream over time.
> >
> > The same file? foo.lisp.1 is a different file than foo.lisp.2 .
> > foo.lisp.newest points to what ever is newest. So while
> > a stream is open, I'd expect PROBE-FILE to return something
> > which names the file and does not change (or does change less likely).
>
> I think that's the reasonable thing for PROBE-FILE to do, and the
> standard does say it should do that, but it also says that PROBE-FILE
> coerces a stream to a pathname as if by PATHNAME, and that PATHNAME
> returns a pathname that "corresponds to the filename used to open the
> file", which I take to mean the defaulted argument to open, and not
> the truename of the file associated with the stream. And this is my
> problem: the two sentences in the specification for PROBE-FILE are not
> consistent.
>
> >> In any case, your example is not sufficient to demonstrate the
> >> conclusion you draw. You're calling PROBE-FILE on streams for which
> >> the pathname used to open the stream is likely to name the file
> >> associated with the stream. That is, given only what you've shown
> >> above, these two forms
> >>
> >> (truename (pathname stream))
> >> (truename stream)
> >>
> >> will return the same result. But my point is that that these two
> >> concepts can come apart. Specifically, what /should/ (not /does/)
> >> PROBE-FILE return for FOO1 after the second OPEN, i.e., when
> >> #P">joswig>foo1.text.newest" is a name for the file whose truename is
> >> "RJNXP:>joswig>foo1.text.2"?
> >
> > foo1.text.1 . That is the file that is currently open with
> > the first stream. If I want to apply other functions, for example
> > get the file-author, I need the correct file (the one with the
> > version number), not newest - which is another file.
>
> That's fine, just note that PROBE-FILE is not using what PATHNAME
> would return for the stream, but instead the name of the file actually
> associated with the stream. That is what I'm writing about in this
> thread.
I don't understand your confusion about this - maybe it's me:
Spec for PROBE-FILE:
If the pathspec designator is an open stream, then probe-file
produces the truename of its associated file.
If pathspec is a stream, whether open or closed,
it is coerced to a pathname as if by the function pathname.
I read:
* an open stream:
it returns the truename of the pathname
* a closed stream
it returns the pathname
Like
(if (stream-open-p stream)
(truename (pathname stream))
(pathname stream))
>
> Regards,
> RmK
--
http://lispm.dyndns.org/
From: Richard M Kreuter
Subject: Re: PROBE-FILE and open FILE-STREAMs
Date:
Message-ID: <87prwdp5z8.fsf@progn.net>
Rainer Joswig <······@lisp.de> writes:
> I don't understand your confusion about this - maybe it's me:
>
> Spec for PROBE-FILE:
>
> If the pathspec designator is an open stream, then probe-file
> produces the truename of its associated file.
> If pathspec is a stream, whether open or closed,
> it is coerced to a pathname as if by the function pathname.
As I read those two sentences, both of them apply to open streams, and
they describe different effects.
The first sentence seems to say something like
(if (and (streamp pathspec) (open-stream-p pathspec))
(truename (%file-associated-with-stream pathspec)))
But the second one seems to say
(if (streamp pathspec)
(truename (pathname pathspec)))
I think we've agreed PATHNAME returns the defaulted name used to open
the file, not the name of the file associated with a stream.
Consequently these two forms will have different results on an open
stream.
> I read:
>
> * an open stream:
>
> it returns the truename of the pathname
>
> * a closed stream
>
> it returns the pathname
>
> Like
>
> (if (stream-open-p stream)
> (truename (pathname stream))
> (pathname stream))
Note that this code fragment cannot account for the behavior you've
shown the LispM expressing, because you got back the truename of the
file associated with the stream, not the truename of the result of
calling PATHNAME on the stream.
--
RmK
Richard M Kreuter <·······@progn.net> writes:
> I think that's the reasonable thing for PROBE-FILE to do, and the
> standard does say it should do that, but it also says that PROBE-FILE
> coerces a stream to a pathname as if by PATHNAME, and that PATHNAME
> returns a pathname that "corresponds to the filename used to open the
> file", which I take to mean the defaulted argument to open, and not
> the truename of the file associated with the stream. And this is my
> problem: the two sentences in the specification for PROBE-FILE are not
> consistent.
I think that the key phrase in the requirement is "corresponds to",
which seems to open up exactly the amount of wiggle room necessary to
support the behavior that was demonstrated. There is no requirement
that it return the defaulted argument to open, but merely a requirement
to return a pathname that has an appropriate connection (correspondence)
to the pathname used to open the file.
The example under the documentation, although not normative, does note
"There is a great deal of variability permitted here."
--
Thomas A. Russ, USC/Information Sciences Institute
From: Richard M Kreuter
Subject: Re: PROBE-FILE and open FILE-STREAMs
Date:
Message-ID: <87lk6zpwil.fsf@progn.net>
···@sevak.isi.edu (Thomas A. Russ) writes:
> Richard M Kreuter <·······@progn.net> writes:
>
>> I think that's the reasonable thing for PROBE-FILE to do, and the
>> standard does say it should do that, but it also says that PROBE-FILE
>> coerces a stream to a pathname as if by PATHNAME, and that PATHNAME
>> returns a pathname that "corresponds to the filename used to open the
>> file", which I take to mean the defaulted argument to open, and not
>> the truename of the file associated with the stream. And this is my
>> problem: the two sentences in the specification for PROBE-FILE are not
>> consistent.
>
> I think that the key phrase in the requirement is "corresponds to",
> which seems to open up exactly the amount of wiggle room necessary to
> support the behavior that was demonstrated. There is no requirement
> that it return the defaulted argument to open, but merely a requirement
> to return a pathname that has an appropriate connection (correspondence)
> to the pathname used to open the file.
It's true that there's wiggle room in the specification for PATHNAME,
but that's irrelevant. PATHNAME on a stream has to return the same
pathname whether the stream is open or closed, and so it cannot be
required return the name of the file associated with the stream, since
that file might have a different name after closing the stream.
> The example under the documentation, although not normative, does
> note "There is a great deal of variability permitted here."
Right, but the last example in that dictionary entry shows PATHNAME on
an open stream returning a pathname whose version is "newest", which
is exactly the sort of thing I'm talking about: a pathname with a
version of :NEWEST necessarily refers to different filenames over
time, and can refer to different filenames while the stream is open,
as Rainer Joswig showed in his examples.
Here are a bunch of examples of ways that what PATHNAME returns for a
stream can fail to name the file associated with the stream, and so
cannot reasonably be used in PROBE-FILE. I think all of the following
are plausible behavior on conforming Lisps, though I'm only really
familiar with Unix and logical pathname "file systems". Notice that
the first is required behavor of a conforming Lisp.
;;; Example 1: a logical pathname host whose translations change while
;;; the stream is open.
(setf (logical-pathname-translations "HOME") ())
=> NIL
;; The following translations seem as though they ought to work for
;; any hierarchical file system, though the results print in an
;; implementation-dependent way.
(setf (logical-pathname-translations "HOME")
(list
(list (make-pathname :host "HOME"
:directory '(:absolute :wild)
:name :wild :type :wild :version :wild)
(merge-pathnames
(make-pathname :directory '(:relative :wild)
:name :wild :type :wild :version :wild)
(user-homedir-pathname)))))
=> ((#P"HOME:*;*.*.*" #P"/home/kreuter/*/*.*"))
(setf *s* (open (ensure-directories-exist "HOME:SUBDIR;FOO.LISP.NEWEST")
:direction :output :if-exists :rename-and-delete))
=> #<File-Stream ...>
;; Notice that PATHNAME must return logical pathname in this case.
(pathname *s*)
=> #P"HOME:SUBDIR;FOO.LISP.NEWEST"
(truename #P"HOME:SUBDIR;FOO.LISP.NEWEST")
=> #P"/home/kreuter/subdir/foo.lisp"
(truename (pathname *s*))
=> #P"/home/kreuter/subdir/foo.lisp"
(setf (logical-pathname-translations "HOME")
(list
(list (make-pathname :host "HOME"
:directory '(:absolute :wild)
:name :wild :type :wild :version :wild)
(make-pathname :directory '(:absolute :wild)
:name :wild :type :wild :version :wild))))
=> ((#P"HOME:*;*.*.*" #P"/*/*.*"))
(truename #P"HOME:SUBDIR;FOO.LISP.NEWEST")
!! No such file: /subdir/foo.lisp
(truename (pathname *s*))
!! No such file: /subdir/foo.lisp
;;; Example 2: a system with symbolic links where a symlink is
;;; replaced while the stream is open.
;; Suppose a Unix with symbolic links, a Lisp whose namestring syntax
;; resembles filename syntax for alphapbetic characters and slash,
;; that resolves symbolic links as part of TRUENAME, and that has a
;; function called SYMLINK that takes two strings and passes them to
;; the symlink(2) system call, and returns T in case a symbolic link
;; is created.
(setf *default-pathname-defaults* (pathname "/tmp/"))
=> #P"/tmp/"
;; Use OPEN to create a new file.
(close (open "foo" :direction :output :if-exists :rename-and-delete))
=> #<File-Stream ...>
(symlink "/tmp/foo" "/tmp/symlink")
=> T
(setf *s* (open "symlink"))
=> #<File-Stream ...>
(pathname *s*)
=> #P"/tmp/symlink"
(truename #P"/tmp/symlink")
=> #P"/tmp/foo"
(truename (pathname *s*))
=> #P"/tmp/foo"
;; Replace the symbolic link
(symlink "/tmp/foo" "/bin/sh")
=> T
(truename #P"/tmp/symlink")
=> #P"/bin/sh"
(truename (pathname *s*))
=> #P"/bin/sh"
;;; Example 3: a Windows file system with junction points that change
;;; while the stream is open. (I'm not really a Windows user, but I
;;; think I've verified that it's possible to delete a reparse point
;;; while a program has a file that's been opened through the reparse
;;; point's name. In this respect they're like a restricted kind of
;;; symbolic link, I suppose.)
;; Suppose a Lisp implementation with access to a Windows file system
;; with an established junction point C:\usbstick that mounts E:\, and
;; suppose that the Lisp that resolves reparse points as part of
;; TRUENAME, and that the Lisp has a function, RUN-COMMAND, that runs
;; a system command given as a string.
(setf *s* (open "C:\\usbstick\\file.txt"
:direction :output :if-exists :supersede))
=> #<File-Stream>
(pathname *s*)
=> #P"C:\\usbstick\\file.txt"
(truename #P"C:\\usbstick\\file.txt")
=> #P"E:\\file.txt"
(truename (pathname *s*))
=> #P"E:\\file.txt"
(run-command "mountvol C:\\usbstick /D")
=> ;; irrelevant
(truename #P"C:\\usbstick\\file.txt")
!! Error: no such file C:\\usbstick\\file.txt
(truename (pathname *s*))
!! Error: no such file C:\\usbstick\\file.txt
;;; Example 4: a versioning file system where a new version of a file
;;; is created while the stream is open
;; Suppose a Lisp implementation with access a TOPS-20 file system.
;; (I've only logged on to a TOPS-20 system a few times, and so am
;; mostly working from a manual in this example.) Note that in
;; TOPS-20 file specification syntax, the generation number 0 refers
;; to the newest version, the generation number -3 is a wildcard that
;; matches all versions.
;; Ensure that there are no versions of any file with name "FOO" and
;; type "TXT" in my log-in directory.
(mapc #'delete-file (directory "DSK:<ME>FOO.TXT.-3"))
=> ;; irrelevant
(setf *s* (open #P"DSK:<ME>FOO.TXT.0" :direction :output))
=> #<File-Stream ...>
(pathname *s*)
=> #P"DSK:<ME>FOO.TXT.0"
(truename #P"DSK:<ME>FOO.TXT.0")
=> #P"DSK:<ME>FOO.TXT.1"
(truename (pathname *s*))
=> #P"DSK:<ME>FOO.TXT.1"
(close (open #P"DSK:<ME>FOO.TXT.0" :direction :output
:if-exists :new-version))
=> #<File-Stream ...>
(truename #P"DSK:<ME>FOO.TXT.0")
=> #P"DSK:<ME>FOO.TXT.2"
(truename (pathname *s*))
=> #P"DSK:<ME>FOO.TXT.2"
In all these examples, if PROBE-FILE employs what PATHNAME returns for
the stream, then PROBE-FILE probes for the wrong file over time.
--
RmK