Here is a really complicated use of make-pathname:
(make-pathname :device "D" :directory '(:absolute "_distro"))
Incredible, right? No wonder diff vendors of Lisps for Win32 come up
with diff results!
ACL: #p"D:\\_distro\\"
Corman: #P"D:\_distro\"
LW: #P":D:/_distro/"
See that LW version? See that cute little colon in front of the drive
letter D? It has the neat effect of making probe-file not find anything
that uses that pathname.
I imagine it has something to do with hosts, but I just need that colon
to go away. Along with the entire pathname scheme, but I'll be happy if
I can just get LW to stop putting that colon up front.
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
On Sun, Jan 26, 2003 at 10:32:38PM +0000, Kenny Tilton wrote:
> ACL: #p"D:\\_distro\\"
> Corman: #P"D:\_distro\"
> LW: #P":D:/_distro/"
>
> See that LW version? See that cute little colon in front of the drive
> letter D? It has the neat effect of making probe-file not find anything
> that uses that pathname.
Isn't it great? It's actually because LispWorks interprets the HOST
parameter as the drive letter, and Allegro interprets the DEVICE
parameter as the drive letter. I wish they would agree, but...
(It seems to me that HOST would make more sense if it were interpreted
by LispWorks as the CIFS host. I think Allegro does this. But it's
probably too late to change now...)
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
"Matthew Danish" <·······@andrew.cmu.edu> wrote in message ··························@lain.cheme.cmu.edu...
> On Sun, Jan 26, 2003 at 10:32:38PM +0000, Kenny Tilton wrote:
> > ACL: #p"D:\\_distro\\"
> > Corman: #P"D:\_distro\"
> > LW: #P":D:/_distro/"
> >
> > See that LW version? See that cute little colon in front of the drive
> > letter D? It has the neat effect of making probe-file not find anything
> > that uses that pathname.
>
> Isn't it great? It's actually because LispWorks interprets the HOST
> parameter as the drive letter, and Allegro interprets the DEVICE
> parameter as the drive letter. I wish they would agree, but...
>
> (It seems to me that HOST would make more sense if it were interpreted
> by LispWorks as the CIFS host. I think Allegro does this. But it's
> probably too late to change now...)
>
Well, it gets weirder, the length of the string matters...
CL-USER 13 > (make-pathname :host "localhost" :device "d" :directory '(:absolute "_distro"))
#P"\\\\localhost\\_distro\\"
CL-USER 14 > (make-pathname :host "a" :device "d" :directory '(:absolute "_distro"))
#P"a:d:/_distro/"
--
Geoff
Matthew Danish wrote:
> On Sun, Jan 26, 2003 at 10:32:38PM +0000, Kenny Tilton wrote:
>
>>ACL: #p"D:\\_distro\\"
>>Corman: #P"D:\_distro\"
>>LW: #P":D:/_distro/"
>>
>>See that LW version? See that cute little colon in front of the drive
>>letter D? It has the neat effect of making probe-file not find anything
>>that uses that pathname.
>
>
> Isn't it great? It's actually because LispWorks interprets the HOST
> parameter as the drive letter, and Allegro interprets the DEVICE
> parameter as the drive letter. I wish they would agree, but...
Or they could address it in their documentation. Maybe I missed it, but
I knew this crap was vendor-deliberately-inconsistent <g> so I looked
for LW doc on this, no luck.
Ok, thx, substituting :host "D" for :device "D" works dandy. I'm gonna
hate LW for a month over this. I'm ready for some football.
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<··············@nyc.rr.com>...
> Here is a really complicated use of make-pathname:
>
> (make-pathname :device "D" :directory '(:absolute "_distro"))
>
> Incredible, right? No wonder diff vendors of Lisps for Win32 come up
> with diff results!
The short answer is that LW uses HOST where others use DEVICE, as
others have pointed out. I'm not actually sure which is right, though
I think I prefer the the others. I guess it depends to some extent on
how Windows thinks of pathnames, and the interesting case would be the
\\x\y\z style names - does Windows think of the x name there as the
same as a drive letter?
Anyway, practically, what I do is never to start from nothing when
making a path, but instead to merge / default from an existing path
which came from a string. This avoids issues about what bits of
syntax correspond to what element in a pathname. However it doesn't
let you say `I want drive D' without constructing a string and parsing
it.
--tim
Tim Bradshaw wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<··············@nyc.rr.com>...
>
>>Here is a really complicated use of make-pathname:
>>
>> (make-pathname :device "D" :directory '(:absolute "_distro"))
>>
>>Incredible, right? No wonder diff vendors of Lisps for Win32 come up
>>with diff results!
>
>
> The short answer is that LW uses HOST where others use DEVICE, as
> others have pointed out. I'm not actually sure which is right, though
> I think I prefer the the others. I guess it depends to some extent on
> how Windows thinks of pathnames, and the interesting case would be the
> \\x\y\z style names - does Windows think of the x name there as the
> same as a drive letter?
I did break down and give LW my NT system's network moniker
(OMIGODKENNY) as the host in one desperate attempt at a workaround.
Probe-file on the \\\OMIGODKENNY\\D\\etc result actually went away for
five seconds (presumably dashing out my cable modem to South Park for a
quick look around) before returning nil. :)
>
> Anyway, practically, what I do is never to start from nothing when
> making a path, but instead to merge / default from an existing path
> which came from a string. This avoids issues about what bits of
> syntax correspond to what element in a pathname.
Ah, never thought of that: eliminate the colon using the editor <g>:
(make-pathname
:name "uffi" :case :local :type "asd"
:defaults #P"D:/_distro/uffi/"
:version :newest)
That would have worked. But am I right that the string itself would not
be portable because of diff ways of separating the directory levels?
Kind of a pick-your-poison situation, I guess. Thx for the idea.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<··············@nyc.rr.com>...
> That would have worked. But am I right that the string itself would not
> be portable because of diff ways of separating the directory levels?
> Kind of a pick-your-poison situation, I guess. Thx for the idea.
Yes, I think it fairly obviously isn't (although, in practice, I've
never seen a system which doesn't happily accept / as the Windows
pathname separator).
For my purposes, I take the approach that the application should
really only ever take pathnames `provided by the user' and then
compute other pathnames from them. Further, if it's going to be mildly
portable between OSs (as well as Lisp implementions) it really can
only reason about directories and filenames, not devices and hosts -
Unix, say doesn't really have a notion of a host or device in a
pathname (someone is going to point out that there is actually some
obscure posix (?) thing which is //x/y/... where x might be a host or
device). If I can live with those restrictions (and in particular if
I don't worry about FSs which have directories less structured than
Unix/Windows), then it's pretty possible to be portable, I think. The
crucial trick is that all the actual names you start from come `from
the user' or in real life from config files rather than being wired
in.
Of course, not all programs can make these assumptions.
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<··············@nyc.rr.com>...
>
> > That would have worked. But am I right that the string itself would not
> > be portable because of diff ways of separating the directory levels?
> > Kind of a pick-your-poison situation, I guess. Thx for the idea.
>
> Yes, I think it fairly obviously isn't (although, in practice, I've
> never seen a system which doesn't happily accept / as the Windows
> pathname separator).
The Windows kernel API accepts '/' as the pathname separator, so
unless an application goes out of its way to prohibit this, it will
work.
Kenny Tilton <·······@nyc.rr.com> writes:
> Here is a really complicated use of make-pathname:
>
> (make-pathname :device "D" :directory '(:absolute "_distro"))
>
> Incredible, right? No wonder diff vendors of Lisps for Win32 come up
> with diff results!
>
> ACL: #p"D:\\_distro\\"
> Corman: #P"D:\_distro\"
> LW: #P":D:/_distro/"
>
> See that LW version? See that cute little colon in front of the drive
> letter D? It has the neat effect of making probe-file not find
> anything that uses that pathname.
>
> I imagine it has something to do with hosts, but I just need that
> colon to go away. Along with the entire pathname scheme, but I'll be
> happy if I can just get LW to stop putting that colon up front.
Well, this also bugs me, but I believe it's actually defensible.
Keep in mind that a "file host" is not necessarily a network host.
In some file systems, this matters because the file syntax can vary
between things you might think are "devices".
So, for example, if one disk is a DOS disk and another is an NTFS
disk, there might be subtle differences between the possible filenames
for that disk. This might not matter so much any more, but might have
at one time, and might again in the future.
If you require "D" to be just a device, you're assuming that all devices
on the "host" file system use the same syntax. The reason for this is that
a lot of implementations issue namestring parsers on a per-host basis.
(Even PARSE-NAMESTRING takes a relative-to-host argument but not a
relative-to-device argument.
Too little work was done between vendors to coordinate certain common
decisions, and that's clearly lamentable. That could be fixed by a
layered standard without changing the underlying standard, which is
clearly good. It hasn't been though, which is again lamentable...
But at least in the interim the individual vendors have the capability
to be conforming and to do what they feel is right, and at least you
can figure out how to get work done with a small amount of work on
your own part. I think in general it's pretty easy to build
compatibility interfaces over these small glitches...
Kent M Pitman <······@world.std.com> writes:
> Too little work was done between vendors to coordinate certain common
> decisions, and that's clearly lamentable. That could be fixed by a
> layered standard without changing the underlying standard, which is
> clearly good. It hasn't been though, which is again lamentable...
> But at least in the interim the individual vendors have the capability
> to be conforming and to do what they feel is right, and at least you
> can figure out how to get work done with a small amount of work on
> your own part. I think in general it's pretty easy to build
> compatibility interfaces over these small glitches...
Er, this isn't as easy as it may at first appear. (At least, doing a
good, general, file-system/pathname interface. It's not too bad to
hack out something that will read/write a file.)
Joe Marshall <···@ccs.neu.edu> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Too little work was done between vendors to coordinate certain common
> > decisions, and that's clearly lamentable. That could be fixed by a
> > layered standard without changing the underlying standard, which is
> > clearly good. It hasn't been though, which is again lamentable...
> > But at least in the interim the individual vendors have the capability
> > to be conforming and to do what they feel is right, and at least you
> > can figure out how to get work done with a small amount of work on
> > your own part. I think in general it's pretty easy to build
> > compatibility interfaces over these small glitches...
>
> Er, this isn't as easy as it may at first appear. (At least, doing a
> good, general, file-system/pathname interface. It's not too bad to
> hack out something that will read/write a file.)
Let me correct what I said slightly--writing a good _general purpose_
set of tools that you could feel good advertising to others is tricky.
I think writing something idiosyncratic to a given system, which works
around exactly the problems the system in question is dealing with, usually
turns out to not be that bad.
I guess what I really meant was less to make a claim of easy
generality and more to make a claim that I don't see it as a serious
barrier to any particular system being made to work "well enough".
Kent M Pitman <······@world.std.com> writes:
> Let me correct what I said slightly--writing a good _general purpose_
> set of tools that you could feel good advertising to others is tricky.
> I think writing something idiosyncratic to a given system, which works
> around exactly the problems the system in question is dealing with, usually
> turns out to not be that bad.
>
> I guess what I really meant was less to make a claim of easy
> generality and more to make a claim that I don't see it as a serious
> barrier to any particular system being made to work "well enough".
I agree.
But it'd sure be nice to fix pathnames once and for all....
Kent M Pitman wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Here is a really complicated use of make-pathname:
>>
>> (make-pathname :device "D" :directory '(:absolute "_distro"))
>>
>>Incredible, right? No wonder diff vendors of Lisps for Win32 come up
>>with diff results!
>>
>>ACL: #p"D:\\_distro\\"
>>Corman: #P"D:\_distro\"
>>LW: #P":D:/_distro/"
>>
>>See that LW version? See that cute little colon in front of the drive
>>letter D? It has the neat effect of making probe-file not find
>>anything that uses that pathname.
>>
>>I imagine it has something to do with hosts, but I just need that
>>colon to go away. Along with the entire pathname scheme, but I'll be
>>happy if I can just get LW to stop putting that colon up front.
>
>
> Well, this also bugs me, but I believe it's actually defensible.
>
> Keep in mind that a "file host" is not necessarily a network host.
OK, thx for filling in the rationale for what I stumbled over.
> I think in general it's pretty easy to build
> compatibility interfaces over these small glitches...
Yes, and hopefully it is clear to all that I am just a whiner who comes
here to bore the world with his problems when i run into a little
difficulty.
Can you imagine what a wreck I'd be without UFFI?
The fact is, anyone trying to deliver a package that runs on every Lisp
platform is bound to have such difficulties, and by the same token can
be expected to know his way around Lisp (which I do not, not at the
level of youse guys and gals). The only problems I am having are at the
clearly marked "implementation-dependent" boundaries.
Like I said, I'm just a whiner. :) Well, OK, I guess my strength was
sapped by having OpenGL kick my ass from one corner to another of the
viewing frustrum... good excuse?
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Kenny Tilton <·······@nyc.rr.com> writes:
> The fact is, anyone trying to deliver a package that runs on every
> Lisp platform is bound to have such difficulties, and by the same
> token can be expected to know his way around Lisp (which I do not, not
> at the level of youse guys and gals). The only problems I am having
> are at the clearly marked "implementation-dependent" boundaries.
Try doing it in Java!
There are some wonderful idiosyncracies there. For instance, if you
want to list a directory under Windows, you had better leave off the
slash at the end or you won't get anything. Except in the case of the
root directory - you have to leave the slash.
list ("D:\\Foo\\") => null
list ("D:\\Foo") => ["bar.txt" "baz.txt"]
list ("D:\\") => ["Foo" "WINNT"]
list ("D:") => null
The isReadOnly() method will tell you if the file cannot be written,
but until Java 2 there was no way of modifying that bit. It is
unclear what making a file unwritable means on Unix (no doubt there is
some convention, but it isn't spelled out in the documentation for
setReadOnly()).
Joe Marshall <···@ccs.neu.edu> writes:
> Try doing it in Java!
>
> There are some wonderful idiosyncracies there. For instance, if you
> want to list a directory under Windows, you had better leave off the
> slash at the end or you won't get anything. Except in the case of the
> root directory - you have to leave the slash.
I believe this is Windows being insane, not Java. At least Python has
similar issues, and that's the excuse we always use :-)
Dealing with UNC paths is yet more fun, AIUI (not very well, luckily
for me).
Cheers,
M.
--
6. Symmetry is a complexity-reducing concept (co-routines include
subroutines); seek it everywhere.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
Michael Hudson <···@python.net> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
> > Try doing it in Java!
> >
> > There are some wonderful idiosyncracies there. For instance, if you
> > want to list a directory under Windows, you had better leave off the
> > slash at the end or you won't get anything. Except in the case of the
> > root directory - you have to leave the slash.
>
> I believe this is Windows being insane, not Java.
Well, perhaps the insanity *originates* in Windows, but the point is
that the Java file API is an *extremely* thin layer on top of the OS
and provides little more than a crippled API to the native code.
Writing portable code in this is a nightmare.
Lisp, at least, makes an attempt to abstract away the details of the
file system by providing pathnames. You can actually get away with
writing code portable across OS's. The difficulty is that it is hard
to write code that is portable among different Lisp implementations
(sigh). But still, it is more likely that you would choose one
implementation and deliver on several platforms than it is you would
choose multiple implementations and deliver on a single platform.
> At least Python has similar issues, and that's the excuse we always
> use :-)
Just because every OS provides a string-based API to their file system
doesn't mean that the user should be pasting strings!
> Dealing with UNC paths is yet more fun, AIUI (not very well, luckily
> for me).
I *think* that UNC paths are a tad easier because they don't have
drives and colons (so the syntax is more uniform. I could be wrong,
and unfortunately, UNC pathnames are not completely portable within
the Win32 API). The real problem is mixing UNC, DOS, and Unix paths
in the same environment (and trying to merge a relative pathname that
came from Unix with an absolute pathname that comes from DOS, or
vice-versa).
Joe Marshall <···@ccs.neu.edu> writes:
> Lisp, at least, makes an attempt to abstract away the details of the
> file system by providing pathnames. You can actually get away with
> writing code portable across OS's. The difficulty is that it is hard
> to write code that is portable among different Lisp implementations
> (sigh).
At least in my limited experience (having recently ported a commercial
application across implementations and operating systems), you can get
around a lot of those difficulties by using logical pathnames whenever
possible. I kept all my logical pathname definitions in a single file
and other then modifying those I didn't have to do anything else
pathname-related for the port.
Gabe Garza
Kenny Tilton <·······@nyc.rr.com> writes:
> Corman: #P"D:\_distro\"
Other issues aside, are you sure this isn't a bug in Corman?
Looks like too few backslashes here.
Kenny Tilton <·······@nyc.rr.com> writes:
> Here is a really complicated use of make-pathname:
>
> (make-pathname :device "D" :directory '(:absolute "_distro"))
>
Other than discussing the behavior of make-pathname, do you have
something which you cannot do portable? Perhaps if you state your
problem, people here can help design a more portable solution (than
using make-pathname). I find I rarely need to use make-pathname.
Kevin
Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> I find I rarely need to use make-pathname.
Really?
I find that I rely on make-pathname *exclusively* for manipulating
pathnames because its behavior is well defined.
Except that on Franz Allegro on one platform (was it windows?) I had
to advise make-pathname to let me use all six slots. Grrr.
Joe Marshall <···@ccs.neu.edu> writes:
> Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
>
> > I find I rarely need to use make-pathname.
>
> Really?
>
> I find that I rely on make-pathname *exclusively* for manipulating
> pathnames because its behavior is well defined.
Again, I'd like to see some examples that support this. I'm not
saying I don't believe you, I'm saying I haven't experienced this and
I'm having trouble seeing what you mean.
Kevin
Kevin Layer <·····@--you-know-what-to-remove--.franz.com> wrote in message news:<··············@--you-know-what-to-remove--.franz.com>...
> Again, I'd like to see some examples that support this. I'm not
> saying I don't believe you, I'm saying I haven't experienced this and
> I'm having trouble seeing what you mean.
>
I'd like to see some examples too. I don't have access to my large
filename-bashing system right now, but I'm fairly sure I almost never
use MAKE-PATHNAME. On the other hand, my system only runs in one
implementation right now for reasons that (should be!) unrelated to
pathnames, so I haven't had a chance to test if my
`trying-to-be-portable' pathname bashing code actually is.
(The biggest problem I've had in the entire life of the thing is that
rsync absolutely *knows* that pathnames with colons in are
host:path-on-host, so if you are using WIndows then ... well, you
basically can't use rsync without jumping through lots of hoops. And
people complain about CL pathnames...)
--tim
Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
> > Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> >
> > > I find I rarely need to use make-pathname.
> >
> > Really?
> >
> > I find that I rely on make-pathname *exclusively* for manipulating
> > pathnames because its behavior is well defined.
>
> Again, I'd like to see some examples that support this. I'm not
> saying I don't believe you, I'm saying I haven't experienced this and
> I'm having trouble seeing what you mean.
Ok, I'll dig some up when I get home. But I suspect we might be
misinterpreting each other. I *do* use other pathname functions like
merge-pathnames, pathname-directory, etc., but I rarely use the
#P"/usr/bin/foo" syntax or operate on namestrings. This isn't to say
that they *couldn't* be used, but that the behavior of the
string<->pathname mapping is just not uniform enough when dealing with
multiple lisp implementations on multiple OS platforms.
At Content Integrity our product was a source-code management system
written in Franz Allegro CL. We developed it under NT, but released
under NT, HP-UX, and Linux. The server supported remote and local
clients. It had to grok NT pathnames and Unix pathnames and both
kinds of pathnames as seen through the eyes of Java (Sun Java on Unix
and either Sun or MS Java on NT), and either kind of pathname as seen
via the OS. Our goals were that it wouldn't matter what platform the
server ran on, that if all the clients were on homogeneous platforms
you'd get out of the system *exactly* what you put in, and if the
clients were on heterogeneous platforms you'd get out of the system
something as close as possible as what you put in (with certain
configuration settings to resolve the problems between creating
isomorphic mappings between NT and Unix file systems).
We learned fairly quickly to pay extremely close attention to
pathnames.
Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
> > Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> >
> > > I find I rarely need to use make-pathname.
> >
> > Really?
> >
> > I find that I rely on make-pathname *exclusively* for manipulating
> > pathnames because its behavior is well defined.
>
> Again, I'd like to see some examples that support this. I'm not
> saying I don't believe you, I'm saying I haven't experienced this and
> I'm having trouble seeing what you mean.
Here are some examples:
I have a project that spans multiple directories. The `build' scripts
live in the `build' directory. They include lisp DEFSYSTEM files,
package files, and other random stuff. Since the various developers
have their own way of launching lisp, the `current directory' when
lisp starts may be the root of the project, the build directory, the
user's home directory, the directory where lisp is installed, or
something else. So in order to find the root of the project, we look
at the *load-truename* and merge it with
(make-pathname :directory '(:relative :back) :defaults "")
Another example is when calling DIRECTORY. Besides the fact that it
does different things on different lisps, some lisps return pathnames
with the last directory component in the :name component (or in the
name and type components if there is a dot in the directory name!)
Furthermore, depending on the list, the names are not canonicalized:
(directory ".") => '("./." "./.." "./foo" "./bar" ...)
The only reasonable thing to do here was to write my own directory
function that called the internal one and rebuild the result.
There is an ambiguity with names like ".foo" Is it a file with an
empty string for a name and a type "foo", or is it a file with a dot
in the name and no type? (Heh, it might even be a directory...) What
will I get if I try to parse a namestring like this? What do I get if
*default-pathname-defaults* gets set to this?! Different lisps again
do different things. However, make-pathname is unambiguous.
Joe Marshall <···@ccs.neu.edu> writes:
> Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
>
> > Joe Marshall <···@ccs.neu.edu> writes:
> >
> > > Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> > >
> > > > I find I rarely need to use make-pathname.
> > >
> > > Really?
> > >
> > > I find that I rely on make-pathname *exclusively* for manipulating
> > > pathnames because its behavior is well defined.
> >
> > Again, I'd like to see some examples that support this. I'm not
> > saying I don't believe you, I'm saying I haven't experienced this and
> > I'm having trouble seeing what you mean.
>
> Here are some examples:
>
> I have a project that spans multiple directories. The `build' scripts
> live in the `build' directory. They include lisp DEFSYSTEM files,
> package files, and other random stuff. Since the various developers
> have their own way of launching lisp, the `current directory' when
> lisp starts may be the root of the project, the build directory, the
> user's home directory, the directory where lisp is installed, or
> something else. So in order to find the root of the project, we look
> at the *load-truename* and merge it with
>
> (make-pathname :directory '(:relative :back) :defaults "")
Can you tell me how the above call to make-pathname and the following
differ?
(pathname "../")
Is not the `pathname' version completely equivalent? I would also
think it is immune to changes in the internal representation of
pathnames, too (not that this is much of an issue given the example).
> Another example is when calling DIRECTORY. Besides the fact that it
> does different things on different lisps, some lisps return pathnames
> with the last directory component in the :name component (or in the
> name and type components if there is a dot in the directory name!)
> Furthermore, depending on the list, the names are not canonicalized:
> (directory ".") => '("./." "./.." "./foo" "./bar" ...)
>
> The only reasonable thing to do here was to write my own directory
> function that called the internal one and rebuild the result.
I can understand that. I wonder if you can do what you need to do, in
each lisp, without using make-pathname.
> There is an ambiguity with names like ".foo" Is it a file with an
> empty string for a name and a type "foo", or is it a file with a dot
> in the name and no type? (Heh, it might even be a directory...) What
> will I get if I try to parse a namestring like this? What do I get if
> *default-pathname-defaults* gets set to this?! Different lisps again
> do different things. However, make-pathname is unambiguous.
This is the one case where I think make-pathname use is perfectly OK.
(merge-pathnames (make-pathname :name ".foo") ...)
`name' and `type' are unlikely to get you into trouble.
Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> > (make-pathname :directory '(:relative :back) :defaults "")
>
> Can you tell me how the above call to make-pathname and the following
> differ?
>
> (pathname "../")
Sure. On the Macintosh and other file systems (Multics, ITS,
...), "../" is just a filename. On some operating systems, only one
dot is permitted (VAX, TOPS-20, ...). On some file systems (ISO9000,
Lisp logical pathname), "/" is an illegal character (and there may or
may not be problems with the dots).
Kent M Pitman <······@world.std.com> writes:
> Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
>
> > > (make-pathname :directory '(:relative :back) :defaults "")
> >
> > Can you tell me how the above call to make-pathname and the following
> > differ?
> >
> > (pathname "../")
>
> Sure. On the Macintosh and other file systems (Multics, ITS,
> ...), "../" is just a filename. On some operating systems, only one
> dot is permitted (VAX, TOPS-20, ...). On some file systems (ISO9000,
> Lisp logical pathname), "/" is an illegal character (and there may or
> may not be problems with the dots).
Let me refine my question. Do the above two differ on any
platform/lisp combo that you, Joe, care about?
Btw, Allegro CL doesn't run on any of the systems you mentioned.
Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> >
> > > > (make-pathname :directory '(:relative :back) :defaults "")
> > >
> > > Can you tell me how the above call to make-pathname and the following
> > > differ?
> > >
> > > (pathname "../")
> >
> > Sure. On the Macintosh and other file systems (Multics, ITS,
> > ...), "../" is just a filename. On some operating systems, only one
> > dot is permitted (VAX, TOPS-20, ...). On some file systems (ISO9000,
> > Lisp logical pathname), "/" is an illegal character (and there may or
> > may not be problems with the dots).
>
> Let me refine my question. Do the above two differ on any
> platform/lisp combo that you, Joe, care about?
>
> Btw, Allegro CL doesn't run on any of the systems you mentioned.
It is true that I don't much care about VAX, ITS, or TOPS-20, but
MacIntosh is one market that we couldn't ignore (but I assume I could
use Unix pathnames with OSX at this point). But I didn't see any
documentation that required ".." to parse as :BACK rather than :UP,
and in fact there is one lisp where pathnames with :UP in them print
with ".." (so much for read-print consistency).
So I suppose I *could* have used (pathname "../") (and I never said
that couldn't) but I think
(make-pathname :directory '(:relative :back) :defaults "") is more
robust and clearer in intent.
Joe Marshall <···@ccs.neu.edu> writes:
> It is true that I don't much care about VAX, ITS, or TOPS-20, but
> MacIntosh is one market that we couldn't ignore (but I assume I could
> use Unix pathnames with OSX at this point). But I didn't see any
> documentation that required ".." to parse as :BACK rather than :UP,
> and in fact there is one lisp where pathnames with :UP in them print
> with ".." (so much for read-print consistency).
>
> So I suppose I *could* have used (pathname "../") (and I never said
> that couldn't) but I think
> (make-pathname :directory '(:relative :back) :defaults "") is more
> robust and clearer in intent.
Isn't that what I said? ;)
[The rest of this not directed at Joe but at least a little at Kevin
and perhaps, too, at a more general group of similarly minded folks
that he is perhaps unintentionally representing at this moment in my
mind...]
Why is it that every time I cite ITS or TOPS-20 someone thinks that I'm
suggesting a trip back in time. It's weird that no one ever thinks these
are just existence proofs that things can change over time, and that time
runs forward as well as backward.
It's almost as if people think that industry is converging on the one
and only one true file system. If it is, that's REALLY REALLY sad
because I can assure you that some extremely good features have been lost
along the way that might want to be reinvented. And some future operating
systems might diverge, just as past ones have.
Now, some people may not care if their code runs in those future operating
systems, but in the past I have seen that attitude taken and all it did was
mean a lot of needless porting work because it was possible to anticipate
the changes and not to have to do that porting work by simply having written
things portably.
Portability works in 4 dimensions, not three. The fourth being time.
Any time you see someone trying to universally quantify across all extant
implementations to decide to write their code, you know they are selling
short on the future.
My question (about the platforms Joe cares about) seems reasonable to
me. If every time I have to program a solution, I have to think about
previous systems (which I consider obsolete, because they are old and
I'm not using them) and future system (that I cannot envision),
wouldn't that make programming more difficult?
I also don't see how using make-pathname, in this case, will change
anything. If "../" isn't recognized by the implementation's operating
system, then :back or :up in the directory component surely would not
be either.
I want to highlight my original point:
When you use make-pathname to construct a pathname you make be using
internal knowledge about the implementation (e.g., that Allegro uses
the `device' for drive), and that is *not* portable.
Further, I stated that if shown examples, I could come up with more
portable ways to solve the problem, other than using make-pathname.
Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> I also don't see how using make-pathname, in this case, will change
> anything. If "../" isn't recognized by the implementation's operating
> system, then :back or :up in the directory component surely would not
> be either.
Huh? Surely there could exist operating systems that define a :back or
:up syntax that wouldn't use ".."! Besides, since :back is a
syntactic operation, not a semantic one, it makes sense to place :back
in a relative pathname for the purposes of merging it at a later time,
even if the OS in question has no notion of :back whatsoever.
> I want to highlight my original point:
>
> When you use make-pathname to construct a pathname you make be using
> internal knowledge about the implementation (e.g., that Allegro uses
> the `device' for drive), and that is *not* portable.
>
> Further, I stated that if shown examples, I could come up with more
> portable ways to solve the problem, other than using make-pathname.
Pathnames aren't generally portable anyway. I find that manipulating
pathnames directly via `make-pathname' is more predictable than
manipulating them indirectly via `parse-namestring'.
In fact, when creating a pathname for a host whose syntax doesn't
match the localhost, you really cannot rely on parse-namestring!
Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> If every time I have to program a solution, I have to think about
> previous systems (which I consider obsolete, because they are old and
> I'm not using them) and future system (that I cannot envision),
> wouldn't that make programming more difficult?
Well, yes and no. It may make the initial programming slightly more
difficult, but thinking about portability usually results in cleaner
designs. They have better separation of functionality and by not having
quite as many hidden assumptions built-in to the code they have the
benefit of being easier to maintain, evolve and reuse for other
purposes.
The purpose for considering the "obsolete" operating systems is
precisely to help alleviate the problem of envisioning future ones. The
changes made in the past are at least representative of a class of
modifications to operating systems. If you have compatibility backwards
in time, then you stand a better chance of also having it forwards in
time (as Kent eloquently argued in another post.)
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
···@sevak.isi.edu (Thomas A. Russ) writes:
> Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
>
> > If every time I have to program a solution, I have to think about
> > previous systems (which I consider obsolete, because they are old and
> > I'm not using them) and future system (that I cannot envision),
> > wouldn't that make programming more difficult?
>
> Well, yes and no. It may make the initial programming slightly more
> difficult, but thinking about portability usually results in cleaner
> designs.
Moreover, if you adopt a regular practice of portability, you don't think
about it. I'll go out on a limb and allege that Kevin is making trouble
for himself by wanting to program non-portably, and so when he decides to
do something portable, he does have to stop and think.
Being able to assume they'll never have to switch to another platform or
vendor is a luxury that I think mostly only vendors reliably have. Many
of us have been forced, over time, to switch vendors at least once,
sometimes many times. And while sometimes a solution requires a
vendor-specific solution, we prefer to think of these as the unusual
situations and so to isolate such cases to files that are known to be
more "fragile" than the ordinarily robust code we aspire to write.
> The purpose for considering the "obsolete" operating systems is
> precisely to help alleviate the problem of envisioning future ones.
Extremely well put!
Kent M Pitman <······@world.std.com> writes:
> ···@sevak.isi.edu (Thomas A. Russ) writes:
>
> > Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> >
> > > If every time I have to program a solution, I have to think about
> > > previous systems (which I consider obsolete, because they are old and
> > > I'm not using them) and future system (that I cannot envision),
> > > wouldn't that make programming more difficult?
> >
> > Well, yes and no. It may make the initial programming slightly more
> > difficult, but thinking about portability usually results in cleaner
> > designs.
>
> Moreover, if you adopt a regular practice of portability, you don't think
> about it. I'll go out on a limb and allege that Kevin is making trouble
> for himself by wanting to program non-portably, and so when he decides to
> do something portable, he does have to stop and think.
I want to "program non-portably"? From a recent post of mine:
I want to highlight my original point:
When you use make-pathname to construct a pathname you make be using
internal knowledge about the implementation (e.g., that Allegro uses
the `device' for drive), and that is *not* portable.
I am clearly arguing for programming in a *more* portable way, not
*less*.
You can find that quote here:
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&safe=off&threadm=4y94sxf5s.fsf%40beta.franz.com&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Doff%26group%3Dcomp.lang.lisp
>
> Being able to assume they'll never have to switch to another platform or
> vendor is a luxury that I think mostly only vendors reliably have. Many
> of us have been forced, over time, to switch vendors at least once,
> sometimes many times. And while sometimes a solution requires a
> vendor-specific solution, we prefer to think of these as the unusual
> situations and so to isolate such cases to files that are known to be
> more "fragile" than the ordinarily robust code we aspire to write.
My focus, from first post in this thread, was for portability, which
would lead users to more easily switch vendors. Perhaps you are
talking about someone else in the above paragraph, or just talking in
general.
* Kent M Pitman wrote:
> Being able to assume they'll never have to switch to another platform or
> vendor is a luxury that I think mostly only vendors reliably have.
And even vendors have to switch to other platforms: 68k to SPARC,
SunOS < 5 to SunOS 5 must both have been really major changes within
Sun as well as for their users.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Kent M Pitman wrote:
> > Being able to assume they'll never have to switch to another platform or
> > vendor is a luxury that I think mostly only vendors reliably have.
>
> And even vendors have to switch to other platforms: 68k to SPARC,
> SunOS < 5 to SunOS 5 must both have been really major changes within
> Sun as well as for their users.
And don't forget Mac OS 9 to OS X, which is at least an order of
magnitude more dramatic than the BSD->SysV change for SunOS. Any Mac
developers who got too "cute" with their system-specific assumptions
are hurting now.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> My focus, from first post in this thread, was for portability, which
> would lead users to more easily switch vendors. Perhaps you are
> talking about someone else in the above paragraph, or just talking in
> general.
Certainly I have no desire to cast your views in a way incompatible with
how you would cast them. I happily accept your correction.
I had taken what I thought were your remarks encouraging the use of
"../" and questioning the use of the MAKE-PATHNAME as encouraging
non-portability. Likewise I thought you were saying that it was hard
to think portably seemed to reject that. It seems to me we all have
one "compiled in" way of thinking which is not hard and that
deviations from our regular practice is hard; I was suggesting that if
you make (i.e., "if one makes") portable programming their compiled-in
way of doing things, then it is not a deviation from the norm to do
it, and as a consequence it is not (as) hard (as programming
non-portably).
If these are not things you said, then you're absolved.. I wasn't trying
to paint anyone in particular into the role of villains and good guys.
I'm happy to let people elect their own categorization based on the
morality-of-the-moment in my text. :) If you don't think these things,
I still think there are people who do, and I was speaking to those people.
Again, my apologies if I appeared to be dumping on you. I really prefer
to discuss ideas, not people. Attitudes held by people seem also worth
discussing where those attitudes affect style, performance, etc. And I was
certainly going there. But not for the purpose of ad hominem debate..
Kent M Pitman <······@world.std.com> writes:
> Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
>
> > My focus, from first post in this thread, was for portability, which
> > would lead users to more easily switch vendors. Perhaps you are
> > talking about someone else in the above paragraph, or just talking in
> > general.
>
> Certainly I have no desire to cast your views in a way incompatible with
> how you would cast them. I happily accept your correction.
>
> I had taken what I thought were your remarks encouraging the use of
> "../" and questioning the use of the MAKE-PATHNAME as encouraging
> non-portability.
I didn't say it, but I should have: since the directory component of
pathnames is specified in the ANS, I have no problem with Joe's use of
:up and :back, etc. What started the discussion was my asking how it
was different from (pathname "../"), even though this isn't a use of
make-pathname I would erradicate.
I was questioning the use of make-pathname, in some cases. It has
already been demonstrated that different vendors do different things
with the device. It seems very obvious that saying
(make-pathname ... :device ...)
is *not* portable. I have always been able to do pathname manipulation
on Windows without using :device and make-pathname. Why do I try and
avoid it? Because I have no idea if Allegro will always use this
represente the drive in the device on Windows. I'm trying to think
ahead and do defensive programming.
Kevin Layer <·····@--you-know-what-to-remove--.franz.com> writes:
> I was questioning the use of make-pathname, in some cases. It has
> already been demonstrated that different vendors do different things
> with the device. It seems very obvious that saying
>
> (make-pathname ... :device ...)
>
> is *not* portable.
Not necessarily. I agree that depending upon Lisp to interpret the
device as a Windows drive letter is non-portable.
It is true that this may produce a pathname that cannot be correctly
interpreted by DIRECTORY, PROBE-FILE, DELETE-FILE, etc. etc.
But it *ought* to produce a pathname such that PATHNAME-DEVICE will
return whatever it was that was stuck in there in the first place.
Furthermore, the resulting pathname should obey the rules of pathname
merging.
Kent M Pitman <······@world.std.com> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
> > It is true that I don't much care about VAX, ITS, or TOPS-20, but
> > MacIntosh is one market that we couldn't ignore (but I assume I could
> > use Unix pathnames with OSX at this point). But I didn't see any
> > documentation that required ".." to parse as :BACK rather than :UP,
> > and in fact there is one lisp where pathnames with :UP in them print
> > with ".." (so much for read-print consistency).
> >
> > So I suppose I *could* have used (pathname "../") (and I never said
> > that couldn't) but I think
> > (make-pathname :directory '(:relative :back) :defaults "") is more
> > robust and clearer in intent.
>
> Isn't that what I said? ;)
Yes. And you said it quite well. I wouldn't have bothered to follow
up but Kevin Layer asked specifically ``Do the above two differ on any
platform/lisp combo that you, Joe, care about?'' and I thought that it
would be rude to not respond even if I had nothing more to say than
`yeah, what Kent said'.
Kent M Pitman <······@world.std.com> writes:
> It's almost as if people think that industry is converging on the one
> and only one true file system. If it is, that's REALLY REALLY sad
> because I can assure you that some extremely good features have been lost
> along the way that might want to be reinvented. And some future operating
> systems might diverge, just as past ones have.
Could you please elaborate a little bit on these features? I never had
the chance to work with an ITS or TOPS-10, TOPS-20 system. I would
like to know more about the good features that got lost.
Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
Andreas Eder <············@t-online.de> writes:
> Could you please elaborate a little bit on these features? I never had
> the chance to work with an ITS or TOPS-10, TOPS-20 system. I would
> like to know more about the good features that got lost.
Kent mentioned versioning. I'll put in a vote for UNDELETE. Deleting
a file on TOPS-20 made it invisible and a candidate for purging, but
if you wanted it back, you could just UNDELETE it. PURGE truly erase
all DELETED files.
From: Christopher C. Stacy
Subject: Re: ···@& pathname problem
Date:
Message-ID: <u3cn127vn.fsf@dtpq.com>
>>>>> On 05 Feb 2003 18:04:19 -0500, Joe Marshall ("Joe") writes:
Joe> Andreas Eder <············@t-online.de> writes:
>> Could you please elaborate a little bit on these features? I never had
>> the chance to work with an ITS or TOPS-10, TOPS-20 system. I would
>> like to know more about the good features that got lost.
Joe> Kent mentioned versioning. I'll put in a vote for UNDELETE. Deleting
Joe> a file on TOPS-20 made it invisible and a candidate for purging, but
Joe> if you wanted it back, you could just UNDELETE it. PURGE truly erase
Joe> all DELETED files.
It was called "EXPUNGE".
······@dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 05 Feb 2003 18:04:19 -0500, Joe Marshall ("Joe") writes:
>
> Joe> Andreas Eder <············@t-online.de> writes:
> >> Could you please elaborate a little bit on these features? I never had
> >> the chance to work with an ITS or TOPS-10, TOPS-20 system. I would
> >> like to know more about the good features that got lost.
>
> Joe> Kent mentioned versioning. I'll put in a vote for UNDELETE. Deleting
> Joe> a file on TOPS-20 made it invisible and a candidate for purging, but
> Joe> if you wanted it back, you could just UNDELETE it. PURGE truly erase
> Joe> all DELETED files.
>
> It was called "EXPUNGE".
How soon we forget.
Joe Marshall <···@ccs.neu.edu> writes:
> ······@dtpq.com (Christopher C. Stacy) writes:
>
> > >>>>> On 05 Feb 2003 18:04:19 -0500, Joe Marshall ("Joe") writes:
> >
> > Joe> Andreas Eder <············@t-online.de> writes:
> > >> Could you please elaborate a little bit on these features? I
> > >> never had the chance to work with an ITS or TOPS-10, TOPS-20
> > >> system. I would like to know more about the good features that
> > >> got lost.
> >
> > Joe> Kent mentioned versioning. I'll put in a vote for UNDELETE.
> > Joe> Deleting a file on TOPS-20 made it invisible and a candidate
> > Joe> for purging, but if you wanted it back, you could just
> > Joe> UNDELETE it. PURGE truly erase all DELETED files.
> >
> > It was called "EXPUNGE".
>
> How soon we forget.
In modern file systems, it's called "Empty Trash" (or perhaps different
things in foreign-speaking countries like the UK, where I think it's
"Empty Wastebasket"). Soft deletion, which is what's discussed here,
is really not that different from tossing something in the recycle bin,
except that the recycle bin makes it hard to tell what's still available
and what's already irrevocably gone because stuff moves to another
directory...
Andreas Eder <············@t-online.de> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > It's almost as if people think that industry is converging on the one
> > and only one true file system. If it is, that's REALLY REALLY sad
> > because I can assure you that some extremely good features have been lost
> > along the way that might want to be reinvented. And some future operating
> > systems might diverge, just as past ones have.
>
> Could you please elaborate a little bit on these features? I never had
> the chance to work with an ITS or TOPS-10, TOPS-20 system. I would
> like to know more about the good features that got lost.
Well, the most obvious lost feature is versioning.
You might argue that if it was lost it was for a good reason, but evolution
doesn't do a pick-and-choose of each feature in each system, allowing good
features to go forward. Rather, the system survives and its features, even
the questionable ones, survive with it.
So you get the same effect as when George Bush is elected president and
he suddenly thinks that the very questionable piece of information "do
people want me as president at all" (which it's not even clear was answered,
given that he lost he popular vote and all) can be construed to mean "do
people endorse each and every one of my many policies. It simply isn't the
case that people were voting a down-the-line vote on each thing and that all
people either endorse everything he is and says or reject everything he
is and says. A vote simply means "overall, this guy and his baggage is
better than, overall, that guy and his baggage". And so it goes for
operating systems.
On older operating systems (and hence, possibly on operating systems
of the future if you're not too cynical and you think the world could
one day be corrected), files had versions. That means when you wrote
back foo.lisp, you didn't clobber your previous foo.lisp. Each one got
a number. So if I create a foo.lisp when none existed, I make a
foo.lisp.1. If I write it anew, I get foo.lisp.2. When I ask for
just "foo.lisp" on read, I usually get the highest version, which is
foo.lisp.2. This was tremendously useful if you were wanting to just rush
out the door and you had unwritten editor buffers because you could save
your files without worrying if you had made changes you wanted to keep;
later you could do a compare of foo.lisp.5 with foo.lisp.7 to see if you
liked the changes you made. (I was especially surprised the Mac didn't pick
this up because a natural visual metaphor for versioning would have been a
little stack of icons, so files that had multiple versions could just have
looked like little piles of files and would not have made much visual clutter.)
The ISO 9000 (I think that's what it's called) file system does use
FOO.LISP;3 to denote version 3 of FOO.LISP and is the only "active"
file system I know of that uses versions. I think that Unix folks think
that RCS replaces the need for this, but I don't agree.
Another operating system feature I liked a lot was the Multics file system's
use of "<" and ">" as dir separators, instead of "/". In multics,
">foo>bar>baz>x.lisp" was a filename in the
(:ABSSOLUTE "FOO" "BAR" "BAZ")
directory while
"foo>bar>baz>x.lisp"
was a filename in
(:RELATIVE "FOO" "BAR" "BAZ")
Furthermore, if you wanted to upward, you could do:
"<<foo>bar>baz>x.lisp"
which meant dir
(:RELATIVE :UP :UP "FOO" "BAR" "BAZ")
In fact, because going down into a link and then up to the parent could
take you interesting places, you could do:
"foo>bar<baz>x.lisp"
meaning
(:RELATIVE "FOO" "BAR" :UP "BAZ")
These notations made it a lot clearer what was a relative directory and
what was not, and I found "<" infinitely more intuitive than ".." to mean
"parent dir".
Kent M Pitman <······@world.std.com> writes:
> On older operating systems (and hence, possibly on operating systems
> of the future if you're not too cynical and you think the world could
> one day be corrected), files had versions. That means when you wrote
> back foo.lisp, you didn't clobber your previous foo.lisp. Each one got
> a number. So if I create a foo.lisp when none existed, I make a
> foo.lisp.1. If I write it anew, I get foo.lisp.2. When I ask for
> just "foo.lisp" on read, I usually get the highest version, which is
> foo.lisp.2. This was tremendously useful if you were wanting to just rush
> out the door and you had unwritten editor buffers because you could save
> your files without worrying if you had made changes you wanted to keep;
> later you could do a compare of foo.lisp.5 with foo.lisp.7 to see if you
> liked the changes you made.
Well, for this particular usage of file versioning (editor buffers),
the fact that Emacs optionally supports file versioning is good
enough. I use Emacs' versioning-emulation on all my programming
projects. Alas, because the filesystem doesn't support versioning, it
clutters up directories, so I can't just use it everywhere :-(
> (I was especially surprised the Mac didn't pick this up because a
> natural visual metaphor for versioning would have been a little
> stack of icons, so files that had multiple versions could just have
> looked like little piles of files and would not have made much
> visual clutter.) The ISO 9000 (I think that's what it's called)
> file system does use FOO.LISP;3 to denote version 3 of FOO.LISP and
> is the only "active" file system I know of that uses versions.
Since learning about this lost feature, I'm surprised too. And I'm
particularly disappointed that they didn't pick it up for OS X (and
they even had ISO9000 to inspire them!). Oh well...
> I think that Unix folks think that RCS replaces the need for this,
> but I don't agree.
I really hope that's not why this feature is missing from OS X.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Christopher C. Stacy
Subject: Re: ···@& pathname problem
Date:
Message-ID: <ubs1p27z7.fsf@dtpq.com>
>>>>> On 05 Feb 2003 18:51:38 -0800, Thomas F Burdick ("Thomas") writes:
Thomas> Well, for this particular usage of file versioning (editor
Thomas> buffers), the fact that Emacs optionally supports file
Thomas> versioning is good enough.
This isn't good enough because all the other tools don't understand
the versions. They hardly even understand the file "extension" part,
but to the extent that they do that, they get confused if there's also
a version number in there.
Note that on the system's we're talking about, the versioning
semantics were in the filesystem, not in libraries or applications.
······@dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 05 Feb 2003 18:51:38 -0800, Thomas F Burdick ("Thomas") writes:
> Thomas> Well, for this particular usage of file versioning (editor
> Thomas> buffers), the fact that Emacs optionally supports file
> Thomas> versioning is good enough.
>
> This isn't good enough because all the other tools don't understand
> the versions. They hardly even understand the file "extension" part,
> but to the extent that they do that, they get confused if there's also
> a version number in there.
>
> Note that on the system's we're talking about, the versioning
> semantics were in the filesystem, not in libraries or applications.
Yes, I know this (see the rest of my post lamenting that the Mac never
picked up on this). To the extent that you work entirely within
Emacs, the versioning emulation works. Which means that for the
particular use I was considering ("Oh crap, it's the end of the day
and I need to save my buffers"), it's good enough. You can go ahead
and save them, knowing that Emacs will have a whole series of backup
versions. Emacs is sufficiently OS-like that the fact that only Emacs
supports its approach doesn't hurt too much for writing code within
the Emacs IDE. But yes ... it's a far cry from actual system support.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> enough. I use Emacs' versioning-emulation on all my programming
> projects. Alas, because the filesystem doesn't support versioning, it
> clutters up directories, so I can't just use it everywhere :-(
You may already be aware of this, but you can direct all backups to
a single backup directory in the latest Emacs versions, thus
avoiding the clutter.
--
Hannu
From: Christopher C. Stacy
Subject: Re: ···@& pathname problem
Date:
Message-ID: <uy94tyzdt.fsf@dtpq.com>
I've never understood the "clutter" issue;
I guess it's a personal working style psychology issue.
Could someone write more about their experience?
I also don't like having to look in a seperate directory for the
versions of the files. I want to access them as easily as I access
the current version of the file, just by naming their "name" - not
having to mess around with directory names.
······@dtpq.com (Christopher C. Stacy) writes:
> I've never understood the "clutter" issue;
> I guess it's a personal working style psychology issue.
> Could someone write more about their experience?
For code, there's no issue. However, my ~/Documents directory is
cluttered enough, I don't need many versions of each file in there. I
already miss some file names among the crowd. Of course, if
versioning were system-supported, then, as Kent pointed out, the
obvious solution would be to have a little stack of icons in the
Finder, which would solve the clutter issue.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
······@dtpq.com (Christopher C. Stacy) writes:
> I've never understood the "clutter" issue;
> I guess it's a personal working style psychology issue.
> Could someone write more about their experience?
>
> I also don't like having to look in a seperate directory for the
> versions of the files. I want to access them as easily as I access
> the current version of the file, just by naming their "name" - not
> having to mess around with directory names.
It is quite easy to modify ls.c to avoid showing the names matching
".*\\.~[0-9]+~", like emacs does in M-x find-file, and to add an
option to show the versions (note that GNU ls already has a -v option
meaning "sort by version").
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
There is a fault in reality. Do not adjust your minds. -- Salman Rushdie
* Kent M Pitman wrote:
> I think that Unix folks think
> that RCS replaces the need for this, but I don't agree.
I don't really think that they do. ClearCase would be closer, which
implements versions through a filesystem, although you have to say
when you want a new version. Indeed, I think that Unix (or Unixoid
systems) is kind of at the point now where if you did want to
implement a versioned FS, you could, and then you could plug it in.
It might even be possible to get CC to work this way, though I am not
sure. There might be issues with names (CC uses a complex syntax for
version numbers (which are structured, of course, as it's a SCM not
just a versioned FS), but I think it could be done. Of course the
`plugging it in' bit would probably vary across OSs, unless you did it
via something like NFS (I have seen an interface to the DOS filesystem
done as an NFS server, so this isn't so unreasonable).
--tim
Tim Bradshaw <···@cley.com> writes:
> * Kent M Pitman wrote:
> > I think that Unix folks think
> > that RCS replaces the need for this, but I don't agree.
>
> I don't really think that they do. ClearCase would be closer, which
> implements versions through a filesystem, although you have to say
> when you want a new version. Indeed, I think that Unix (or Unixoid
> systems) is kind of at the point now where if you did want to
> implement a versioned FS, you could, and then you could plug it in.
ElephantFS is a research project that implements one for FreeBSD.
See <http://www.cs.ubc.ca/~feeley/> for details. One feature
it has that seems very attractive to me is the idea of keeping
'notable landmarks', and discarding unused versions: as time goes on
without a version being accessed, if it's close enough to another
revision which comes after, it's dropped. This handles the case that
every few months you mess with configuration files, saving a number of
times while experimenting; but really, all you care about is the final
result of that burst of experimentation.
And version numbers work nicely with directories and time. An example
command using the versions is
cd .#today:11:30
which takes you to a view of the directory as it existed at
11:30. Seems like neat stuff; I keep wishing it or similar features
were brought into mainstream filesystems.
--
If you want divine justice, die.
-- Nick Seldon
+ Kent M Pitman <······@world.std.com>:
| The ISO 9000 (I think that's what it's called) file system does use
| FOO.LISP;3 to denote version 3 of FOO.LISP and is the only "active"
| file system I know of that uses versions.
Do you mean ISO 9660? The kind that's used on CD-ROMs? Unless I am
mistaken, ISO 9000 is a standard for quality assurance or some such
thing. (In fact, from what I hear it's more a system for assuring
that fingers can be pointed at the right person when quality fails.)
| I think that Unix folks think that RCS replaces the need for this,
| but I don't agree.
Um, but it's a very useful band aid. I might worry about the amount
of disk space used with versioning of the classic kind, but I suppose
it's always possible to have a clever file system that detects when
FOO.LISP;7 is almost the same as FOO.LISP;6 and then just stores the
difference on disk.
But how would you deal with the other neat feature of RCS, namely
branches? (Not to mention tags, which become useful with CVS.) CL
does not support multidimensional version numbers, so it seems you
would have to resort to encoding the branch number in the filename.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Kent M Pitman <······@world.std.com>:
>
> | The ISO 9000 (I think that's what it's called) file system does use
> | FOO.LISP;3 to denote version 3 of FOO.LISP and is the only "active"
> | file system I know of that uses versions.
>
> Do you mean ISO 9660? The kind that's used on CD-ROMs?
And loopbacks :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On 06 Feb 2003 00:52:47 +0100, Harald Hanche-Olsen <······@math.ntnu.no>
wrote:
> Do you mean ISO 9660? The kind that's used on CD-ROMs? Unless I am
> mistaken, ISO 9000 is a standard for quality assurance or some such
> thing. (In fact, from what I hear it's more a system for assuring
> that fingers can be pointed at the right person when quality fails.)
Some time ago, while doing some TV channel surfing, I run across a show by
a tarrot reader at a local station (I live in northern Italy). In a part of
the screen there was a sign stating that the tarrot reader was ISO 900X
certified (I can't remember the "X" right now).
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Paolo Amoroso <·······@mclink.it> writes:
> Some time ago, while doing some TV channel surfing, I run across a
> show by a tarrot reader at a local station (I live in northern
> Italy). In a part of the screen there was a sign stating that the
> tarrot reader was ISO 900X certified (I can't remember the "X" right
> now).
Go to Thailand and you'll see "ISO 9000 certified" on just about every
second business sign.
--
Frode Vatvedt Fjeld
Kent M Pitman <······@world.std.com> writes:
> The ISO 9000 (I think that's what it's called) file system does use
> FOO.LISP;3 to denote version 3 of FOO.LISP and is the only "active"
> file system I know of that uses versions.
Although admittedly not hugely popular, there are plenty of people
who'd say VMS (which I assume is what you ment earlier in the thread
by "VAX," though it also runs on Alphas and supposedly has an IA64
port in the works) is "active"...
$ @dka300:[dungeon]dungeon.com;1
%DCL-I-SUPERSEDE, previous value of SYS$INPUT has been superseded
Welcome to Dungeon. This version created 3-NOV-78.
You are in an open field west of a big white house with a boarded
front door.
There is a small mailbox here.
>
Gabe Garza
Gabe Garza <·······@ix.netcom.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > The ISO 9000 (I think that's what it's called) file system does use
> > FOO.LISP;3 to denote version 3 of FOO.LISP and is the only "active"
> > file system I know of that uses versions.
>
> Although admittedly not hugely popular, there are plenty of people
> who'd say VMS (which I assume is what you ment earlier in the thread
> by "VAX," though it also runs on Alphas and supposedly has an IA64
> port in the works) is "active"...
Recent OpenVMS news:
http://news.com.com/2100-1001-983162.html
Headline: Itanium gives OpenVMS new lease on life
A quote:
Booting OpenVMS on an HP i2000 Itanium server is a momentous event
for the operating system, which just passed its 25-year
anniversary. HP is moving all its server lines to Intel's Itanium
chip, meaning that OpenVMS must make the switch or be left behind
with HP's Alpha processor, the last generation of which is planned
for 2004.
Gabe Garza wrote:
> Kent M Pitman <······@world.std.com> writes:
>
>
>>The ISO 9000 (I think that's what it's called) file system does use
>>FOO.LISP;3 to denote version 3 of FOO.LISP and is the only "active"
>>file system I know of that uses versions.
>
>
> Although admittedly not hugely popular, there are plenty of people
> who'd say VMS (which I assume is what you ment earlier in the thread
> by "VAX," though it also runs on Alphas and supposedly has an IA64
> port in the works) is "active"...
My ISP uses VMS on at least some of its servers, since the script
kiddies are unlikely to be able to hack into it.
I mentioned this to some coworkers at lunch today, and wondered if
anyone had developed a versioned file system for Linux.
Paul
From: Christopher C. Stacy
Subject: Re: ···@& pathname problem
Date:
Message-ID: <u7kcd27xc.fsf@dtpq.com>
Versioning was invented on ITS, and was picked up and somewhat
improved on TOPS-20. It also made it over to VMS.
Of course the Lisp Machine (the successor to ITS) had it.
Kent M Pitman <······@world.std.com> writes:
> (I was especially surprised the Mac didn't pick
> this up because a natural visual metaphor for versioning would have been a
> little stack of icons, so files that had multiple versions could just have
> looked like little piles of files and would not have made much visual clutter.)
I suppose that this may have been due to space concerns with the initial
Macs. With only a 400k floppy that often contained the OS, your
application and your data files, having a new version each time you
saved would have been a bit difficult to deal with.
Nevertheless, lack of versioning is something that I sorely miss in the
current operating systems.
-Tom.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> ······@dtpq.com (Christopher C. Stacy) writes:
>
> > I've never understood the "clutter" issue;
> > I guess it's a personal working style psychology issue.
> > Could someone write more about their experience?
>
> For code, there's no issue. However, my ~/Documents directory is
> cluttered enough, I don't need many versions of each file in there.
> I already miss some file names among the crowd.
Meaning your tools for presenting the contents are impoverished enough
that they force you to see files you don't want. This can happen due
to reasons other than multiple versions. Good tools for directory
display AND filtering are an essential characteristic of a file system
browser.
> Of course, if versioning were system-supported, then, as Kent
> pointed out, the obvious solution would be to have a little stack of
> icons in the Finder, which would solve the clutter issue.
Right. I could be wrong, but I think that's just what Chris was
getting at--that the problem isn't where the files are, but how they
are presented.
- - - -
Back to Lisp, There is a programmatic issue of whether DIRECTORY is the
only way to access them. In TOPS20, I seem to recall that one was intended
to get a <<... can't remember the word. I seem to recall it's jfn or some
such thing ...>> a pointer or cursor into the directory, similar to the
protocol that with-hash-table-iterator uses, where you get an initial
pointer/cursor and you can step the pointer/cursor to get a "next file".
This keeps you from having to cons whole directories as structures and
allows you to work in O(1) space rather than O(n) for programs searching
directories of n files. The CL interface to dir listing is, therefore,
one of those tools that 'feels' (or 'causes') the pain' of directory
clutter, because you sometimes have to cons whole directories of pathnames
to find out that the first file in the dir was the one you wanted...
Hopefully vendors provide native alternatives,since it would fit perfectly
into the mapping or LOOP styles to do so...
Kent M Pitman <······@world.std.com> writes:
> can't remember the word. I seem to recall it's jfn or some such thing
Yes, JFN. Job file number.
--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10,
Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming
Thank you Kent for that informative post.
Kent M Pitman <······@world.std.com> writes:
> On older operating systems (and hence, possibly on operating systems
> of the future if you're not too cynical and you think the world could
> one day be corrected), files had versions. That means when you wrote
> back foo.lisp, you didn't clobber your previous foo.lisp. Each one got
> a number. So if I create a foo.lisp when none existed, I make a
> foo.lisp.1. If I write it anew, I get foo.lisp.2. When I ask for
> just "foo.lisp" on read, I usually get the highest version, which is
> foo.lisp.2. This was tremendously useful if you were wanting to just rush
> out the door and you had unwritten editor buffers because you could save
> your files without worrying if you had made changes you wanted to keep;
> later you could do a compare of foo.lisp.5 with foo.lisp.7 to see if you
> liked the changes you made. (I was especially surprised the Mac didn't pick
> this up because a natural visual metaphor for versioning would have been a
> little stack of icons, so files that had multiple versions could just have
> looked like little piles of files and would not have made much visual clutter.)
> The ISO 9000 (I think that's what it's called) file system does use
> FOO.LISP;3 to denote version 3 of FOO.LISP and is the only "active"
> file system I know of that uses versions. I think that Unix folks think
> that RCS replaces the need for this, but I don't agree.
Is there any information on the web or in libraries about those file
systems. Versioning seems very interesting to me. How did you get rid
of old versions - automatically? How many were allowed?
> Another operating system feature I liked a lot was the Multics file system's
> use of "<" and ">" as dir separators, instead of "/". In multics,
> ">foo>bar>baz>x.lisp" was a filename in the
> (:ABSSOLUTE "FOO" "BAR" "BAZ")
> directory while
> "foo>bar>baz>x.lisp"
> was a filename in
> (:RELATIVE "FOO" "BAR" "BAZ")
> Furthermore, if you wanted to upward, you could do:
> "<<foo>bar>baz>x.lisp"
> which meant dir
> (:RELATIVE :UP :UP "FOO" "BAR" "BAZ")
> In fact, because going down into a link and then up to the parent could
> take you interesting places, you could do:
> "foo>bar<baz>x.lisp"
> meaning
> (:RELATIVE "FOO" "BAR" :UP "BAZ")
> These notations made it a lot clearer what was a relative directory and
> what was not, and I found "<" infinitely more intuitive than ".." to mean
> "parent dir".
That is definitely true. I wonder wether it would be feasible to
implement such filesystem semantics under a current BSD or Linux.
Thanks,
Andreas
--
Wherever I lay my .emacs, there�s my $HOME.
* Andreas Eder wrote:
> Is there any information on the web or in libraries about those file
> systems. Versioning seems very interesting to me. How did you get rid
> of old versions - automatically? How many were allowed?
There are other things that standard (meaning `with the semantics that
the 7th edition FS had' I guess) Unix filesystems lack which make them
a real pain. The lack of ACLs for instance contribute to making Unix
security as hard to manage as it is (Solaris has ACLS but there are
various features that somewhat suck about them). Extensible file
metadata is missing, or even just non-extensible but *enough*
metadata, like enough dates to make backup systems work reasonably
(you want at least creation + last backup date as well as the current
last modify and last access). Again Solaris has some extensible
metadata stuff in (maybe) 8 and (certainly) 9, but I don't know enough
to say if it's any use. Other systems are growing these things too,
I'm sure.
Of course, what happens when Unix grows filesystems with extended
semantics is that half the FS tools stop working right (will tar copy
ACLs? Probably not, no). So no one (or very few people) actually use
these things. Also, in the case of ACLs, I think the terrible truth
is that if you *do* provide them (like NTFS does), and support them in
backup tools &c it turns out that no one uses them anyway because
they're too hard to think about.
--tim
Andreas Eder <············@t-online.de> writes:
> Thank you Kent for that informative post.
>
> Kent M Pitman <······@world.std.com> writes:
>
> >
> > [Gobs of info on filesystems of yore]
> >
>
> Is there any information on the web or in libraries about those file
> systems. Versioning seems very interesting to me. How did you get rid
> of old versions - automatically? How many were allowed?
HP keeps the complete OpenVMS doc set available for browsing here:
http://www.openvms.compaq.com/doc/os731_index.html
The OpenVMS file system uses versioning and is definitely worth
learning about. In addition to versioning, it offers other features
alien to Unix; e.g., logical pathnames (similar to Common Lisp's)
and internal support for file formats other then octet streams...
If you're the hands on type and really interested in this stuff, you
can pick up a used VAXStation off of eBay for less then a hundred
bucks (you'll also want some kind of console--cheapest option is to
build a MMJ -> DB9 serial cable and use your PC's serial port...).
It'll either have VMS already installed or you can get a hobbiest
license for free from whatever DECUS is called now. There's a whole
world out there that's neither Unix nor Windows, and learning about
it is a fairly enlightening experience.
> >
> > [Neat Multics pathname info]
> >
>
> That is definitely true. I wonder wether it would be feasible to
> implement such filesystem semantics under a current BSD or Linux.
>
From what I understand (someone correct me if I'm wrong), a
fundamental difference between Unix and VMS-like operating system
pathname semantics is that Unix splits pathname semantics between the
shell and system calls, where VMS puts the burden on the system calls
(FWIW, I like this better).
For example, On VMS "DEL GNG:[DOCS.DRAFTS...]*.*;*" would treat
"DKA300:[GNG.DOCS.DRAFTS...]*.*;*" as a single pathname denoting all
versions of all files, in the directory (:ABSOLUTE "GNG" "DOCS"
"DRAFTS") and all its subdirectories on the device "DKA300".
On Unix, the shell would expand "/gng/docs/drafts/*/*" into multiple
arguments (all files in the first level of subdirectories under
"/gng/docs/drafts")--the program wouldn't even see the users pathname.
I think you could get a cheap-and-not-really-correct solution on Unix
by modifying a shell to grok your new syntax. It would have to expand
all pathnames into a form that other Unix programs would understand.
cheap-and-not-really-correct hasn't really stopped anyone on Unix
before, so don't let it discourage you now. ;)
Gabe Garza
From: Christopher C. Stacy
Subject: Re: ···@& pathname problem
Date:
Message-ID: <un0l8bva1.fsf@dtpq.com>
>>>>> On 06 Feb 2003 22:20:36 +0100, Andreas Eder ("Andreas") writes:
Andreas> Versioning seems very interesting to me. How did you get rid
Andreas> of old versions - automatically? How many were allowed?
Sometimes the word "generation" was used, rather than "version".
The version size was limited by the representation used in the
filesystem code. On ITS, filename components were limited to six
characters, so the highest version was 999999. On the LispM file
system (LMFS) the version number was some integer like 16777216.
On TOPS-20 the highest version number was 131071.
I don't remember the limit on VMS.
When you exceeded this, on ITS it just wrapped (000000),
and I think that's also what LMFS did, but I don't remember.
On TOPS-20 you got an error; I don't remember what VMS did.
In practice, the numbers didn't often get that high, unless there
was some kind of run-away bug. And if the numbers do get too high,
if you had to, you can always reset the counter by going back and
renumbering the files (since there are not really that many existing
versions of the file). That has the potential to confusion with other
databases that remembered the version numbers of files (such as source
control systems or filesystem backup/restore databases).
But I just don't recall that ever being a problem, in practice.
Note that version numbers are different from, not a replacement for,
source-control-versioning systems. So, you can check out copy of the
source file in your own working directory. You let the version number
on that copy go up as neeed. When you're done, you check back in to
the master directory, with the version just bumped up by one (even
though you had created 300 more generations of the copy of the file).
The version-control systems work on top of and orthogonally to
the filesystem's notion of file versions.
Emacs had tools for pruning and cleaning excess versions of the files
from your directory. (In fact, GNU Emacs still has some of that kind
of thing, but it only works on files that follow its conventions.)
A single keystroke in Dired marks all the excess versions for deletion.
There were also commands (in your command shell) that would delete
files with wildcard versions, but retaining a specified number of
the most recent ones, or in a range of dates, etc. Also, the
filesystem had a "Dont Reap" bit that could be set on files to
explicitly mark them as protected from such wildcard reaping tools.
Another feature of these versioned filesystems (at least on ITS, LMFS,
and TOPS-20) is that besides asking to open a specific version, you
can ask for the "newest" version (which is the default), or the "oldest"
version of the file. This is specified in the syntax. On ITS, the
filename would be "FOO <" for the oldest vesion of the file "FOO".
On LMFS a filename can look like "foo.lisp.oldest".
The file "version" or "generation" feature was not just for humans
editing source files, although that was one of the most useful places.
Let me mention another example of the difference between the operating
system understanding that files have versions, versus the GNU Emacs
kludge of creating "backup" files. Suppose you have a directory that
contains a bunch of files that each correspond to some program function.
For example, suppose each file contains the configuration for a particular
server to start. In filesystems that have versions, a program can ask
for a directory listing of "*.cfg.newest", and each file will be indeed
be the config file for a server; just map over the files.
By contrast, on today's systems, our program would get confused
because it would see all those "backup" copies of the files,
and think each one was a seperate server, and do the wrong thing.
Alternatively, you could invent another place to store the backups,
but now you have to have another directory for every directory that
exists on the system. And now you have to plug that directory name
(or other funny business) into the pathname, and having to do this
will confuse other programs that are not kludge-aware.
Another feature someone mentioned is that files on TOPS-20 and LMFS
did not go away when you "deleted" them. The DELETE operation only
marks them, so that if the user later requests a seperate operation
called EXPUNGE on the file (directory), they really go away.
Up until that point, you can UNDELETE the files. After the point
of EXPUNGE you would have to use some disk salvage recovery tool.
The way we would work is to save the files early and often.
(This was especially true if your site was prone to power failures!)
In Emacs, every time you typed "c-x c-s", you would be creating
a new version of the file, which is a place you can easily examine
and go back to. They are all timestamped in the directory for free.
You can use command keystrokes in Emacs to diff or visually compare.
When you think you're done with those excess versions, you go back
and delete them, all the way back to the version you started from.
Having lots of versions of files is feature, not a hassle.
You just delete the ones you don't want by pressing two keys in Dired.
Now you just have the n+1 committed versions that you really like.
No fuss no muss, but you meanwhile saved your ass because you were
able to back out all those stupid changes you unintentionally made.
When you decide that you're eating too much disk space, now you go
back and EXPUNGE the directory (because, secretly, you could have still
UNDELETEd all those versions of the files back into existance.)
The DELETE/UNDELETE/EXPUNGE facility was seperate from the versions.
Any file can be UNDELETEd, not just those with multiple versions.
But those two features work well together for managing your disk files.
Some people didn't like the undelete or versioning features on TOPS-20
and would say that it was "unreliable". What they mean by this is
that someone else (like their boss) had access to their directories,
and would sometimes come along without warning and just delete files
or perform an EXPUNGE without their consent. Rather than blame the
person who did this, I have heard people blame "the system".
(I never worked in a place where people would do such a thing.)
One thing that would make a versioned file system `interesting' for
Unixoid systems would be hard links. If x and y are the same,
identical file, what should happen when I make a new version of x?
Does y get a new version too? Even now editors which make backups
have to deal with this case specially (or often fail to deal with it)
- emacs has backup-by-copying-when-linked for instance.
The problem with this is basically because current standard Unix FSs
have a separation between file names, which live in directories (and
that is *all* that lives in directories), and all the other file
metadata, which lives in (or is referenced by, for some recently-added
metadata) the inode. The inode knows how many names (hard links) the
file has, which is essentially to support a reference-counting `GC',
but it doesn't know where those names are. Files in standard Unix FSs
are first-class objects in other words - and indeed it is possible
(and reasonably common) to have files which have *no* names at all but
are being held in existence merely by being open.
I think the right answer would be to associate the version information
with the file itself (hence with the inode), so the answer would be
that yes, y would get a new version too, and versioning information
would be somewhat separate than naming information.
--tim
From: Christopher C. Stacy
Subject: Re: ···@& pathname problem
Date:
Message-ID: <uznp7sxj8.fsf@dtpq.com>
Good question.
BTW, I am pretty susre that ITS is where symbolic file links
were invented. We didn't have hard links. (LMFS same thing.)
ITS also had a pathname "translation" facility in the kernel,
which was sort of like logical pathnames.
+ Tim Bradshaw <···@cley.com>:
| I think the right answer would be to associate the version information
| with the file itself (hence with the inode), so the answer would be
| that yes, y would get a new version too, and versioning information
| would be somewhat separate than naming information.
This could at the same time help solve another problem, namely that of
atomic updates. Updating a configuration file can be dangerous, if
some program needing the config file reads it in the middle of an
update. The traditonal Unix solution is to upate a copy, then rename
the copy to the original name. But this breaks in the presence of
hard links. If you had versioning on the inode level instead, you
could arrange that any program asking for the most recent version of
the file would not get the file which is being updated until the
update is actually finished. You could even request that, if the
updating program dies without properly closing the file, the partially
updated version disappears.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
* Harald Hanche-Olsen wrote:
> This could at the same time help solve another problem, namely that of
> atomic updates. Updating a configuration file can be dangerous, if
> some program needing the config file reads it in the middle of an
> update. The traditonal Unix solution is to upate a copy, then rename
> the copy to the original name. But this breaks in the presence of
> hard links. If you had versioning on the inode level instead, you
> could arrange that any program asking for the most recent version of
> the file would not get the file which is being updated until the
> update is actually finished. You could even request that, if the
> updating program dies without properly closing the file, the partially
> updated version disappears.
Exactly right. By putting more smarts in the inode you can do all
sorts of clever things - for instance (as an extension to your thing)
you could say `I am going to update this set of files: everyone else
should continue to see the current version of *any* of them until I
release the lock I have. If I release the lock abnormally then just
backout all the changes.' You could probably also do FS snapshots
within the filesystem (although systems already have these via
different mechanisms).
--tim
On 07 Feb 2003 21:17:07 +0100, Harald Hanche-Olsen
<······@math.ntnu.no> wrote:
>Updating a configuration file can be dangerous, if
>some program needing the config file reads it in the middle of an
>update.
Aren't writes atomic on Unix? Or if program A is doing write(file,
buf, 1000) and program B does read(file, buf, 1000) can B actually get
500 bytes of old data and 500 bytes of new?
--
"Mercy to the guilty is treachery to the innocent."
Remove killer rodent from address to reply.
http://www.esatclear.ie/~rwallace
+ ··@vorpalbunnyeircom.net (Russell Wallace):
| On 07 Feb 2003 21:17:07 +0100, Harald Hanche-Olsen
| <······@math.ntnu.no> wrote:
|
| >Updating a configuration file can be dangerous, if
| >some program needing the config file reads it in the middle of an
| >update.
|
| Aren't writes atomic on Unix? Or if program A is doing write(file,
| buf, 1000) and program B does read(file, buf, 1000) can B actually get
| 500 bytes of old data and 500 bytes of new?
I'm not sure, but at least I am reasonably certain that your write
call is not guaranteed to write 1000 bytes. It may write only 500; if
you don't check the return value of write(), you're possibly in for a
nasty surprise. (This is certainly true in practice when writing to
sockets, however that is sort of beside the point here.)
In any case, your point, even if valid, relies on your building the
whole file in memory before committing it in a single write. Also,
the combined effects of writing and truncating the file cannot be made
atomic, AFAIK.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
On 08 Feb 2003 13:09:29 +0100, Harald Hanche-Olsen
<······@math.ntnu.no> wrote:
>I'm not sure, but at least I am reasonably certain that your write
>call is not guaranteed to write 1000 bytes. It may write only 500; if
>you don't check the return value of write(), you're possibly in for a
>nasty surprise.
Well, sure; if you can't write all the data (e.g. because the disk is
full), then you lose; you need to check the return value so you can
abort with an error message in that case.
>In any case, your point, even if valid, relies on your building the
>whole file in memory before committing it in a single write. Also,
>the combined effects of writing and truncating the file cannot be made
>atomic, AFAIK.
True; this technique is really at its best when the data is always the
same size (or can be padded out with blanks to ensure that).
--
"Mercy to the guilty is treachery to the innocent."
Remove killer rodent from address to reply.
http://www.esatclear.ie/~rwallace
On 06 Feb 2003 22:20:36 +0100, Andreas Eder <············@t-online.de>
wrote:
> Is there any information on the web or in libraries about those file
> systems. Versioning seems very interesting to me. How did you get rid
The Minicomputer Orphanage provides a huge--I mean it!--collection of
documentation[*] for old systems:
http://www.spies.com/aek/orphan.html
I _highly_ recommend it. By the way, there is also documentation on MIT, TI
and Xerox Lisp machines. Check chapter 6 "Pathnames" of the TI Explorer
Programming Concepts manual. I think it's insightful.
Paolo
[*] Warning: it's fascinating and addicting.
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Paolo Amoroso <·······@mclink.it> writes:
> On 06 Feb 2003 22:20:36 +0100, Andreas Eder <············@t-online.de>
> wrote:
>
> > Is there any information on the web or in libraries about those file
> > systems. Versioning seems very interesting to me. How did you get rid
>
> The Minicomputer Orphanage provides a huge--I mean it!--collection of
> documentation[*] for old systems:
>
> http://www.spies.com/aek/orphan.html
>
> I _highly_ recommend it. By the way, there is also documentation on MIT, TI
> and Xerox Lisp machines. Check chapter 6 "Pathnames" of the TI Explorer
> Programming Concepts manual. I think it's insightful.
>
>
> Paolo
>
> [*] Warning: it's fascinating and addicting.
Very fascinating. But they're missing my favorite over-engineered CISC
minicomputer: the Computer Automation "Naked Mini"!
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + Kent M Pitman <······@world.std.com>:
>
> | The ISO 9000 (I think that's what it's called) file system does use
> | FOO.LISP;3 to denote version 3 of FOO.LISP and is the only "active"
> | file system I know of that uses versions.
>
> Do you mean ISO 9660? The kind that's used on CD-ROMs? Unless I am
> mistaken, ISO 9000 is a standard for quality assurance or some such
> thing.
Actually, I knew this latter fact but wasn't sure if the version numbering
was part of the quality assurance plan. ;) Yes, I mean the thing from
CD-ROM so I guess if you say it's 9660, I'll believe you.
> (In fact, from what I hear it's more a system for assuring
> that fingers can be pointed at the right person when quality fails.)
>
> | I think that Unix folks think that RCS replaces the need for this,
> | but I don't agree.
>
> Um, but it's a very useful band aid.
Btw, I really meant that Unix thinks "user programs" replace the need for
this, RCS being one such example.
> I might worry about the amount
> of disk space used with versioning of the classic kind, but I suppose
> it's always possible to have a clever file system that detects when
> FOO.LISP;7 is almost the same as FOO.LISP;6 and then just stores the
> difference on disk.
Indeed, it could be done, but for data recovery reasons it's a bad idea.
One reason that multiple versions was VERY important and one reason I miss
them even today is that if you get a disk error in FOO.LISP.3 you can often
recover most of the data from FOO.LISP.2, but that wouldn't be so if you
only stored diffs... (well, it would presumably be true in one direction
but not the other).
> But how would you deal with the other neat feature of RCS, namely
> branches?
This is usually done by having "more complicated versions" not by
eliminating versions. The Lisp Machine had a version controlled ("VC") file
system that included branching potentials in extended version information.
This was used internally at Symbolics quite heavily; I'm not sure if it
was ever sold. Probably not. I believe it requires extra pathname
slots to make it work.
But, in addition, even absent branching at the file system level, the
Lisp Machine often did the same thing as Unix does--clone a directory
for a new branch. At least then each branch could have its own version
numbers. As I recall, there were two extra components. One was a branch
ID, but I can't remember what the other was--maybe a branch version?
All VC filenames were "flattened" for the conventional "flat file system"
before release in order to avoid compatibility headaches, as I recall.
And, for things like releases, it was common to have DEFSYSTEM
have a data file that notated the version number for each system. So
Release 3 of the FOO system might have a file that contained
((:SYSTEM-NAME "FOO" :VERSION 3)
(:VERSIONS ("MAIN.LISP" 3) ("AUX.LISP" 7)))
[Why this was stored this way and not as #P"MAIN.LISP.3" I'm not sure but
was probably an accomodation to the absence of operations for
doing a MEMBER-like search for #P"MAIN.LISP.3" in the list
(#P"MAIN.LISP.3" #P"AUX.LISP.7") given a key of #P"MAIN.LISP" with
no version. But it was all easily parsed/coerced so this is just a detail.]
Anyway, if you had several versions of a file that were still active for some
historical reason, you could mark those specific versions "don't reap"
or "don't delete". (Reaping was an automatic or semi-automatic deletion
due to excess generations; deletion was a stronger request to force
deletion even where reaping might have been disabled. Reaping/deletion
could be separately gated.)
The main useful thing about version numbers, though, is that they
acknowledge the monotonic nature of real world time. I often find Unix
or PC files that are in different directories and have no idea which is
newer. Especially because computer clocks are unreliable, some copy
programs don't preserve date/time, some network protocols don't communicate
date/time, and so on. On the Lisp Machine, it was more rare for two
versions of a file to "get separated" in the first place but even when
they did the version information often told you which was more recent.
> (Not to mention tags, which become useful with CVS.) CL
> does not support multidimensional version numbers, so it seems you
> would have to resort to encoding the branch number in the filename.
Yes, this is a weakness in the existing CL pathname system. I suppose
that if someone had a file system that actually supported this stuff,
they'd have to make a pathname extension to accomodate it.
* Kent M Pitman wrote:
> Indeed, it could be done, but for data recovery reasons it's a bad idea.
> One reason that multiple versions was VERY important and one reason I miss
> them even today is that if you get a disk error in FOO.LISP.3 you can often
> recover most of the data from FOO.LISP.2, but that wouldn't be so if you
> only stored diffs... (well, it would presumably be true in one direction
> but not the other).
I am fairly sure that this kind of thing has been rendered obsolete by
events. As far as I can make out, it used to be the case that disks
would fairly often lose a few blocks but then carry on working for a
long time. Certainly this was my experience with SMD disks in the
80s: disks could gradually get sicker and sicker, or alternatively
(and more commonly) new disks would lose a few blocks but then be fine
for a very long time. However, what seems to happen now is that disks
will work fine and then essentially fail completely with a bang.
I admit to not having much evidence other than personal experience for
this - certainly all the disk failures I've been involved with in the
last 5 years or so have been either `disk has lost essentially all its
blocks' or `disk is completely offline'. The one bit of non-personal
evidence I do have is apocryphal - Solaris as of ?2.6? has support
for stuff that SCSI can do to indicate that a disk is getting a lot of
soft errors and may be failing. When this was announced, I remember
them saying that unfortunately this was almost useless, because in
almost all cases there was no warning at all of failure.
On the other hand, given the capacity of modern disks, keeping diffs
doesn't seem so important now.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Kent M Pitman wrote:
> > Indeed, it could be done, but for data recovery reasons it's a bad idea.
> > One reason that multiple versions was VERY important and one reason I miss
> > them even today is that if you get a disk error in FOO.LISP.3 you can often
> > recover most of the data from FOO.LISP.2, but that wouldn't be so if you
> > only stored diffs... (well, it would presumably be true in one direction
> > but not the other).
>
> I am fairly sure that this kind of thing has been rendered obsolete by
> events. As far as I can make out, it used to be the case that disks
> would fairly often lose a few blocks but then carry on working for a
> long time. Certainly this was my experience with SMD disks in the
> 80s: disks could gradually get sicker and sicker, or alternatively
> (and more commonly) new disks would lose a few blocks but then be fine
> for a very long time. However, what seems to happen now is that disks
> will work fine and then essentially fail completely with a bang.
As I understand it, modern hard disks invisibly remap bad blocks using
space reserved for the purpose. When the remap space fills up, bad
blocks start showing up in userspace- and by that point they're
probably starting to fail at a greater rate, giving the impression
that the disk is suddenly failing.
I had a nice 40gig that did indeed fail with a bang- I heard the heads
crash from across the room. Well, not quite a bang but it was pretty
loud given how small disks are these days.
Gregm
Greg Menke <··········@toadmail.com> writes:
> Tim Bradshaw <···@cley.com> writes:
>
> > ... what seems to happen now is that disks
> > will work fine and then essentially fail completely with a bang.
>
> As I understand it, modern hard disks invisibly remap bad blocks using
> space reserved for the purpose.
You're both assuming the problem is hardware.
For better or worse, some versions of the Lisp Machine file system had the
same kinds of problems that other file systems had to go through, I guess:
that is, there were bugs in the software that had to get worked out.
As I recall, there were bugs where a file was accidentally shared
(because the file system goofed on its understanding of what was free
and what was not) and so parts of files were invisibly reallocated and
consequently invisibly rewritten without a hardware fault. The effect
was that a file you had not touched at all in months would suddenly contain
someone else's data.
I don't think software bugs can be obsoleted by modern
technology... One can, of course, make the argument that people should
use only old, crufty file systems since only those have had years of
field testing. ;) I don't subscribe to that mode of thinking.
* Kent M Pitman wrote:
> You're both assuming the problem is hardware.
Yes, indeed I am.
> I don't think software bugs can be obsoleted by modern
> technology...
They can be obsoleted by maturity and careful design though - modern
commercial Unix filesystems (and probably Linux too) are amazingly bug
free. I can't remember the last time I had an FS issue on Solaris
which wasn't hardware failure.
> One can, of course, make the argument that people should use only
> old, crufty file systems since only those have had years of field
> testing. ;) I don't subscribe to that mode of thinking.
Neither do I, but I am reasonably sure that careful design and testing
can allow new features to be added to existing FSs (such as ACLs say)
without hurting the reliability. Sure, it's hard work, and you have
to test *a lot*, but people are empirically willing to do that work if
the payoff is high enough (like: if it dies all your Oracle users move
to another vendor and you go bankrupt).
--tim
Tim Bradshaw <···@cley.com> writes:
> > I don't think software bugs can be obsoleted by modern
> > technology...
>
> They can be obsoleted by maturity and careful design though - modern
> commercial Unix filesystems (and probably Linux too) are amazingly bug
> free.
This is an unprovable and probably empirically wrong statement.
We saw a lot of trashed file problems at world.std.com last year.
The middle of a number of my mail files were randomly trashed with
pages of nuls. Numerous other users complained. The world was
willing, on demand, to restore old versions in case those were in
better shape. No explanation was offered. Knowing whether a
version on tape was any better or different was hard since there
were no version numbers. (At least when I used to ask the Lispm
people to restore foo.text.100 and they said all they had was
foo.text.67, I had a guess as to how bad the loss was...)
Welcome to THE WORLD
Shell Server
An SGI/ORIGIN Cluster (IRIX 6.5)
I don't follow freeware very closely but it's my belief that someone
purchased this operating system and that it's commercially supported,
no?
> > One can, of course, make the argument that people should use only
> > old, crufty file systems since only those have had years of field
> > testing. ;) I don't subscribe to that mode of thinking.
>
> Neither do I, but I am reasonably sure that careful design and testing
> can allow new features to be added to existing FSs (such as ACLs say)
> without hurting the reliability. Sure, it's hard work, and you have
> to test *a lot*, but people are empirically willing to do that work if
> the payoff is high enough (like: if it dies all your Oracle users move
> to another vendor and you go bankrupt).
On the flip side, these bugs are hard to document and prove, and by the
time one has recovered the data, one hardly has the time, energy, or money
left to waste on a lawsuit that might fail. So I disagree with this
claim, too.
* Kent M Pitman wrote:
> This is an unprovable and probably empirically wrong statement.
> We saw a lot of trashed file problems at world.std.com last year.
> The middle of a number of my mail files were randomly trashed with
> pages of nuls.
That is almost certainly an NFS bug. NFS has had and probably still
has a bad habit of getting confused and writing blocks of other files,
or blocks of nulls all over files. This is just the same as if a user
program did that, because to all intents and purposes that's all NFS
is - indeed it would be quite possible to implement a fully user-mode
NFS server (and this has been done). The underlying filesystem can't
protect you against applications which decide to write trash onto the
files. The symptoms of this bug as you describe it sound exactly like
the NFS bugs I've experienced.
Note that I didn't claim that *all* filesystems are almost bug free,
simply that it was possible to write ones which are and that this is
not incompatible with the further development of those FSs. I'm very
happy to exclude NFS from the list of filesystems which are almost bug
free - anyone who is using NFS for mission critical writable data,
especially in a heterogeneous environment, is probably asking for what
they get (which will likely be randomly trashed files and weird file
locking problems).
--tim
Tim Bradshaw <···@cley.com> writes:
> One thing that would make a versioned file system `interesting' for
> Unixoid systems would be hard links. If x and y are the same,
> identical file, what should happen when I make a new version of x?
> Does y get a new version too?
Nope. Neither would you if you wrote a new version of x in the present
system unless you chose to update the existing disk blocks (in which case
you would not be bumping version).
> Even now editors which make backups
> have to deal with this case specially (or often fail to deal with it)
> - emacs has backup-by-copying-when-linked for instance.
>
> The problem with this is basically because current standard Unix FSs
> have a separation between file names, which live in directories (and
> that is *all* that lives in directories), and all the other file
> metadata, which lives in (or is referenced by, for some recently-added
> metadata) the inode. The inode knows how many names (hard links) the
> file has, which is essentially to support a reference-counting `GC',
> but it doesn't know where those names are.
Which is yet another reason that versioning would and should simply
ignore this.
New file versions are just different files with usefully related names.
They are NOT "the same file".
> Files in standard Unix FSs
> are first-class objects in other words - and indeed it is possible
> (and reasonably common) to have files which have *no* names at all but
> are being held in existence merely by being open.
>
> I think the right answer would be to associate the version information
> with the file itself (hence with the inode), so the answer would be
> that yes, y would get a new version too, and versioning information
> would be somewhat separate than naming information.
Oh, I think this would be a disaster. It would give opaque behavior
where seemingly equivalent files gave different effects.
Kent M Pitman <······@world.std.com> writes:
> Tim Bradshaw <···@cley.com> writes:
>
> > One thing that would make a versioned file system `interesting' for
> > Unixoid systems would be hard links. If x and y are the same,
> > identical file, what should happen when I make a new version of x?
> > Does y get a new version too?
>
> Nope. Neither would you if you wrote a new version of x in the present
> system unless you chose to update the existing disk blocks (in which case
> you would not be bumping version).
>
> > Even now editors which make backups
> > have to deal with this case specially (or often fail to deal with it)
> > - emacs has backup-by-copying-when-linked for instance.
> >
> > The problem with this is basically because current standard Unix FSs
> > have a separation between file names, which live in directories (and
> > that is *all* that lives in directories), and all the other file
> > metadata, which lives in (or is referenced by, for some recently-added
> > metadata) the inode. The inode knows how many names (hard links) the
> > file has, which is essentially to support a reference-counting `GC',
> > but it doesn't know where those names are.
>
> Which is yet another reason that versioning would and should simply
> ignore this.
>
> New file versions are just different files with usefully related names.
> They are NOT "the same file".
I think this would be disasterous to the Unix way of thinking of
files. If I have /home/foo/thing and /home/bar/thing both being hard
links to the same file, I don't consider them to be different files
with related names, they're the same file. Just like how:
(let ((a '(1 . #1=(2 3)))
(b '(one . #1#)))
...)
(cdr a) and (cdr b) aren't different lists with similar names, they're
the same object. If I were to say "bump the version on
/home/foo/thing" in Unix, I would assume that would actually mean,
"bump the version on the file that has the name /home/foo/thing,
possibly among other names". I would also assume I could bump the
version on a file that has no remaining names at all.
> > Files in standard Unix FSs
> > are first-class objects in other words - and indeed it is possible
> > (and reasonably common) to have files which have *no* names at all but
> > are being held in existence merely by being open.
> >
> > I think the right answer would be to associate the version information
> > with the file itself (hence with the inode), so the answer would be
> > that yes, y would get a new version too, and versioning information
> > would be somewhat separate than naming information.
>
> Oh, I think this would be a disaster. It would give opaque behavior
> where seemingly equivalent files gave different effects.
I don't get what you mean here.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@hurricane.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > New file versions are just different files with usefully related names.
> > They are NOT "the same file".
>
> I think this would be disasterous to the Unix way of thinking of
> files. If I have /home/foo/thing and /home/bar/thing both being hard
> links to the same file, I don't consider them to be different files
> with related names, they're the same file. Just like how:
>
> (let ((a '(1 . #1=(2 3)))
> (b '(one . #1#)))
> ...)
>
> (cdr a) and (cdr b) aren't different lists with similar names, they're
> the same object. If I were to say "bump the version on
> /home/foo/thing" in Unix, I would assume that would actually mean,
> "bump the version on the file that has the name /home/foo/thing,
> possibly among other names". I would also assume I could bump the
> version on a file that has no remaining names at all.
I don't think we disagree about the structural issues, but we apparently
disagree radically about what it means to edit or write a new version.
I don't use hard links, so I am both surprised and not surprised by what
you say. Surprised because it's not how I would have ever used them if I
did use them. Not surprised because I knew I had no firsthand experience
with any need for them.
I had always assumed that the whole reason for the gc issue was that
pointers were not dropped "all at once" but one at a time, and through
people writing new versions of this or that.
The real bug seems to be that the inode has no pointer back to the file
system, so that the editor can ask which of the following you want:
1. Writing a new foo.lisp over foo.lisp.1 causes:
foo.lisp.1 points to inode 1001.
bar.lisp.1 points to inode 1001.
foo.lisp.2 points to inode 1002.
bar.lisp.2 does not exist.
2. Writing a new foo.lisp over foo.lisp.1 causes:
foo.lisp.1 points to inode 1001.
bar.lisp.1 points to inode 1001.
foo.lisp.2 points to inode 1002 (explicitly created).
bar.lisp.2 points to inode 1002 (automatically created).
3. Writing a new foo.lisp over foo.lisp.1 causes:
foo.lisp.1 points to inode 1001.
bar.lisp.1 points to inode 1001.
foo.lisp.2 points to inode 1001 (shared).
bar.lisp.2 does not exist.
4. Writing a new foo.lisp over foo.lisp.1 causes:
foo.lisp.1 points to inode 1001 (bashed).
bar.lisp.1 points to inode 1001 (bashed).
foo.lisp.2 points to inode 1001 (shared).
bar.lisp.2 points to inode 1001 (automatically created, shared).
All of these issues should be in the realm of the editor. The only
reason they can't be, as far as I can tell, is that the inode contains
insufficient info to know and Unix isn't willing to keep outboard
information in a hardlinks database (which would be small because hard
links are rare) that effectively implements inode backpointers.
I think, however, that the file system should primitively have behavior
#1 when the user hasn't asked otherwise because the user should not be
creating or altering sharing where the user has not asked for it.
* Thomas F Burdick wrote:
> I think this would be disasterous to the Unix way of thinking of
> files. If I have /home/foo/thing and /home/bar/thing both being hard
> links to the same file, I don't consider them to be different files
> with related names, they're the same file. Just like how:
> (let ((a '(1 . #1=(2 3)))
> (b '(one . #1#)))
> ...)
> (cdr a) and (cdr b) aren't different lists with similar names, they're
> the same object. If I were to say "bump the version on
> /home/foo/thing" in Unix, I would assume that would actually mean,
> "bump the version on the file that has the name /home/foo/thing,
> possibly among other names". I would also assume I could bump the
> version on a file that has no remaining names at all.
Yes, this is exactly my point: files in Unix are first class objects
with identity and so forth, and versions ought to be part of that
first class object. One of the beauties of the standard Unix FS is
that directories are almost trivial things (obviously the
implementation is not trivial) which simply map file names to
references to files (namely inode numbers).
--tim
* Kent M Pitman wrote:
> Nope. Neither would you if you wrote a new version of x in the
> present system unless you chose to update the existing disk blocks
> (in which case you would not be bumping version).
Which is, of course, what some (most?) unix editors do now.
> New file versions are just different files with usefully related names.
> They are NOT "the same file".
Then Unix already has a versioned filesystem - just change libc and
it's done.
> Oh, I think this would be a disaster. It would give opaque behavior
> where seemingly equivalent files gave different effects.
yes, but that's always a problem with systems with a notion of
identity which is not `has the same name'. Lisp has this in spades,
except, somehow, we think it's good for Lisp...
--tim
+ Kent M Pitman <······@world.std.com>:
| Sure. On the Macintosh and other file systems (Multics, ITS,
| ...), "../" is just a filename.
Many years ago, I was told that, given a Macintosh on a network with a
Sun running a buggy version of NFS, it was possible to use the Mac to
create a file on the Sun with a slash in its name. And by this I
really mean an entry in the directory file containing a slash in the
filename. Of course, such a file (or rather a link, to be technical)
was impossible to remove without editing the raw disk. This kind of
story highlights the dangers of using strings for pathnames, it seems.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
* Kevin Layer wrote:
> Can you tell me how the above call to make-pathname and the following
> differ?
> (pathname "../")
> Is not the `pathname' version completely equivalent? I would also
> think it is immune to changes in the internal representation of
> pathnames, too (not that this is much of an issue given the example).
It's completely equivalent only on machines (and Lisp implementations)
where that string means the same as the MAKE-PATHNAME version. It's
not equivalent on Macs for instance (well: it might be now), and it's
not equivalent on a system which doesn't treat a trailing slash as
meaning `this is a directory'. Finally, there is confusion, if not in
theory then certainly in practice over what something like "xx/../yy/"
means on unix: is it (:relative "xx" :up "yy") or is it (:relative
"xx" :back "yy")? Even now, different programs can have different
interpretations for this with exciting consequences (like: what does
`cd ..' do, and is it the same in bash and sh? (no, it isn't)).
--tim
Kevin Layer wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Here is a really complicated use of make-pathname:
>>
>> (make-pathname :device "D" :directory '(:absolute "_distro"))
>>
>
>
> Other than discussing the behavior of make-pathname, do you have
> something which you cannot do portable?
I am playing with ASDF as my defsystem. It finds the system component by
working down a global list of pathnames (where we are to have pushed a
pathname pointing to the directory containg the system's .ASD file),
giving each pathanme as the default to its own make-pathname.
Well, one or two #+lispworks won't make this thing non-universal, and
that's what I did.
Very close now to Cello/LW, tho it ain't over till its over. Right now
OpenGL is screaming like the little bitch it is, and I am not too sure I
am communicating very well with FreeGlut, so peril abounds. I guess the
good news is that LW/CAPI supports OpenGL out the wazoo, so there's
nothing in principle to worry about.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
Reading this thread I get the impression that pathnames can be a bit
problematic. Two hours later I run into this problem:
How to open a file that has a questionmark (or an asterisk for that
matter) in its name?
This bombs out:
(with-open-file (ifile (make-pathname :name "test?page=1")
:direction :input)
())
*** - wildcards are not allowed here: #P"test?page=1"
The pathname (directory ...) gives back has the same problem.
I'm running Clisp2.27 on Debian Woody.
Cheers, Gabor Melis
* Gabor Melis wrote:
> Reading this thread I get the impression that pathnames can be a bit
> problematic. Two hours later I run into this problem:
> How to open a file that has a questionmark (or an asterisk for that
> matter) in its name?
If that's happening it's likely a bug in the implemtation. On
Unix(oid) systems "test?page=1" is a legal filename, albeit one that's
mildly hard to type to a shell.
--tim
+ ····@hotpop.com (Gabor Melis):
| Reading this thread I get the impression that pathnames can be a bit
| problematic. Two hours later I run into this problem:
| How to open a file that has a questionmark (or an asterisk for that
| matter) in its name?
|
| This bombs out:
| (with-open-file (ifile (make-pathname :name "test?page=1")
| :direction :input)
| ())
| *** - wildcards are not allowed here: #P"test?page=1"
Pathnames may contain wildcard characters. What they are, and how to
quote them, is system dependent.
| The pathname (directory ...) gives back has the same problem.
| I'm running Clisp2.27 on Debian Woody.
I am only familiar with cmucl, but I would not be surprised if clisp
handles wildcards pretty much the same way:
;;; COMMON-LISP-USER:
(wild-pathname-p #p"foo?bar")
T
;;; COMMON-LISP-USER:
(wild-pathname-p #p"foo\\?bar")
NIL
Consult the clisp documentation to find out for sure how it's done.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?