Put extension after medley version in Unix-directory filenames?

[rmkaplan]

The most recent version of a Medley file (say foo.pdf;25) appears in the Unix directory as foo.pdf, with a separate link that records the version number. So that link shows up as foo.pdf.~25~ and earlier versions show up as unlinked files with the same name-format (e.g. foo.pdf.~24~.

This goes against the modern operating-system convention that the final extension of the file is the key to the generic open operation: you can double-click on foo.pdf to open a pdf viewer, but that doesn't work for foo.pdf.~24~. Frank wrote a utility to produce temporary filenames in the Unix directory that swap the version number with the logical extension (foo.~24~.pdf) so that the call to ShellOpen in Medley will trigger the desired operating-system behavior on that file.

I presume that this version-last encoding was originally chosen for Unix files, perhaps without deeper reflection, because the version appeared last in historical predecessors (Tenex, IFS...). But in modern times it would certainly be more convenient if the components were swapped so that the true extension (if any) comes last.

So my feature request is to change the way that the names for new {DSK} files are represented in the Unix directory, with some fooling around so that Medley maps both old and new formats to the same internal format. I don't know whether this is something that happens at the Maiko level or somewhere in the DSK or Unix Medley file devices (and perhaps in UNPACKFILENAME/PACKFILENAME for the {UNIX} device.

Comments?

[nbriggs]

Please be explicit about all the cases for extension, no extension, version, no version and the exact punctuation you suggest -- I believe the current enumeration code depends on being able to start at a particular point in the file enumeration and step through the names in sorted order until it finds one where the unversioned name changes while this proposal will mix foo.~24~.pdf, foo.~24.txt, foo.~25~.pdf, ...

Note also that Emacs uses the same scheme (foo.el.~3~)

All the name fakery happens in the Maiko DSK device code.

[nbriggs]

This is what the lispusers/COMPARE* files listing would be like with the proposed scheme (only looking at the files with versions and extensions) listing.txt

[nbriggs]

I presume that the printed Lisp representation of the names would remain foo.pdf;24 so the [UN]PACKFILENAME code would remain the same.

If the DSK code were to map both old and new format to the same internal name - what would happen if you have both foo.pdf.~23~ and foo.~23~.pdf present in the same directory?

[rmkaplan]

The revised Medley code for creating and manipulating files and names would not create this kind of confusion. If an old form exists, a new version would be created with the bumped up new-format version number.

I think this situation should arise only if files are moved around outside of Medley, at the Unix level or in the {UNIX} file device. At that level those would be just 2 different files.

So the question is, what would happen when code inside of Medley is asked to do something with {DSK}foo.pdf, and it detects the occurrence of files with different (new and old) names that are intended to be version-synonymous. Perhaps if they are actually the same file, Medley could do something automatically to get rid of the anomaly. But a generally safe approach for this unlikely situation would be to alert the user that something is screwed up and needs to be fixed up (by doing something at the Unix level or in the {UNIX} file device).

(A user who wants to systematically make the transition could run a Medley utility to translate old-format names in a new directory to new, the way we fix directory dates to match the internal dates of Lisp and Tedit files no matter how the files were downloaded. But probably better to let the names migrate over time, without renaming old files.)

On Sep 7, 2024, at 10:24 PM, Nick Briggs @.***> wrote:

I presume that the printed Lisp representation of the names would remain foo.pdf;24 so the [UN]PACKFILENAME code would remain the same.

If the DSK code were to map both old and new format to the same internal name - what would happen if you have both foo.pdf.~23~ and foo.~23~.pdf present in the same directory?

— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/1824#issuecomment-2336552755, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJKMHWBZQ3XPQCKVHVDZVPNRVAVCNFSM6AAAAABN2TRYKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZWGU2TENZVGU. You are receiving this because you authored the thread.

[masinter]

some background on the "file type" problem and why it isn't simple can be found in

US8099445B1 - File dispatcher for multiple application targets - Google Patents https://patents.google.com/patent/US8099445

The present invention relates to manipulating files in a computing environment. Software applications create and manipulate files. Each file is characterized by a file type, which can be indicated to the operating environment by a file extension or MIME (Multipurpose Internet Mail Extensions) type. For example, TIFF files (Tagged Image File Format) have a MIME type of “image/tiff” and a “.tif” extension, while PDF files (Portable Document Format) have a MIME type of “application/pdf” and a “.pdf” file extension. In addition, some file types have a “magic number”: an initial sequence of bytes or data at the beginning of the file which only appears (or is likely to appear) in files of a particular type. As used in this specification, the term file type can be a complex of different components. File type can include file extension (“.pdf”), MIME type or content-type (“application/pdf”) and/or “a magic number,” a special sequence of bytes that only appear inside files of a particular type. The different ways of indicating or determining file type are usually, but need not, be correlated. For example, a single MIME type can correspond to several file extensions, one file extension can be used by several MIME types, and file type determination by magic number detection is often unreliable. In many operating environments, file types can be associated with a default application. For example, in a typical computer system installation, Microsoft PowerPoint® software available from Microsoft Corporation of Redmond, Wash. may open PowerPoint files, Adobe® Acrobat® software available from Adobe Systems Incorporated of San Jose, Calif. may open PDF files, etc. In most operating systems, such as the Macintosh® or Windows® environments, users can associate a specified application with a particular file extension or MIME type to make the specified application the default opener for the particular file extension or MIME type. In some cases, operating systems check for a default opener whenever a file is opened. When a default application has been specified, to use any other application to open a file a user must launch the other application separately and select the file from within that application, drag the file icon to the application icon or use another file opening method. (more in the patent)

https://LarryMasinter.net https://interlisp.org