Logical pathname version component on non-versioned file systems

I am writing this because I find the logical pathname concept to be
very useful in theory, particularly with versioned files. However, I
don't know of any modern file system that exposes this type of
versioning to the user.

I have seen various people use a form like file.type.~version~ but I
do not know how they implement this using logical pathnames, if at
all.

I would think that an even better solution would be one that made use
of some kind of actual versioning, where a save operation causes the
previous version of the file to be archived and the newly saved
version to become :NEWEST. This could be accomplished with rcs or the
like. Is there any CL implementation that would allow for such a hook
to be built into the logical pathname translations, both on save and
on load?

If not, is there a good reference for any of the existing
implementations' implementation of logical pathnames? The HyperSpec
falls short of giving any implementation-dependent details, of course,
and a quick Google search for "<your implementation here>
logical-pathname-translations" comes up short for the values of <your
implementation here> that I attempted.

Am 02.12.2006 22:55 Uhr schrieb "Ari Johnson" unter <iamtheari@gmail.com> in
m21wnihsjb.fsf@hermes.theari.com:

> I am writing this because I find the logical pathname concept to be
> very useful in theory, particularly with versioned files. However, I
> don't know of any modern file system that exposes this type of
> versioning to the user.

File versions are independent of logical pathnames. File
versions were very popular in VMS (-> OpenVMS) or LMFS (the Lisp Machine
file system). ISO 9660 (used by CDROMs) also supports file versions.

See: http://en.wikipedia.org/wiki/Versioning_file_system

Logical pathnames are supporting file versions, because in some Lisp systems
source code was usually stored in versioned file systems and Logical
Pathnames were used to refer to specific versions of a file. In those
systems there were physical pathnames that used those versions.
On the Lisp Machine there were different classes (or flavors)
of pathnames. The Common Lisp standard (ASNI CL) doesn't have
these concepts of multiple different file systems with different
capabilies. Versioning of files is just one of these differences
between file systems. For example in HFS+ (from Apple) files
have types, creators, various meta data and so called 'forks'
(not just data forks, but arbitrary numbers of other data).

> I have seen various people use a form like file.type.~version~ but I
> do not know how they implement this using logical pathnames, if at
> all.

This is just a convention. If you store files on the Lisp Machine
on a, say, NFS file system, the Lisp Machine uses such a naming
convention for the filenames.

>
> I would think that an even better solution would be one that made use
> of some kind of actual versioning, where a save operation causes the
> previous version of the file to be archived and the newly saved
> version to become :NEWEST.

Like in versioning file systems. See above.

> This could be accomplished with rcs or the
> like. Is there any CL implementation that would allow for such a hook
> to be built into the logical pathname translations, both on save and
> on load?
>
> If not, is there a good reference for any of the existing
> implementations' implementation of logical pathnames? The HyperSpec
> falls short of giving any implementation-dependent details, of course,
> and a quick Google search for "<your implementation here>
> logical-pathname-translations" comes up short for the values of <your
> implementation here> that I attempted.

Rainer Joswig <joswig@lisp.de> writes:

> Am 02.12.2006 22:55 Uhr schrieb "Ari Johnson" unter <iamtheari@gmail.com> in
> m21wnihsjb.fsf@hermes.theari.com:
>
>> I am writing this because I find the logical pathname concept to be
>> very useful in theory, particularly with versioned files. However, I
>> don't know of any modern file system that exposes this type of
>> versioning to the user.
>
> File versions are independent of logical pathnames. File
> versions were very popular in VMS (-> OpenVMS) or LMFS (the Lisp Machine
> file system). ISO 9660 (used by CDROMs) also supports file versions.
>
> See: http://en.wikipedia.org/wiki/Versioning_file_system
>
> Logical pathnames are supporting file versions, because in some Lisp systems
> source code was usually stored in versioned file systems and Logical
> Pathnames were used to refer to specific versions of a file. In those
> systems there were physical pathnames that used those versions.
> On the Lisp Machine there were different classes (or flavors)
> of pathnames. The Common Lisp standard (ASNI CL) doesn't have
> these concepts of multiple different file systems with different
> capabilies. Versioning of files is just one of these differences
> between file systems. For example in HFS+ (from Apple) files
> have types, creators, various meta data and so called 'forks'
> (not just data forks, but arbitrary numbers of other data).
>
>> I have seen various people use a form like file.type.~version~ but I
>> do not know how they implement this using logical pathnames, if at
>> all.
>
> This is just a convention. If you store files on the Lisp Machine
> on a, say, NFS file system, the Lisp Machine uses such a naming
> convention for the filenames.
>
>>
>> I would think that an even better solution would be one that made use
>> of some kind of actual versioning, where a save operation causes the
>> previous version of the file to be archived and the newly saved
>> version to become :NEWEST.
>
> Like in versioning file systems. See above.
>
>> This could be accomplished with rcs or the
>> like. Is there any CL implementation that would allow for such a hook
>> to be built into the logical pathname translations, both on save and
>> on load?
>>
>> If not, is there a good reference for any of the existing
>> implementations' implementation of logical pathnames? The HyperSpec
>> falls short of giving any implementation-dependent details, of course,
>> and a quick Google search for "<your implementation here>
>> logical-pathname-translations" comes up short for the values of <your
>> implementation here> that I attempted.

Is the following a restatement of your answer?

It requires both a versioning file system and a Common Lisp
implementation that is aware of and exploits the versioning
file system in order to make actual use of the :VERSION
component of a Common Lisp logical pathname.

I understand that versioning file systems do exist and that various
lisps over time have supported them, the lisp machines being a good
example of that. However, I am more interested in making use of this
facility by emulating a versioning file system on top of a
non-versioning file system. If the save and load operations could be
remapped to (progn (save) (rcs-commit)) and (if (eql version :latest)
(load) (load-previous-rcs-version)) respectively, this emulation would
be possible. That's my real curiosity here.

My second curiosity is toward a complete user's manual for the logical
pathname facility as it exists in one of the implementations that I
use (such as OpenMCL or SBCL).

Am 03.12.2006 0:28 Uhr schrieb "Ari Johnson" unter <iamtheari@gmail.com> in
m2y7pp27z5.fsf@hermes.theari.com:

....

> Is the following a restatement of your answer?
>
> It requires both a versioning file system and a Common Lisp
> implementation that is aware of and exploits the versioning
> file system in order to make actual use of the :VERSION
> component of a Common Lisp logical pathname.

No. On the Lisp Machine you can store versions of files
on a Unix File system (via NFS for example).
The version numbers are just appended
to the usual pathnames. The pathname and file system code
take care of creating new versions and so on.

Logical Pathnames have versions. Right. Any operation
that accepts logical pathnames (CL:OPEN, ...)
translates logical pathnames to physical pathnames first.
(see http://www.lisp.org/HyperSpec/Issues...9-writeup.html ).

-> LOGICAL PATHNAMES are translated to PHYSICAL PATHNAMES when used.

So you need some kind of mapping from logical pathnames
to physical pathnames. This means you need support
for versions also in physical pathnames or you need to
map the version component from a logical into the
component of a physical pathname.

Example

foo:bar;baz.lisp;3 could be /Volumes/disk1/foo/bar/baz.lisp~3~

Now you have to ways to deal with the function PATHNAME-TYPE:

PATHNAME-TYPE for the logical pathname returns "lisp".

Alternative one: The implementation for physical pathnames supports version
numbers.

PATHNAME-TYPE for the physical pathname returns "lisp".

Alternative two: The implementation for physical pathnames doesn't support
version numbers.

PATHNAME-TYPE for the physical pathname returns "lisp~3~".

Both have their problems. But conceptually alternative one
might be better (since PATHNAME-TYPE returns the same for the logical
pathname and the translated physical pathname).

This means, if you want versions in logical
pathnames, you need support for versions in physical pathnames, too.
The consequence of that is that you need support for versions
in all routines that access files (OPEN (and WITH-OPEN-FILE),
RENAME-FILE, DELETE-FILE, PROBE-FILE, FILE-WRITE-DATE,
FILE-AUTHOR, LOAD, COMPILE-FILE, ED, DRIBBLE, ...).

> I understand that versioning file systems do exist and that various
> lisps over time have supported them, the lisp machines being a good
> example of that. However, I am more interested in making use of this
> facility by emulating a versioning file system on top of a
> non-versioning file system. If the save and load operations could be
> remapped to (progn (save) (rcs-commit)) and (if (eql version :latest)
> (load) (load-previous-rcs-version)) respectively, this emulation would
> be possible. That's my real curiosity here.
>
> My second curiosity is toward a complete user's manual for the logical
> pathname facility as it exists in one of the implementations that I
> use (such as OpenMCL or SBCL).

You may find some information here:

http://www.cs.cmu.edu/Groups/AI/html...TION0027150000
00000000000
http://www.franz.com/support/documen...tm#logical-pat
hnames-1

The older Explorer Programming Concepts
(
http://bitsavers.trailing-edge.com/p...1A_PgmgConcept
s.pdf )
might be interesting for some historical perspective...

Ari Johnson <iamtheari@gmail.com> writes:

> I am writing this because I find the logical pathname concept to be
> very useful in theory, particularly with versioned files. However, I
> don't know of any modern file system that exposes this type of
> versioning to the user.
>
> I have seen various people use a form like file.type.~version~ but I
> do not know how they implement this using logical pathnames, if at
> all.

Well if we had sane implementations of logical pathnames on unix, we
could write:

(setf (logical-pathname-translations "FS-WITH-VERSION")
(list "**;*.*.*" "/**/*.*.~*~"))

and be done, but this doesn't work with the actual implementations I
know.


> I would think that an even better solution would be one that made
> use of some kind of actual versioning, where a save operation causes
> the previous version of the file to be archived and the newly saved
> version to become :NEWEST. This could be accomplished with rcs or
> the like. Is there any CL implementation that would allow for such
> a hook to be built into the logical pathname translations, both on
> save and on load?

AFAIK, no hook. You'd have to reimplement all the logical pathname
module.


> If not, is there a good reference for any of the existing
> implementations' implementation of logical pathnames? The HyperSpec
> falls short of giving any implementation-dependent details, of course,
> and a quick Google search for "<your implementation here>
> logical-pathname-translations" comes up short for the values of <your
> implementation here> that I attempted.

--
__Pascal Bourguignon__ http://www.informatimago.com/

IMPORTANT NOTICE TO PURCHASERS: The entire physical universe,
including this product, may one day collapse back into an
infinitesimally small space. Should another universe subsequently
re-emerge, the existence of this product in that universe cannot be
guaranteed.