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? 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/syslinuxWhat is the value quoting those lines? Groeten Geert Stappers -- Leven en laten leven ------------- volgend deel ------------ Een niet-tekst bijlage is gescrubt... Naam: signature.asc Type: application/pgp-signature Grootte: 836 bytes Omschrijving: Digital signature URL : <http://www.zytor.com/pipermail/syslinux/attachments/20150918/5186b137/attachment.sig>
> 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.
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