[syslinux] file names format for c32 files
Ady
ady-sf at hotmail.com
Fri Sep 18 06:23:02 PDT 2015
> 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.
More information about the Syslinux
mailing list