[syslinux] file names format for c32 files

Didier Spaier didier at slint.fr
Fri Sep 18 07:16:50 PDT 2015



On 18/09/2015 15:23, Ady via Syslinux wrote:
 >
 >> On Fri, Sep 18, 2015 at 02:01:32PM +0300, Ady via Syslinux wrote:
 >>>>
 >>>> We have pxechn.c32 working with pxelinux.0 to switch between the two
 >>>> system, but pxechn.c32 under Uefi come up with the folowing error
 >>>
 >>>
 >>> @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.
 >
 > 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



More information about the Syslinux mailing list