[syslinux] file names format for c32 files

[Ady]

> 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.


> 
> 
> And now something completely different:
> > > _______________________________________________
> > > Syslinux mailing list
> > > Submissions to Syslinux at zytor.com
> > > Unsubscribe or set options at:
> > > http://www.zytor.com/mailman/listinfo/syslinux
> > > 
> > 
> > 
> > _______________________________________________
> > Syslinux mailing list
> > Submissions to Syslinux at zytor.com
> > Unsubscribe or set options at:
> > http://www.zytor.com/mailman/listinfo/syslinux
> 
> What is the value quoting those lines?
> 
> 
> Groeten
> Geert Stappers
> -- 
> Leven en laten leven
> 

Hehe, OK, I'll bite again :)

Because the official Syslinux Mailing List is not cached by popular web 
search engines, so the sites where this mailing list can be found are 
of doubtful reputation – one of their main goals is to collect 
potentially valid email addresses. In some cases, these fishy sites are 
quoted or linked to – even here in the mailing list; that's a fact I 
would rather not see happening again – instead of linking to the 
official mailing list archives.

So, one way for me to help users in finding this mailing list and its 
official archives, while reducing the use of some of these doubtful 
sites, is to quote the official mailing list information. Then, it 
might be also quoted / found / read, and in some cases some emails 
might see the light into some popular web search engines.

Perhaps one day someone will take care of the (small) issues causing 
popular web search engines to catalog this mailing list as "dead", 
"abandoned" or similar, and then some day they might be willing to 
provide the mailing list archives in their search results again.

Regards,
Ady.