[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