Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!as From: as@castle.ed.ac.uk (A Stevens) Newsgroups: comp.sys.acorn,eunet.micro.acorn Subject: DOS/UNIX/etc <-> ADFS Filename Mapping Message-ID: <7850@castle.ed.ac.uk> Date: 15 Jan 91 18:44:51 GMT Sender: as@castle.ed.ac.uk Organization: Edinburgh University Computing Service Lines: 97 The need for a convention for filename extensions =============================================== One serious complication when porting code or file-structures to and from the Arch is its unfortunate combination of short (10 char) filenames and an absence of filename extensions. To convert filenames from DOS (effectively 11 chars if you count the extension) or UNIX or VMS some kind of transformation has to be performed. The catch is not that this is impossible, just that there are so many different ways to do it, so programs tend not work in the same way. Clearly some kind of de facto standard is required if we are to avoid the current situation which boils down to alternate sighs of relief and swearing. (The situation puts me in mind of the ``long command line'' problem that complicated life on ST's until things settled down). A proposal for Handling filename extensions ------------------------------------------- Turn ``filename.ext'' into ``ext.filename''. Advantages: + Can cope with those long filename suffixes that come up in UNIX. You could systematically convert a UNIX file ``foo.longsuff'' to ``longsuff.foo''. Compound suffixes might be neatly broken up by swapping . for / (not common inside UNIX or DOS filenames ). E.g. ``foo.e1.e2.e3'' into ``e1/e2/e3.foo''. The catch with this approach, pure, is that it loses information. Once a directory/file tree has been turned into ADFS form, you can no longer guess which directories are simply there to support filename suffixes, and which were part of the original directory structure. The best solution here seems to be the one Arxe systems use for their MultiFS. I.e. directories used to replace filename extensions are distinguished by having ``/'' as the last character of their names. E.g. foo.baz -> baz/.foo fred.tar.Z.uu -> tar/Z/uu/.fred The trailing slash also has a nice symmetrical feel when you use slashes to separate parts of a comound suffix. + This method would work with stuff like ``make'', ``amu'', and would (of course) interface nicely with Arxe's Multi-FS. Disadvantages: - This approach would require significant programming support. A whole bunch of routines would be needed to hide the transformation from naive ported DOS or UNIX code. Either file-access routines would need to be equipped with smart (and slow) routines to disambiguate combinations of ADFS and UNIX/DOS conventions (e.g. what is the suffix in ``$.Library.fred.c.Z''?) or porting would require a little programming effort. I.e. Filenames input would need to be converted to ADFS from UNIX/DOS conventions for internal processing, and then converted back to ADFS when the results are finally passed to file-access routines. In either case, file-access routines would need to be smart enough to create and delete suffix directories as required. - This convention is not understood used by what, for me at least, are pretty important programs. Graham Toals TeX, and Frank Lancaster's tar. Dealing with long filenames? ---------------------------- Handling filename suffixes is of course not the whole story. A similarly difficult problem is what to do with (UNIX etc) filenames that, even without suffixes, are longer than 10 characters. Again there are lots of different approaches. Some programs just truncate, others are a lot cleverer. Frank Lancaster's tar port seems to do something pretty smart with stripping out vowels and the like. Perhaps Frank could be persuaded to tell us the cunning details to provide a basis for a ``standard''? What do people feel about this issue? Will Acorn ever bring out a filing system with long names? :-) Andrew