[syslinux] file names format for c32 files

[Geert Stappers]

On Fri, Sep 18, 2015 at 04:16:50PM +0200, Didier Spaier via Syslinux wrote:
> On 18/09/2015 15:23, Ady via Syslinux wrote:
> > Stappers wrote:
> >> On Fri, Sep 18, 2015 at 02:01:32PM +0300, Ady via Syslinux wrote:
> >>>
> >>> @Developers, please consider using 8.3 file names format for c32 files
> >>> instead of such a long file name.
> >>
> >> Example of such a long file name?
> >>
> >> So we know which file name to surpress into 8.3.
> >> ( yes, CP/M file name convention legacy is still present )
> >>
> >>
> >>> If possible, also use short names for source files too. TIA.
> >>
> >> Euh, please visit http://www.dmst.aueb.gr/dds/pubs/conf/2015-MSR-Unix-History/html/Spi15c.html
> >> scroll down to '4 Data Uses', check the graphic, especial file name length.
> >>
> >> My point: _Why_ restrict the development system  file name length?
> >>
> >
> > Hehe, OK, I'll bite :).
> >
> > The length of file names under some generic common-user situation might
> > not be important nowadays, but I still think it is relevant when
> > talking about The Syslinux Project.

Yes, on the _target_ system, not on the _development_ system.


> > While testing Syslinux features, one set of tests I perform is about
> > file systems. So, among other things, I test the different installers,
> > including the DOS-based one ??? which happens to be important to me,
> > while I am aware that others don't even remember it exists ??? and I also
> > test ISOLINUX. For instance, I test whether files can be read
> > correctly, whether the configuration files can be found where they
> > should and in the documented order, whether the directory paths are
> > mangled as a common user would expect, and so on. You might think all
> > this is trivial, but this is how I have found and reported several bugs
> > in the past.
> >
> > I purposely test SYSLINUX under an environment without long file name
> > (LFN) support under DOS, among other cases.
> >
> > Another case: When building an ISO image, the resulting file name
> > resolution might depend on the specific options that were used in
> > mkisofs (or similar). The file name support in ISO9660 Level 1 is
> > limited, in a very similar way as the "DOS 8.3" format ??? this is not a
> > coincidence.
> >
> > This is one of the reasons why certain tools that "transform" ISO
> > images into something bootable from a (USB) portable storage device
> > have some different and/or unexpected results in some cases. For
> > example, if the ISO image was built with Rock Ridge support, or with
> > Joliet support, or with Level 1/2/3/4, then the file names in the ISO
> > (and therefore, in the resulting storage device) can be slightly
> > different. There are more considerations, but this is enough for the
> > purpose of this email.
> >
> > In my tests, I sometimes put the Syslinux distribution archives in an
> > ISO image, together with the binaries. I might use the whole archive,
> > or only part of its content.
> >
> > So, lets say I put "localboot.c32" in an ISO image and I want to use it
> > / test it. If the ISO image is built with ISO9660 Level 1 only, then
> > typing in "localboot.c32" in the ISOLINUX command prompt will fail, no
> > matter what I would do. The reason: "localboot.c32" does not comply
> > with the "8.3" file name format, so ISO Level 1 cannot understand this
> > file name "as-is". In other words, the file name is too long.
> >
> > Now, what happens if I change the file name, "localboot.c32", into
> > something else like, say, "local.c32", or "lboot.c32" before building
> > the ISO image? I could type in "local.c32" in the ISOLINUX command
> > prompt and the file would be correctly found and then executed.
> >
> > If there is a really compelling reason to actually use long file names
> > in Syslinux, it is not going to be the end of the world. But, if it can
> > be avoided and use "8.3" file name format whenever possible, I think we
> > should. Why complicate the lives of ISO builders, and users, and
> > partial file system support, with no practical gain?
> >
> > I shall mention that the c32 library modules in v.5.00 were originally
> > named in a non-compliant way, and of course they failed to work in
> > ISO9660 Level 1 and in FAT without LFN support. After reporting it,
> > Peter changed their names.
> >
> > BTW, although binary files (e.g. c32 modules, installers, memdisk...)
> > are seen and used by common users much more than source code files, I
> > have the same request / suggestion for the latter group: use "8.3"
> > whenever possible.
> 
> I will add a little reminder, maybe off topic.
> 
> Assuming that we are trying to be as much POSIX compliant as possible,
> we could follow theses recommendations, cf.
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_278
> 
> <quote>
> 3.278 Portable Filename Character Set
> 
> The set of characters from which portable filenames are constructed.
> 
> A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
> a b c d e f g h i j k l m n o p q r s t u v w x y z
> 0 1 2 3 4 5 6 7 8 9 . _ -
> 
> The last three characters are the <period>, <underscore>, and <hyphen>
>  characters, respectively. See also Pathname.
>  <end quote>
> 
>  I do not see an issue here.
> 
>  But we could also follow, among the Utility Syntax Guidelines, cf.
> 
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html#tag_12_02
> 
>  <quote>
>  Guideline 1:
>     Utility names should be between two and nine characters, inclusive.
> Guideline 2:
>     Utility names should include lowercase letters (the lower character
>     classification) and digits only from the portable character set.
> </quote>
> 
> Just my two cents.
> Didier
> 

> >> Example of such a long file name?
> >>
> >> So we know which file name to surpress into 8.3.

Off-list information:
 {cpuidtest,entrydump,fancyhello,kontron_wdt,localboot,serialinfo}.c32

Rename proposal
 N.c32       ->   8.c32
 cpuidtest   -> cpuidtst
 entrydump   -> ntrydump
 fancyhello  -> fncyhelo
 kontron_wdt -> kntrnwdt
 localboot   -> loclboot
 serialinfo  -> serilnfo

Other rename proposals are welcome.


Groeten
Geert Stappers
http://www.syslinux.org/wiki/index.php/Library_modules#Syslinux_modules_working_dependencies
-- 
Leven en laten leven