Linux & FAT32 label

Linux & FAT32 label

[Pali Rohár]

Hi! There is a big inconsistency in Linux tools which read or write
FAT32 label in filesystem images. The most common used are tools:
blkid (from util-linux project), fatlabel (previously known as
dosfslabel; from dosfstools project) and mlabel (from mtools project).

FAT32 is itself a big mess from Microsoft hell and even FAT32
implementation in Microsoft Windows systems is not compliant to the
released FAT32 documentation from Microsoft.

In past months I observed that Linux FAT32 tools has its own way how
they interpret FAT32 label (known as volume id) and because every GUI
application uses one of those low-level command line tool, it is a big
mess if one application say that FAT32 label is A and another that it is
B. And then Windows XP say, it is C.

I would like to open discussion if it would be possible to change
behavior how blkid (from util-linux project) and fatlabel (from
dosfstool project) handle FAT32 label. Ideally to report exactly same
output.

Basic information about FAT32 label:

1) It is stored in two locations: boot sector and root directory as
   file name.

2) In both location format is 11 bytes, padded with spaces (not nulls).

3) Empty label in boot sector is stored as "NO NAME    " and not as
   empty string.

4) Empty label in root directory is stored either as name which starts
   with byte 0xE5, or is not stored in root directory at all.

5) If label contains leading byte 0xE5, then in root directory is stored
   as byte 0x05.

6) Label string is stored according to current DOS code page. Therefore
   label string needs to be converted to bytes.

7) Label string cannot contain control characters and characters from
   the set   ? / \ | . , ; : + = [ ] < > "   plus lower case characters
   are stored as their upper case variant (not only ASCII).

(Please correct me if I'm wrong in some of those points)

Plus Microsoft Windows systems fully ignores label stored in boot
sector. Seems they do not read it nor they do not update it on changes.

Looks like that mlabel (from mtools) applies all above rules and uses
DOS code page 850 by default (can be changed in config file).

blkid and fatlabel process special cases from 1) to 5) differently and
they operates on raw bytes, not strings (in DOS code page).

mlabel reads label from the root directory (missing entry is interpreted
as no label; there is no fallback to boot sector), but "set" operation
modify label in both location boot sector + root directory. Basically it
is near to Windows implementation. And reason why Gparted GUI
application uses mlabel and not fatlabel.

As Linux does not have "current DOS code page" and argv arguments are
not (Unicode) strings, but arbitrary bytes, I understand that for point
6) it is easier to operates not on FAT strings (in current code page),
but rather on bytes. Which also would be same on all machines with any
configuration.

But would it be possible to decide and unify handling of point 2), 3),
4), 5)? Ideally with combination how to handle situation when different
label is stored in boot sector and root directory.

As Windows does not use label in boot sector, it is very common
situation that label in boot sector differs from the root directory.

The best would be see in all cases same label from blkid, fatlabel and
mlabel. Ideally same as Windows machines -- but due to DOS code page,
this is possible only for ASCII subset of the 8bit encoding. IIRC most
(or all?) DOS code page has same characters in printable ASCII range.

It is really bad situation if I open disk in Gparted which show me label
via mlabel and then I open in KDE Partition Manager and I see different
label string (as it reads it from fatlabel).

Also note that older version of fatlabel (when it was named dosfslabel)
operated only the label stored in boot sector (and label stored in root
directory was not read or touched).

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Pali Rohár]

On Wednesday 04 October 2017 17:33:32 Pali Rohár wrote:
> Hi! There is a big inconsistency in Linux tools which read or write
> FAT32 label in filesystem images. The most common used are tools:
> blkid (from util-linux project), fatlabel (previously known as
> dosfslabel; from dosfstools project) and mlabel (from mtools project).
> 
> FAT32 is itself a big mess from Microsoft hell and even FAT32
> implementation in Microsoft Windows systems is not compliant to the
> released FAT32 documentation from Microsoft.
> 
> In past months I observed that Linux FAT32 tools has its own way how
> they interpret FAT32 label (known as volume id) and because every GUI
> application uses one of those low-level command line tool, it is a big
> mess if one application say that FAT32 label is A and another that it is
> B. And then Windows XP say, it is C.
> 
> I would like to open discussion if it would be possible to change
> behavior how blkid (from util-linux project) and fatlabel (from
> dosfstool project) handle FAT32 label. Ideally to report exactly same
> output.
> 
> Basic information about FAT32 label:
> 
> 1) It is stored in two locations: boot sector and root directory as
>    file name.
> 
> 2) In both location format is 11 bytes, padded with spaces (not nulls).
> 
> 3) Empty label in boot sector is stored as "NO NAME    " and not as
>    empty string.
> 
> 4) Empty label in root directory is stored either as name which starts
>    with byte 0xE5, or is not stored in root directory at all.
> 
> 5) If label contains leading byte 0xE5, then in root directory is stored
>    as byte 0x05.
> 
> 6) Label string is stored according to current DOS code page. Therefore
>    label string needs to be converted to bytes.
> 
> 7) Label string cannot contain control characters and characters from
>    the set   ? / \ | . , ; : + = [ ] < > "   plus lower case characters
>    are stored as their upper case variant (not only ASCII).
> 
> (Please correct me if I'm wrong in some of those points)
> 
> Plus Microsoft Windows systems fully ignores label stored in boot
> sector. Seems they do not read it nor they do not update it on changes.
> 
> Looks like that mlabel (from mtools) applies all above rules and uses
> DOS code page 850 by default (can be changed in config file).
> 
> blkid and fatlabel process special cases from 1) to 5) differently and
> they operates on raw bytes, not strings (in DOS code page).
> 
> mlabel reads label from the root directory (missing entry is interpreted
> as no label; there is no fallback to boot sector), but "set" operation
> modify label in both location boot sector + root directory. Basically it
> is near to Windows implementation. And reason why Gparted GUI
> application uses mlabel and not fatlabel.
> 
> As Linux does not have "current DOS code page" and argv arguments are
> not (Unicode) strings, but arbitrary bytes, I understand that for point
> 6) it is easier to operates not on FAT strings (in current code page),
> but rather on bytes. Which also would be same on all machines with any
> configuration.
> 
> But would it be possible to decide and unify handling of point 2), 3),
> 4), 5)? Ideally with combination how to handle situation when different
> label is stored in boot sector and root directory.
> 
> As Windows does not use label in boot sector, it is very common
> situation that label in boot sector differs from the root directory.
> 
> The best would be see in all cases same label from blkid, fatlabel and
> mlabel. Ideally same as Windows machines -- but due to DOS code page,
> this is possible only for ASCII subset of the 8bit encoding. IIRC most
> (or all?) DOS code page has same characters in printable ASCII range.
> 
> It is really bad situation if I open disk in Gparted which show me label
> via mlabel and then I open in KDE Partition Manager and I see different
> label string (as it reads it from fatlabel).
> 
> Also note that older version of fatlabel (when it was named dosfslabel)
> operated only the label stored in boot sector (and label stored in root
> directory was not read or touched).
> 

Hi! I did some testing of FAT32 label with different tools and here are
results:

                                                 dosfslabel 3.0.12   fatlabel 4.1       blkid 2.20.1   mlabel 4.0.12   label.exe Windows XP
fat32_mkdosfs_label1                             'label1     '       'label1     '      'label1'       'label1     '   'label1'
fat32_mkdosfs_label1_dosfslabel_empty            '           '       '           '      none           '           '   none
fat32_mkdosfs_label1_dosfslabel_label2           'label2     '       'label2     '      'label2'       'label2     '   'label2'
fat32_mkdosfs_label1_dosfslabel_NO_NAME          'NO NAME    '       'NO NAME    '      none           'NO NAME    '   'NO NAME'
fat32_mkdosfs_label1_mlabel_erase                'NO NAME    '       'NO NAME    '      none           none            none
fat32_mkdosfs_label1_mlabel_NO_NAME              'NO NAME    '       'NO NAME    '      none           'NO NAME    '   'NO NAME'
fat32_mkdosfs_label1_xp_erase                    'label1'    '       0xE5'abel1     '   'label1'       none            none
fat32_mkdosfs_label1_xp_label2                   'label1'    '       'LABEL2     '      'LABEL2'       'LABEL2     '   'LABEL2'
fat32_mkdosfs_none                               '           '       '           '      none           none            none
fat32_mkdosfs_none_dosfslabel_label1             'label1     '       'label1     '      'label1'       none            none
fat32_mkdosfs_none_dosfslabel_label1_xp_label2   'label1'    '       'LABEL2     '      'LABEL2'       'LABEL2     '   'LABEL2'
fat32_mkdosfs_none_dosfslabel_NO_NAME            'NO NAME    '       'NO NAME    '      none           none            none
fat32_mkdosfs_none_xp_label1                     '           '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'
fat32_mkdosfs_none_xp_label1_dosfslabel_label2   'label2     '       'label2     '      'label2'       'label2     '   'label2'
fat32_xp_label1                                  'NO NAME    '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'
fat32_xp_none                                    'NO NAME    '       'NO NAME    '      none           none            none
fat32_xp_none_dosfslabel_label1                  'label1     '       'label1     '      'label1'       none            none
fat32_xp_none_mlabel_label1                      'LABEL1     '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'

In the first column is image name (all images are compressed and
attached) which contains steps of operations, e.g. file name
fat32_mkdosfs_none_dosfslabel_label1_xp_label2 means:

1. create filesystem with mkdosfs without specifying label
2. change label with dosfslabel (3.0.12) to 'label1'
3. change label under Windows XP to 'label2'

>From testing it looks like that different tools and different version of
them have different behavior how they read or write FAT32 label, see
following table:

                             read boot   write boot   read root   write root
dosfslabel 3.0.0  - 3.0.6    YES         YES          NO          NO
dosfslabel 3.0.7  - 3.0.15   YES         YES          NO          BUGGY (YES - if already exists; NO - otherwise)
dosfslabel 3.0.16 - 4.1      YES         YES          YES         YES
label.exe Windows XP         NO          NO           YES         YES
blkid                        YES         NO           YES         NO
mlabel                       NO          YES          YES         YES


Attached images in compressed form has only 600 kB and I think they can
be useful for testing either blkid or dosfstools project, so I'm sending
them here.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

On Wednesday 11 October 2017 23:24:35 Pali Rohár wrote:
> Attached images in compressed form has only 600 kB and I think they can
> be useful for testing either blkid or dosfstools project, so I'm sending
> them here.

Gmail refused to send .tar.gz archive. So I'm sending tar.bz2. It is
just 9 kB (.tar.gz was 600 kB).

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: images.tar.bz2 --]
[-- Type: application/octet-stream, Size: 8861 bytes --]

Re: Linux & FAT32 label

[Pali Rohár]

On Wednesday 11 October 2017 23:24:35 Pali Rohár wrote:
> On Wednesday 04 October 2017 17:33:32 Pali Rohár wrote:
> > Hi! There is a big inconsistency in Linux tools which read or write
> > FAT32 label in filesystem images. The most common used are tools:
> > blkid (from util-linux project), fatlabel (previously known as
> > dosfslabel; from dosfstools project) and mlabel (from mtools project).
> > 
> > FAT32 is itself a big mess from Microsoft hell and even FAT32
> > implementation in Microsoft Windows systems is not compliant to the
> > released FAT32 documentation from Microsoft.
> > 
> > In past months I observed that Linux FAT32 tools has its own way how
> > they interpret FAT32 label (known as volume id) and because every GUI
> > application uses one of those low-level command line tool, it is a big
> > mess if one application say that FAT32 label is A and another that it is
> > B. And then Windows XP say, it is C.
> > 
> > I would like to open discussion if it would be possible to change
> > behavior how blkid (from util-linux project) and fatlabel (from
> > dosfstool project) handle FAT32 label. Ideally to report exactly same
> > output.
> > 
> > Basic information about FAT32 label:
> > 
> > 1) It is stored in two locations: boot sector and root directory as
> >    file name.
> > 
> > 2) In both location format is 11 bytes, padded with spaces (not nulls).
> > 
> > 3) Empty label in boot sector is stored as "NO NAME    " and not as
> >    empty string.
> > 
> > 4) Empty label in root directory is stored either as name which starts
> >    with byte 0xE5, or is not stored in root directory at all.
> > 
> > 5) If label contains leading byte 0xE5, then in root directory is stored
> >    as byte 0x05.
> > 
> > 6) Label string is stored according to current DOS code page. Therefore
> >    label string needs to be converted to bytes.
> > 
> > 7) Label string cannot contain control characters and characters from
> >    the set   ? / \ | . , ; : + = [ ] < > "   plus lower case characters
> >    are stored as their upper case variant (not only ASCII).
> > 
> > (Please correct me if I'm wrong in some of those points)
> > 
> > Plus Microsoft Windows systems fully ignores label stored in boot
> > sector. Seems they do not read it nor they do not update it on changes.
> > 
> > Looks like that mlabel (from mtools) applies all above rules and uses
> > DOS code page 850 by default (can be changed in config file).
> > 
> > blkid and fatlabel process special cases from 1) to 5) differently and
> > they operates on raw bytes, not strings (in DOS code page).
> > 
> > mlabel reads label from the root directory (missing entry is interpreted
> > as no label; there is no fallback to boot sector), but "set" operation
> > modify label in both location boot sector + root directory. Basically it
> > is near to Windows implementation. And reason why Gparted GUI
> > application uses mlabel and not fatlabel.
> > 
> > As Linux does not have "current DOS code page" and argv arguments are
> > not (Unicode) strings, but arbitrary bytes, I understand that for point
> > 6) it is easier to operates not on FAT strings (in current code page),
> > but rather on bytes. Which also would be same on all machines with any
> > configuration.
> > 
> > But would it be possible to decide and unify handling of point 2), 3),
> > 4), 5)? Ideally with combination how to handle situation when different
> > label is stored in boot sector and root directory.
> > 
> > As Windows does not use label in boot sector, it is very common
> > situation that label in boot sector differs from the root directory.
> > 
> > The best would be see in all cases same label from blkid, fatlabel and
> > mlabel. Ideally same as Windows machines -- but due to DOS code page,
> > this is possible only for ASCII subset of the 8bit encoding. IIRC most
> > (or all?) DOS code page has same characters in printable ASCII range.
> > 
> > It is really bad situation if I open disk in Gparted which show me label
> > via mlabel and then I open in KDE Partition Manager and I see different
> > label string (as it reads it from fatlabel).
> > 
> > Also note that older version of fatlabel (when it was named dosfslabel)
> > operated only the label stored in boot sector (and label stored in root
> > directory was not read or touched).
> > 
> 
> Hi! I did some testing of FAT32 label with different tools and here are
> results:
> 
>                                                  dosfslabel 3.0.12   fatlabel 4.1       blkid 2.20.1   mlabel 4.0.12   label.exe Windows XP
> fat32_mkdosfs_label1                             'label1     '       'label1     '      'label1'       'label1     '   'label1'
> fat32_mkdosfs_label1_dosfslabel_empty            '           '       '           '      none           '           '   none
> fat32_mkdosfs_label1_dosfslabel_label2           'label2     '       'label2     '      'label2'       'label2     '   'label2'
> fat32_mkdosfs_label1_dosfslabel_NO_NAME          'NO NAME    '       'NO NAME    '      none           'NO NAME    '   'NO NAME'
> fat32_mkdosfs_label1_mlabel_erase                'NO NAME    '       'NO NAME    '      none           none            none
> fat32_mkdosfs_label1_mlabel_NO_NAME              'NO NAME    '       'NO NAME    '      none           'NO NAME    '   'NO NAME'
> fat32_mkdosfs_label1_xp_erase                    'label1'    '       0xE5'abel1     '   'label1'       none            none
> fat32_mkdosfs_label1_xp_label2                   'label1'    '       'LABEL2     '      'LABEL2'       'LABEL2     '   'LABEL2'
> fat32_mkdosfs_none                               '           '       '           '      none           none            none
> fat32_mkdosfs_none_dosfslabel_label1             'label1     '       'label1     '      'label1'       none            none
> fat32_mkdosfs_none_dosfslabel_label1_xp_label2   'label1'    '       'LABEL2     '      'LABEL2'       'LABEL2     '   'LABEL2'
> fat32_mkdosfs_none_dosfslabel_NO_NAME            'NO NAME    '       'NO NAME    '      none           none            none
> fat32_mkdosfs_none_xp_label1                     '           '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'
> fat32_mkdosfs_none_xp_label1_dosfslabel_label2   'label2     '       'label2     '      'label2'       'label2     '   'label2'
> fat32_xp_label1                                  'NO NAME    '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'
> fat32_xp_none                                    'NO NAME    '       'NO NAME    '      none           none            none
> fat32_xp_none_dosfslabel_label1                  'label1     '       'label1     '      'label1'       none            none
> fat32_xp_none_mlabel_label1                      'LABEL1     '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'
> 
> In the first column is image name (all images are compressed and
> attached) which contains steps of operations, e.g. file name
> fat32_mkdosfs_none_dosfslabel_label1_xp_label2 means:
> 
> 1. create filesystem with mkdosfs without specifying label
> 2. change label with dosfslabel (3.0.12) to 'label1'
> 3. change label under Windows XP to 'label2'
> 
> From testing it looks like that different tools and different version of
> them have different behavior how they read or write FAT32 label, see
> following table:
> 
>                              read boot   write boot   read root   write root
> dosfslabel 3.0.0  - 3.0.6    YES         YES          NO          NO
> dosfslabel 3.0.7  - 3.0.15   YES         YES          NO          BUGGY (YES - if already exists; NO - otherwise)
> dosfslabel 3.0.16 - 4.1      YES         YES          YES         YES
> label.exe Windows XP         NO          NO           YES         YES
> blkid                        YES         NO           YES         NO
> mlabel                       NO          YES          YES         YES
> 
> 
> Attached images in compressed form has only 600 kB and I think they can
> be useful for testing either blkid or dosfstools project, so I'm sending
> them here.
> 

Based on results I would propose following unification:

1. If there is entry for label in root directory, including erased entry
   which starts with 0xE5, then do *not* process boot entry.

   --> Reason: Setting label to empty on Windows XP just marks label in
       root directory as erased (set first byte to 0xE5) and it does not
       touch boot sector when label can be always old. Test case is in
       file fat32_mkdosfs_label1_xp_erase.

       Same behavior can be seen in mlabel.

2. Process 'NO NAME    ' label in root directory as 'NO NAME' name. Not
   as empty label.

   --> Reason: 'NO NAME    ' is regular entry in root directory and both
       Windows XP and mlabel handle it in this way.

3. Process 'NO NAME    ' label in boot directory as empty label. Not as
   label with name 'NO NAME'.

   --> Reason: On Windows XP when formatting empty disk and label is not
       specified then 'NO NAME    ' is stored to boot directory.

4. Prefer label from the root directory. If there is none entry (means
   there is also no erased entry), then read label from root sector.

   --> Reason: Windows XP and mlabel ignores what is written in boot
       sector. Windows XP even do not update boot sector, so label
       stored in boot sector is incorrect after any change done by
       Windows XP.

       But due to compatibility with older dosfslabel, which stores
       label only to boot sector, there is need for some fallback. Due
       to point 1. the best seems to be to process also erased label in
       root directory (marked with leading 0xE5) and fallback to boot
       sector only in case label in root directory is missing.

What do you think about it?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Karel Zak]

On Wed, Oct 11, 2017 at 11:44:26PM +0200, Pali Rohár wrote:
> On Wednesday 11 October 2017 23:24:35 Pali Rohár wrote:
> > On Wednesday 04 October 2017 17:33:32 Pali Rohár wrote:
> > > Hi! There is a big inconsistency in Linux tools which read or write
> > > FAT32 label in filesystem images. The most common used are tools:
> > > blkid (from util-linux project), fatlabel (previously known as
> > > dosfslabel; from dosfstools project) and mlabel (from mtools project).
> > > 
> > > FAT32 is itself a big mess from Microsoft hell and even FAT32
> > > implementation in Microsoft Windows systems is not compliant to the
> > > released FAT32 documentation from Microsoft.
> > > 
> > > In past months I observed that Linux FAT32 tools has its own way how
> > > they interpret FAT32 label (known as volume id) and because every GUI
> > > application uses one of those low-level command line tool, it is a big
> > > mess if one application say that FAT32 label is A and another that it is
> > > B. And then Windows XP say, it is C.
> > > 
> > > I would like to open discussion if it would be possible to change
> > > behavior how blkid (from util-linux project) and fatlabel (from
> > > dosfstool project) handle FAT32 label. Ideally to report exactly same
> > > output.

The stuff in blkid is not "how we believe that FAT should be handled",
but "what users expect" :-) There is nothing like FAT standard and
unfortunately on may disks and USB devices is huge number FATS created
by many 3rd-party tools. For me the LABEL is not so important, the most
important is to keep libblkid ability to detect all the crazy FATs.

> Based on results I would propose following unification:
> 
> 1. If there is entry for label in root directory, including erased entry
>    which starts with 0xE5, then do *not* process boot entry.
> 
>    --> Reason: Setting label to empty on Windows XP just marks label in
>        root directory as erased (set first byte to 0xE5) and it does not
>        touch boot sector when label can be always old. Test case is in
>        file fat32_mkdosfs_label1_xp_erase.
> 
>        Same behavior can be seen in mlabel.
> 
> 2. Process 'NO NAME    ' label in root directory as 'NO NAME' name. Not
>    as empty label.
> 
>    --> Reason: 'NO NAME    ' is regular entry in root directory and both
>        Windows XP and mlabel handle it in this way.
> 
> 3. Process 'NO NAME    ' label in boot directory as empty label. Not as
>    label with name 'NO NAME'.

I prefer this solution. The label also means entry in udev DB, symlink
somewhere in /dev, field in lsblk output, etc. I'd like to avoid "NO
NAME" everywhere in the system (especially if you have more than one
device with this "label"). The "NO NAME" dummy label provides zero
value to end users.

>    --> Reason: On Windows XP when formatting empty disk and label is not
>        specified then 'NO NAME    ' is stored to boot directory.
> 
> 4. Prefer label from the root directory. If there is none entry (means
>    there is also no erased entry), then read label from root sector.
> 
>    --> Reason: Windows XP and mlabel ignores what is written in boot
>        sector. Windows XP even do not update boot sector, so label
>        stored in boot sector is incorrect after any change done by
>        Windows XP.
> 
>        But due to compatibility with older dosfslabel, which stores
>        label only to boot sector, there is need for some fallback. Due
>        to point 1. the best seems to be to process also erased label in
>        root directory (marked with leading 0xE5) and fallback to boot
>        sector only in case label in root directory is missing.
> 
> What do you think about it?

The best for me is to keep blkid output backwardly compatible as much
as possible :-)

Note that the current version is v2.31-rc, you use pretty old v2.20 in
your tests.

    Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Linux & FAT32 label

[Pali Rohár]

On Thursday 12 October 2017 10:56:58 Karel Zak wrote:
> On Wed, Oct 11, 2017 at 11:44:26PM +0200, Pali Rohár wrote:
> > On Wednesday 11 October 2017 23:24:35 Pali Rohár wrote:
> > > On Wednesday 04 October 2017 17:33:32 Pali Rohár wrote:
> > > > Hi! There is a big inconsistency in Linux tools which read or write
> > > > FAT32 label in filesystem images. The most common used are tools:
> > > > blkid (from util-linux project), fatlabel (previously known as
> > > > dosfslabel; from dosfstools project) and mlabel (from mtools project).
> > > > 
> > > > FAT32 is itself a big mess from Microsoft hell and even FAT32
> > > > implementation in Microsoft Windows systems is not compliant to the
> > > > released FAT32 documentation from Microsoft.
> > > > 
> > > > In past months I observed that Linux FAT32 tools has its own way how
> > > > they interpret FAT32 label (known as volume id) and because every GUI
> > > > application uses one of those low-level command line tool, it is a big
> > > > mess if one application say that FAT32 label is A and another that it is
> > > > B. And then Windows XP say, it is C.
> > > > 
> > > > I would like to open discussion if it would be possible to change
> > > > behavior how blkid (from util-linux project) and fatlabel (from
> > > > dosfstool project) handle FAT32 label. Ideally to report exactly same
> > > > output.
> 
> The stuff in blkid is not "how we believe that FAT should be handled",
> but "what users expect" :-)

I, as a user, would expect that e.g. label set on Windows machine would
be visible also on Linux. Or if I remove label on Windows machine, then
Linux see also information that it is removed.

> There is nothing like FAT standard and

There are two "official" FAT32 documents as a "standard" from Microsoft:

fatgen103.doc
FAT32 Spec (SDA Contribution).doc

But even Microsoft Windows implementations of FAT32 are not compliant to
those documents... So it can be used just as reference.

> unfortunately on may disks and USB devices is huge number FATS created
> by many 3rd-party tools. For me the LABEL is not so important, the most
> important is to keep libblkid ability to detect all the crazy FATs.

Yes, detecting as many possible FATs as possible...

> > Based on results I would propose following unification:
> > 
> > 1. If there is entry for label in root directory, including erased entry
> >    which starts with 0xE5, then do *not* process boot entry.
> > 
> >    --> Reason: Setting label to empty on Windows XP just marks label in
> >        root directory as erased (set first byte to 0xE5) and it does not
> >        touch boot sector when label can be always old. Test case is in
> >        file fat32_mkdosfs_label1_xp_erase.
> > 
> >        Same behavior can be seen in mlabel.
> > 
> > 2. Process 'NO NAME    ' label in root directory as 'NO NAME' name. Not
> >    as empty label.
> > 
> >    --> Reason: 'NO NAME    ' is regular entry in root directory and both
> >        Windows XP and mlabel handle it in this way.
> > 
> > 3. Process 'NO NAME    ' label in boot directory as empty label. Not as
> >    label with name 'NO NAME'.
> 
> I prefer this solution. The label also means entry in udev DB, symlink
> somewhere in /dev, field in lsblk output, etc. I'd like to avoid "NO
> NAME" everywhere in the system (especially if you have more than one
> device with this "label"). The "NO NAME" dummy label provides zero
> value to end users.

Ok.

> >    --> Reason: On Windows XP when formatting empty disk and label is not
> >        specified then 'NO NAME    ' is stored to boot directory.
> > 
> > 4. Prefer label from the root directory. If there is none entry (means
> >    there is also no erased entry), then read label from root sector.
> > 
> >    --> Reason: Windows XP and mlabel ignores what is written in boot
> >        sector. Windows XP even do not update boot sector, so label
> >        stored in boot sector is incorrect after any change done by
> >        Windows XP.
> > 
> >        But due to compatibility with older dosfslabel, which stores
> >        label only to boot sector, there is need for some fallback. Due
> >        to point 1. the best seems to be to process also erased label in
> >        root directory (marked with leading 0xE5) and fallback to boot
> >        sector only in case label in root directory is missing.
> > 
> > What do you think about it?
> 
> The best for me is to keep blkid output backwardly compatible as much
> as possible :-)

Backward compatibility is a good reason. But what with situation when
interoperability with other systems (e.g. Windows) does not work as
expected? From test results we can see that blkid does not see change
when Windows removes label.

> Note that the current version is v2.31-rc, you use pretty old v2.20 in
> your tests.

I used older system for testing, but it seems that handling FAT32 label
was not changed since 2.20. Git version still shows me same results.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Karel Zak]

On Thu, Oct 12, 2017 at 11:21:13AM +0200, Pali Rohár wrote:
> > The best for me is to keep blkid output backwardly compatible as much
> > as possible :-)
> 
> Backward compatibility is a good reason. But what with situation when
> interoperability with other systems (e.g. Windows) does not work as
> expected?

Then... I'm ready to do the changes to keep interoperability with the
rest of the universe. It's the same situation as with UDF, you know...

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Linux & FAT32 label

[Pali Rohár]

On Thursday 12 October 2017 12:13:11 Karel Zak wrote:
> On Thu, Oct 12, 2017 at 11:21:13AM +0200, Pali Rohár wrote:
> > > The best for me is to keep blkid output backwardly compatible as much
> > > as possible :-)
> > 
> > Backward compatibility is a good reason. But what with situation when
> > interoperability with other systems (e.g. Windows) does not work as
> > expected?
> 
> Then... I'm ready to do the changes to keep interoperability with the
> rest of the universe. It's the same situation as with UDF, you know...

Apparently situation is not same as with UDF. For UDF we have
specification and basically all known UDF implementation by me were
compatible how to treat label except blkid (which read different think).

For FAT32 we have 3 different linux implementations (blkid, fatlabel,
mlabel) and every one is slightly different in reading label (see
results sent in previous emails).

What is first needed to know if implementations are willing to change to
be more or less same. And then decide what we want to change.

Andreas, as fatlabel maintainer, what do you think about it?

If you want, I can prepare patches for blkid and fatlabel to mimic
behavior written in proposed solution. But I think it does not make
sense to change just one Linux tool...

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Pavel Machek]

Hi!

> Based on results I would propose following unification:
> 
...
> 4. Prefer label from the root directory. If there is none entry (means
>    there is also no erased entry), then read label from root sector.
> 
>    --> Reason: Windows XP and mlabel ignores what is written in boot
>        sector. Windows XP even do not update boot sector, so label
>        stored in boot sector is incorrect after any change done by
>        Windows XP.
> 
>        But due to compatibility with older dosfslabel, which stores
>        label only to boot sector, there is need for some fallback. Due
>        to point 1. the best seems to be to process also erased label in
>        root directory (marked with leading 0xE5) and fallback to boot
>        sector only in case label in root directory is missing.
> 
> What do you think about it?

4. seems dangerous. Assume we have "OLD" in boot sector and "0xe5-EW" in the directory
entry. The label will change from <none> to "OLD" when the directory entry is reused by
"FOO.TXT", right? That seems surprising / dangerous.
										Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Linux & FAT32 label

[Pali Rohár]

On Sunday 15 October 2017 08:59:01 Pavel Machek wrote:
> Hi!
> 
> > Based on results I would propose following unification:
> > 
> ...
> > 4. Prefer label from the root directory. If there is none entry (means
> >    there is also no erased entry), then read label from root sector.
> > 
> >    --> Reason: Windows XP and mlabel ignores what is written in boot
> >        sector. Windows XP even do not update boot sector, so label
> >        stored in boot sector is incorrect after any change done by
> >        Windows XP.
> > 
> >        But due to compatibility with older dosfslabel, which stores
> >        label only to boot sector, there is need for some fallback. Due
> >        to point 1. the best seems to be to process also erased label in
> >        root directory (marked with leading 0xE5) and fallback to boot
> >        sector only in case label in root directory is missing.
> > 
> > What do you think about it?
> 
> 4. seems dangerous. Assume we have "OLD" in boot sector and "0xe5-EW" in the directory
> entry. The label will change from <none> to "OLD" when the directory entry is reused by
> "FOO.TXT", right? That seems surprising / dangerous.

Hm... that is a good question what happen (I do not know). I think that
current situation when Windows XP show different label as Linux is also
_surprising_.

Do you have a better idea what to do and how to handle this situation?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Andreas Bombe]

On Mon, Oct 16, 2017 at 12:04:50AM +0200, Pali Rohár wrote:
> On Sunday 15 October 2017 08:59:01 Pavel Machek wrote:
> > Hi!
> > 
> > > Based on results I would propose following unification:
> > > 
> > ...
> > > 4. Prefer label from the root directory. If there is none entry (means
> > >    there is also no erased entry), then read label from root sector.
> > > 
> > >    --> Reason: Windows XP and mlabel ignores what is written in boot
> > >        sector. Windows XP even do not update boot sector, so label
> > >        stored in boot sector is incorrect after any change done by
> > >        Windows XP.
> > > 
> > >        But due to compatibility with older dosfslabel, which stores
> > >        label only to boot sector, there is need for some fallback. Due
> > >        to point 1. the best seems to be to process also erased label in
> > >        root directory (marked with leading 0xE5) and fallback to boot
> > >        sector only in case label in root directory is missing.
> > > 
> > > What do you think about it?
> > 
> > 4. seems dangerous. Assume we have "OLD" in boot sector and "0xe5-EW" in the directory
> > entry. The label will change from <none> to "OLD" when the directory entry is reused by
> > "FOO.TXT", right? That seems surprising / dangerous.
> 
> Hm... that is a good question what happen (I do not know). I think that
> current situation when Windows XP show different label as Linux is also
> _surprising_.
> 
> Do you have a better idea what to do and how to handle this situation?

I have been saying this, a deleted directory entry has no valid contents
and its existence should not be considered meaningful. A Windows
formatted FAT filesystem without label will have no root directory label
entry and if an existing label is deleted, that deleted entry can be
overwritten at any time.

"Ignoring the presence of boot sector labels" is the only thing I see
for practical Windows compatibility.

Re: Linux & FAT32 label

[Andreas Bombe]

On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote:
> On Thursday 12 October 2017 12:13:11 Karel Zak wrote:
> > On Thu, Oct 12, 2017 at 11:21:13AM +0200, Pali Rohár wrote:
> > > > The best for me is to keep blkid output backwardly compatible as much
> > > > as possible :-)
> > > 
> > > Backward compatibility is a good reason. But what with situation when
> > > interoperability with other systems (e.g. Windows) does not work as
> > > expected?
> > 
> > Then... I'm ready to do the changes to keep interoperability with the
> > rest of the universe. It's the same situation as with UDF, you know...
> 
> Apparently situation is not same as with UDF. For UDF we have
> specification and basically all known UDF implementation by me were
> compatible how to treat label except blkid (which read different think).
> 
> For FAT32 we have 3 different linux implementations (blkid, fatlabel,
> mlabel) and every one is slightly different in reading label (see
> results sent in previous emails).
> 
> What is first needed to know if implementations are willing to change to
> be more or less same. And then decide what we want to change.
> 
> Andreas, as fatlabel maintainer, what do you think about it?
> 
> If you want, I can prepare patches for blkid and fatlabel to mimic
> behavior written in proposed solution. But I think it does not make
> sense to change just one Linux tool...

I was worried that there might be some scripts or programs that expect
the "NO NAME" output for unlabeled volumes from fatlabel. At least there
does not appear anything like that judging from a few searches on
codesearch.debian.net. Not that there's a guaranteed "NO NAME" on
unlabeled filesystems, in an unlikely case the boot sector label field
might be missing altogether.

So far I think I will change fatlabel to chop off trailing white space
when printing and have it interpret no rootdir label + boot sector label
== NO NAME as no label.

The other thing is completely ignoring the boot sector label, which I
could have as a mode enabled by command line switch or environmental
variable, or just outright make it the default. I'm not decided yet.

Another problem is whether to also ignore boot sector on setting label.
Otherwise the sequence:
  "set label on Linux" (both root and boot)
  "change label on Windows" (root label is changed)
  "remove label on Windows" (root label is deleted)
  "view label on Linux" (no root label, use boot label)
resurrects an old label.

Re: Linux & FAT32 label

[Pali Rohár]

On Monday 16 October 2017 03:12:43 Andreas Bombe wrote:
> The other thing is completely ignoring the boot sector label, which I
> could have as a mode enabled by command line switch or environmental
> variable, or just outright make it the default. I'm not decided yet.
> 
> Another problem is whether to also ignore boot sector on setting label.
> Otherwise the sequence:
>   "set label on Linux" (both root and boot)
>   "change label on Windows" (root label is changed)
>   "remove label on Windows" (root label is deleted)
>   "view label on Linux" (no root label, use boot label)
> resurrects an old label.

There is also mlabel tool which is heavily used (e.g. by gparted GUI
application) and when setting new label it stores it to both location.

And because gparted is used on Linux, such situation as described above
can still happen.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Pali Rohár]

On Monday 16 October 2017 09:28:45 Pali Rohár wrote:
> On Monday 16 October 2017 03:12:43 Andreas Bombe wrote:
> > The other thing is completely ignoring the boot sector label, which I
> > could have as a mode enabled by command line switch or environmental
> > variable, or just outright make it the default. I'm not decided yet.
> > 
> > Another problem is whether to also ignore boot sector on setting label.
> > Otherwise the sequence:
> >   "set label on Linux" (both root and boot)
> >   "change label on Windows" (root label is changed)
> >   "remove label on Windows" (root label is deleted)
> >   "view label on Linux" (no root label, use boot label)
> > resurrects an old label.
> 
> There is also mlabel tool which is heavily used (e.g. by gparted GUI
> application) and when setting new label it stores it to both location.
> 
> And because gparted is used on Linux, such situation as described above
> can still happen.

Another option is to completely ignore label from the boot sector when
reading label.

And maybe it can be a good idea to synchronize labels in boot sector and
root directory in fsck.fat. When differs in interactive mode it can ask
user if label from root directory should be copied to boot sector or
from boot sector to root directory.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Andy Shevchenko]

On Mon, Oct 16, 2017 at 4:12 AM, Andreas Bombe <aeb@debian.org> wrote:
> On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote:
>> On Thursday 12 October 2017 12:13:11 Karel Zak wrote:
>> > On Thu, Oct 12, 2017 at 11:21:13AM +0200, Pali Rohár wrote:
>> > > > The best for me is to keep blkid output backwardly compatible as much
>> > > > as possible :-)
>> > >
>> > > Backward compatibility is a good reason. But what with situation when
>> > > interoperability with other systems (e.g. Windows) does not work as
>> > > expected?
>> >
>> > Then... I'm ready to do the changes to keep interoperability with the
>> > rest of the universe. It's the same situation as with UDF, you know...
>>
>> Apparently situation is not same as with UDF. For UDF we have
>> specification and basically all known UDF implementation by me were
>> compatible how to treat label except blkid (which read different think).
>>
>> For FAT32 we have 3 different linux implementations (blkid, fatlabel,
>> mlabel) and every one is slightly different in reading label (see
>> results sent in previous emails).
>>
>> What is first needed to know if implementations are willing to change to
>> be more or less same. And then decide what we want to change.
>>
>> Andreas, as fatlabel maintainer, what do you think about it?
>>
>> If you want, I can prepare patches for blkid and fatlabel to mimic
>> behavior written in proposed solution. But I think it does not make
>> sense to change just one Linux tool...
>
> I was worried that there might be some scripts or programs that expect

If we really care about such scripts another approach might be to
introduce a CLI switch to "spec compatible mode" to each tool and
suggest in documentation to use it.

There are also variants:
- spec compatible
- WinXX compatible
- DOS compatible
- etc

-- 
With Best Regards,
Andy Shevchenko

Re: Linux & FAT32 label

[Pali Rohár]

On Wednesday 11 October 2017 23:24:35 Pali Rohár wrote:
> On Wednesday 04 October 2017 17:33:32 Pali Rohár wrote:
> > Hi! There is a big inconsistency in Linux tools which read or write
> > FAT32 label in filesystem images. The most common used are tools:
> > blkid (from util-linux project), fatlabel (previously known as
> > dosfslabel; from dosfstools project) and mlabel (from mtools project).
> > 
> > FAT32 is itself a big mess from Microsoft hell and even FAT32
> > implementation in Microsoft Windows systems is not compliant to the
> > released FAT32 documentation from Microsoft.
> > 
> > In past months I observed that Linux FAT32 tools has its own way how
> > they interpret FAT32 label (known as volume id) and because every GUI
> > application uses one of those low-level command line tool, it is a big
> > mess if one application say that FAT32 label is A and another that it is
> > B. And then Windows XP say, it is C.
> > 
> > I would like to open discussion if it would be possible to change
> > behavior how blkid (from util-linux project) and fatlabel (from
> > dosfstool project) handle FAT32 label. Ideally to report exactly same
> > output.
> > 
> > Basic information about FAT32 label:
> > 
> > 1) It is stored in two locations: boot sector and root directory as
> >    file name.
> > 
> > 2) In both location format is 11 bytes, padded with spaces (not nulls).
> > 
> > 3) Empty label in boot sector is stored as "NO NAME    " and not as
> >    empty string.
> > 
> > 4) Empty label in root directory is stored either as name which starts
> >    with byte 0xE5, or is not stored in root directory at all.
> > 
> > 5) If label contains leading byte 0xE5, then in root directory is stored
> >    as byte 0x05.
> > 
> > 6) Label string is stored according to current DOS code page. Therefore
> >    label string needs to be converted to bytes.
> > 
> > 7) Label string cannot contain control characters and characters from
> >    the set   ? / \ | . , ; : + = [ ] < > "   plus lower case characters
> >    are stored as their upper case variant (not only ASCII).
> > 
> > (Please correct me if I'm wrong in some of those points)
> > 
> > Plus Microsoft Windows systems fully ignores label stored in boot
> > sector. Seems they do not read it nor they do not update it on changes.
> > 
> > Looks like that mlabel (from mtools) applies all above rules and uses
> > DOS code page 850 by default (can be changed in config file).
> > 
> > blkid and fatlabel process special cases from 1) to 5) differently and
> > they operates on raw bytes, not strings (in DOS code page).
> > 
> > mlabel reads label from the root directory (missing entry is interpreted
> > as no label; there is no fallback to boot sector), but "set" operation
> > modify label in both location boot sector + root directory. Basically it
> > is near to Windows implementation. And reason why Gparted GUI
> > application uses mlabel and not fatlabel.
> > 
> > As Linux does not have "current DOS code page" and argv arguments are
> > not (Unicode) strings, but arbitrary bytes, I understand that for point
> > 6) it is easier to operates not on FAT strings (in current code page),
> > but rather on bytes. Which also would be same on all machines with any
> > configuration.
> > 
> > But would it be possible to decide and unify handling of point 2), 3),
> > 4), 5)? Ideally with combination how to handle situation when different
> > label is stored in boot sector and root directory.
> > 
> > As Windows does not use label in boot sector, it is very common
> > situation that label in boot sector differs from the root directory.
> > 
> > The best would be see in all cases same label from blkid, fatlabel and
> > mlabel. Ideally same as Windows machines -- but due to DOS code page,
> > this is possible only for ASCII subset of the 8bit encoding. IIRC most
> > (or all?) DOS code page has same characters in printable ASCII range.
> > 
> > It is really bad situation if I open disk in Gparted which show me label
> > via mlabel and then I open in KDE Partition Manager and I see different
> > label string (as it reads it from fatlabel).
> > 
> > Also note that older version of fatlabel (when it was named dosfslabel)
> > operated only the label stored in boot sector (and label stored in root
> > directory was not read or touched).
> > 
> 
> Hi! I did some testing of FAT32 label with different tools and here are
> results:

Hi! I did more tests with MS-DOS and Windows systems and I'm extending
result tables below:

>                                                  dosfslabel 3.0.12   fatlabel 4.1       blkid 2.20.1   mlabel 4.0.12   label.exe Windows XP
> fat32_mkdosfs_label1                             'label1     '       'label1     '      'label1'       'label1     '   'label1'
> fat32_mkdosfs_label1_dosfslabel_empty            '           '       '           '      none           '           '   none
> fat32_mkdosfs_label1_dosfslabel_label2           'label2     '       'label2     '      'label2'       'label2     '   'label2'
> fat32_mkdosfs_label1_dosfslabel_NO_NAME          'NO NAME    '       'NO NAME    '      none           'NO NAME    '   'NO NAME'
> fat32_mkdosfs_label1_mlabel_erase                'NO NAME    '       'NO NAME    '      none           none            none
> fat32_mkdosfs_label1_mlabel_NO_NAME              'NO NAME    '       'NO NAME    '      none           'NO NAME    '   'NO NAME'
> fat32_mkdosfs_label1_xp_erase                    'label1'    '       0xE5'abel1     '   'label1'       none            none
> fat32_mkdosfs_label1_xp_label2                   'label1'    '       'LABEL2     '      'LABEL2'       'LABEL2     '   'LABEL2'
> fat32_mkdosfs_none                               '           '       '           '      none           none            none
> fat32_mkdosfs_none_dosfslabel_label1             'label1     '       'label1     '      'label1'       none            none
> fat32_mkdosfs_none_dosfslabel_label1_xp_label2   'label1'    '       'LABEL2     '      'LABEL2'       'LABEL2     '   'LABEL2'
> fat32_mkdosfs_none_dosfslabel_NO_NAME            'NO NAME    '       'NO NAME    '      none           none            none
> fat32_mkdosfs_none_xp_label1                     '           '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'
> fat32_mkdosfs_none_xp_label1_dosfslabel_label2   'label2     '       'label2     '      'label2'       'label2     '   'label2'
> fat32_xp_label1                                  'NO NAME    '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'
> fat32_xp_none                                    'NO NAME    '       'NO NAME    '      none           none            none
> fat32_xp_none_dosfslabel_label1                  'label1     '       'label1     '      'label1'       none            none
> fat32_xp_none_mlabel_label1                      'LABEL1     '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'

                                                   label.exe MS-DOS 7.10   label.exe Windows 98   label.exe Windows 10
fat32_mkdosfs_label1                               'label1'                'label1'               'label1'
fat32_mkdosfs_label1_dosfslabel_empty              ''                      ''                     none
fat32_mkdosfs_label1_dosfslabel_label2             'label2'                'label2'               'label2'
fat32_mkdosfs_label1_dosfslabel_NO_NAME            'NO NAME'               'NO NAME'              'NO NAME'
fat32_mkdosfs_label1_mlabel_erase                  none                    none                   none
fat32_mkdosfs_label1_mlabel_NO_NAME                'NO NAME'               'NO NAME'              'NO NAME'
fat32_mkdosfs_label1_xp_erase                      none                    none                   none
fat32_mkdosfs_label1_xp_label2                     'LABEL2'                'LABEL2'               'LABEL2'
fat32_mkdosfs_none                                 none                    none                   none
fat32_mkdosfs_none_dosfslabel_label1               none                    none                   none
fat32_mkdosfs_none_dosfslabel_label1_xp_label2     'LABEL2'                'LABEL2'               'LABEL2'
fat32_mkdosfs_none_dosfslabel_NO_NAME              none                    none                   none
fat32_mkdosfs_none_xp_label1                       'LABEL1'                'LABEL1'               'LABEL1'
fat32_mkdosfs_none_xp_label1_dosfslabel_label2     'label2'                'label2'               'label2'
fat32_xp_label1                                    'LABEL1'                'LABEL1'               'LABEL1'
fat32_xp_none                                      none                    none                   none
fat32_xp_none_dosfslabel_label1                    none                    none                   none
fat32_xp_none_mlabel_label1                        'LABEL1'                'LABEL1'               'LABEL1'

Seems that behavior of reading label from FAT32 volume is consistent
between MS-DOS and different Windows versions. The only exception is
when in label in the root directory is stored as empty string (11
spaces). MS-DOS and Windows 98 treat it as label with empty string, but
Windows XP and Windows 10 as disk without label.

> In the first column is image name (all images are compressed and
> attached) which contains steps of operations, e.g. file name
> fat32_mkdosfs_none_dosfslabel_label1_xp_label2 means:
> 
> 1. create filesystem with mkdosfs without specifying label
> 2. change label with dosfslabel (3.0.12) to 'label1'
> 3. change label under Windows XP to 'label2'
> 
> From testing it looks like that different tools and different version of
> them have different behavior how they read or write FAT32 label, see
> following table:
> 
>                              read boot   write boot   read root   write root
> dosfslabel 3.0.0  - 3.0.6    YES         YES          NO          NO
> dosfslabel 3.0.7  - 3.0.15   YES         YES          NO          BUGGY (YES - if already exists; NO - otherwise)
> dosfslabel 3.0.16 - 4.1      YES         YES          YES         YES
> label.exe Windows XP         NO          NO           YES         YES
> blkid                        YES         NO           YES         NO
> mlabel                       NO          YES          YES         YES

label.exe MS-DOS 6.22          NO          YES          YES         YES
label.exe MS-DOS 7.10          NO          YES          YES         YES
label.exe Windows 98 SE        NO          YES          YES         YES
label.exe Windows 10           NO          NO           YES         YES

Older MS-DOS 6.22 does not support FAT32 disks, only FAT16. MS-DOS 7.10
has support for FAT32 and also for LFN. But both tested MS-DOS versions
and Windows 98 updates label in both locations: boot sector and root
directory. Also in case when label is changed in Windows 98 via
"My Computer" GUI.

>From above tests it can be seen that both MS-DOS and all Windows
versions ignores label which is stored in boot sector and show to user
only label from root directory.

Also it can be seen that both MS-DOS versions do not have problems when
label contains lower case letters.

> Attached images in compressed form has only 600 kB and I think they can
> be useful for testing either blkid or dosfstools project, so I'm sending
> them here.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Pali Rohár]

On Tuesday 31 October 2017 10:35:48 Andy Shevchenko wrote:
> On Mon, Oct 16, 2017 at 4:12 AM, Andreas Bombe <aeb@debian.org> wrote:
> > On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote:
> >> On Thursday 12 October 2017 12:13:11 Karel Zak wrote:
> >> > On Thu, Oct 12, 2017 at 11:21:13AM +0200, Pali Rohár wrote:
> >> > > > The best for me is to keep blkid output backwardly compatible as much
> >> > > > as possible :-)
> >> > >
> >> > > Backward compatibility is a good reason. But what with situation when
> >> > > interoperability with other systems (e.g. Windows) does not work as
> >> > > expected?
> >> >
> >> > Then... I'm ready to do the changes to keep interoperability with the
> >> > rest of the universe. It's the same situation as with UDF, you know...
> >>
> >> Apparently situation is not same as with UDF. For UDF we have
> >> specification and basically all known UDF implementation by me were
> >> compatible how to treat label except blkid (which read different think).
> >>
> >> For FAT32 we have 3 different linux implementations (blkid, fatlabel,
> >> mlabel) and every one is slightly different in reading label (see
> >> results sent in previous emails).
> >>
> >> What is first needed to know if implementations are willing to change to
> >> be more or less same. And then decide what we want to change.
> >>
> >> Andreas, as fatlabel maintainer, what do you think about it?
> >>
> >> If you want, I can prepare patches for blkid and fatlabel to mimic
> >> behavior written in proposed solution. But I think it does not make
> >> sense to change just one Linux tool...
> >
> > I was worried that there might be some scripts or programs that expect
> 
> If we really care about such scripts another approach might be to
> introduce a CLI switch to "spec compatible mode" to each tool and
> suggest in documentation to use it.
> 
> There are also variants:
> - spec compatible
> - WinXX compatible
> - DOS compatible
> - etc

I did tests with MS-DOS and Windows versions (results in previous
email), and they seems to be compatible how they read label.

Based on results I would suggest to ignore label from the boot sector
when reading label. This makes behavior consistent with older MS-DOS
systems and also all Windows systems. This change would be a problem
only for users who have label stored only in boot sector. After change
they would not see label anymore -- exactly same what MS-DOS or Windows
show them. Seems that mkdosfs stores label to both location, since
support for label was introduced. So different label would be visible
only for users who used dosfslabel prior to version 3.0.16.

What do you think?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Andy Shevchenko]

On Sun, Nov 5, 2017 at 3:39 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Tuesday 31 October 2017 10:35:48 Andy Shevchenko wrote:
>> On Mon, Oct 16, 2017 at 4:12 AM, Andreas Bombe <aeb@debian.org> wrote:
>> > On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote:
>> >> On Thursday 12 October 2017 12:13:11 Karel Zak wrote:

>> > I was worried that there might be some scripts or programs that expect
>>
>> If we really care about such scripts another approach might be to
>> introduce a CLI switch to "spec compatible mode" to each tool and
>> suggest in documentation to use it.
>>
>> There are also variants:
>> - spec compatible
>> - WinXX compatible
>> - DOS compatible
>> - etc
>
> I did tests with MS-DOS and Windows versions (results in previous
> email), and they seems to be compatible how they read label.
>
> Based on results I would suggest to ignore label from the boot sector
> when reading label.

So, for tools which are not doing that to add

 --ignore-boot-sector-label (or alike) [recommended]

right?

We don't actually know how many users (scripts) are relying on current
behaviour.
If there are only few, we may introduce backward compatibility switch

--read-boot-sector-label

> This makes behavior consistent with older MS-DOS
> systems and also all Windows systems. This change would be a problem
> only for users who have label stored only in boot sector. After change
> they would not see label anymore -- exactly same what MS-DOS or Windows
> show them. Seems that mkdosfs stores label to both location, since
> support for label was introduced. So different label would be visible
> only for users who used dosfslabel prior to version 3.0.16.
>
> What do you think?

So, in summary it looks like a documentation needs update (to mark
your research).

-- 
With Best Regards,
Andy Shevchenko

Re: Linux & FAT32 label

[Pali Rohár]

On Sunday 05 November 2017 15:56:53 Andy Shevchenko wrote:
> On Sun, Nov 5, 2017 at 3:39 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Tuesday 31 October 2017 10:35:48 Andy Shevchenko wrote:
> >> On Mon, Oct 16, 2017 at 4:12 AM, Andreas Bombe <aeb@debian.org> wrote:
> >> > On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote:
> >> >> On Thursday 12 October 2017 12:13:11 Karel Zak wrote:
> 
> >> > I was worried that there might be some scripts or programs that expect
> >>
> >> If we really care about such scripts another approach might be to
> >> introduce a CLI switch to "spec compatible mode" to each tool and
> >> suggest in documentation to use it.
> >>
> >> There are also variants:
> >> - spec compatible
> >> - WinXX compatible
> >> - DOS compatible
> >> - etc
> >
> > I did tests with MS-DOS and Windows versions (results in previous
> > email), and they seems to be compatible how they read label.
> >
> > Based on results I would suggest to ignore label from the boot sector
> > when reading label.
> 
> So, for tools which are not doing that to add
> 
>  --ignore-boot-sector-label (or alike) [recommended]
> 
> right?
> 
> We don't actually know how many users (scripts) are relying on current
> behaviour.
> If there are only few, we may introduce backward compatibility switch
> 
> --read-boot-sector-label

Current behavior of the last blkid and fatlabel tools is: Try to read
label from the root directory. If it does not exist, then fallback to
label stored in boot sector. And when fatlabel is changing label it
updates both locations.

So tools which already uses fatlabel for get & set operations should not
be affected as setting new label makes boot and root in sync.

New proposed behavior is: Try to read label from the root directory. If
not exist, then treat disk as without label.

As in current behavior there is no way via fatlabel to read "just only
label from boot sector", I think that problems for current scripts is
minimal.

What about making this new behavior in fatlabel as default with new
switch --fallback-to-boot-sector (switch to current behavior) or
--read-only-boot-sector (ignores label in root directory) for people who
are interested in label stored in boot sector?

And what to do with blkid? That cannot have any switch :-( and can have
only one behavior.

> > This makes behavior consistent with older MS-DOS
> > systems and also all Windows systems. This change would be a problem
> > only for users who have label stored only in boot sector. After change
> > they would not see label anymore -- exactly same what MS-DOS or Windows
> > show them. Seems that mkdosfs stores label to both location, since
> > support for label was introduced. So different label would be visible
> > only for users who used dosfslabel prior to version 3.0.16.
> >
> > What do you think?
> 
> So, in summary it looks like a documentation needs update (to mark
> your research).

Which documentation do you mean?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Andrius Štikonas]

[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]

Hi,

Well, KDE Partition Manager uses dosfstools but I can always
release a new version once updated dosfstools is released.

Best,
Andrius

2017 m. lapkričio 5 d., sekmadienis 13:56:53 GMT Andy Shevchenko rašė:
> On Sun, Nov 5, 2017 at 3:39 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Tuesday 31 October 2017 10:35:48 Andy Shevchenko wrote:
> >> On Mon, Oct 16, 2017 at 4:12 AM, Andreas Bombe <aeb@debian.org> wrote:
> >> > On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote:
> >> >> On Thursday 12 October 2017 12:13:11 Karel Zak wrote:
> 
> >> > I was worried that there might be some scripts or programs that expect
> >>
> >> If we really care about such scripts another approach might be to
> >> introduce a CLI switch to "spec compatible mode" to each tool and
> >> suggest in documentation to use it.
> >>
> >> There are also variants:
> >> - spec compatible
> >> - WinXX compatible
> >> - DOS compatible
> >> - etc
> >
> > I did tests with MS-DOS and Windows versions (results in previous
> > email), and they seems to be compatible how they read label.
> >
> > Based on results I would suggest to ignore label from the boot sector
> > when reading label.
> 
> So, for tools which are not doing that to add
> 
>  --ignore-boot-sector-label (or alike) [recommended]
> 
> right?
> 
> We don't actually know how many users (scripts) are relying on current
> behaviour.
> If there are only few, we may introduce backward compatibility switch
> 
> --read-boot-sector-label
> 
> > This makes behavior consistent with older MS-DOS
> > systems and also all Windows systems. This change would be a problem
> > only for users who have label stored only in boot sector. After change
> > they would not see label anymore -- exactly same what MS-DOS or Windows
> > show them. Seems that mkdosfs stores label to both location, since
> > support for label was introduced. So different label would be visible
> > only for users who used dosfslabel prior to version 3.0.16.
> >
> > What do you think?
> 
> So, in summary it looks like a documentation needs update (to mark
> your research).
> 
> 


-- 
I encourage the use of end to end email encryption

GPG key:   https://stikonas.eu/andrius.asc
Fingerprint:  1EE5 A320 5904 BAA2 B88C 0A9D 24FD 3194 0095 C0E1

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Linux & FAT32 label

[Andy Shevchenko]

On Sun, Nov 5, 2017 at 4:07 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Sunday 05 November 2017 15:56:53 Andy Shevchenko wrote:
>> On Sun, Nov 5, 2017 at 3:39 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
>> > On Tuesday 31 October 2017 10:35:48 Andy Shevchenko wrote:
>> >> On Mon, Oct 16, 2017 at 4:12 AM, Andreas Bombe <aeb@debian.org> wrote:
>> >> > On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote:
>> >> >> On Thursday 12 October 2017 12:13:11 Karel Zak wrote:
>>
>> >> > I was worried that there might be some scripts or programs that expect
>> >>
>> >> If we really care about such scripts another approach might be to
>> >> introduce a CLI switch to "spec compatible mode" to each tool and
>> >> suggest in documentation to use it.
>> >>
>> >> There are also variants:
>> >> - spec compatible
>> >> - WinXX compatible
>> >> - DOS compatible
>> >> - etc
>> >
>> > I did tests with MS-DOS and Windows versions (results in previous
>> > email), and they seems to be compatible how they read label.
>> >
>> > Based on results I would suggest to ignore label from the boot sector
>> > when reading label.
>>
>> So, for tools which are not doing that to add
>>
>>  --ignore-boot-sector-label (or alike) [recommended]
>>
>> right?
>>
>> We don't actually know how many users (scripts) are relying on current
>> behaviour.
>> If there are only few, we may introduce backward compatibility switch
>>
>> --read-boot-sector-label
>
> Current behavior of the last blkid and fatlabel tools is: Try to read
> label from the root directory. If it does not exist, then fallback to
> label stored in boot sector. And when fatlabel is changing label it
> updates both locations.
>
> So tools which already uses fatlabel for get & set operations should not
> be affected as setting new label makes boot and root in sync.
>
> New proposed behavior is: Try to read label from the root directory. If
> not exist, then treat disk as without label.
>
> As in current behavior there is no way via fatlabel to read "just only
> label from boot sector", I think that problems for current scripts is
> minimal.
>
> What about making this new behavior in fatlabel as default with new
> switch --fallback-to-boot-sector (switch to current behavior) or
> --read-only-boot-sector (ignores label in root directory) for people who
> are interested in label stored in boot sector?

Dunno how others will react, but I think what you are proposing makes sense.

> And what to do with blkid? That cannot have any switch :-( and can have
> only one behavior.

Btw, I don't see such tool in Debian unstable. Do you mean libblkid ?
lsblk OTOH has switches.

>> > This makes behavior consistent with older MS-DOS
>> > systems and also all Windows systems. This change would be a problem
>> > only for users who have label stored only in boot sector. After change
>> > they would not see label anymore -- exactly same what MS-DOS or Windows
>> > show them. Seems that mkdosfs stores label to both location, since
>> > support for label was introduced. So different label would be visible
>> > only for users who used dosfslabel prior to version 3.0.16.
>> >
>> > What do you think?
>>
>> So, in summary it looks like a documentation needs update (to mark
>> your research).
>
> Which documentation do you mean?

At least dosfstools (to mark that versions prior 3.0.16 better to avoid).

And any where new switch would have been added and / or default
behaviour would have been changed.

-- 
With Best Regards,
Andy Shevchenko

Re: Linux & FAT32 label

[Pali Rohár]

On Sunday 05 November 2017 16:25:54 Andy Shevchenko wrote:
> On Sun, Nov 5, 2017 at 4:07 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Sunday 05 November 2017 15:56:53 Andy Shevchenko wrote:
> >> On Sun, Nov 5, 2017 at 3:39 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> >> > On Tuesday 31 October 2017 10:35:48 Andy Shevchenko wrote:
> >> >> On Mon, Oct 16, 2017 at 4:12 AM, Andreas Bombe <aeb@debian.org> wrote:
> >> >> > On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote:
> >> >> >> On Thursday 12 October 2017 12:13:11 Karel Zak wrote:
> >>
> >> >> > I was worried that there might be some scripts or programs that expect
> >> >>
> >> >> If we really care about such scripts another approach might be to
> >> >> introduce a CLI switch to "spec compatible mode" to each tool and
> >> >> suggest in documentation to use it.
> >> >>
> >> >> There are also variants:
> >> >> - spec compatible
> >> >> - WinXX compatible
> >> >> - DOS compatible
> >> >> - etc
> >> >
> >> > I did tests with MS-DOS and Windows versions (results in previous
> >> > email), and they seems to be compatible how they read label.
> >> >
> >> > Based on results I would suggest to ignore label from the boot sector
> >> > when reading label.
> >>
> >> So, for tools which are not doing that to add
> >>
> >>  --ignore-boot-sector-label (or alike) [recommended]
> >>
> >> right?
> >>
> >> We don't actually know how many users (scripts) are relying on current
> >> behaviour.
> >> If there are only few, we may introduce backward compatibility switch
> >>
> >> --read-boot-sector-label
> >
> > Current behavior of the last blkid and fatlabel tools is: Try to read
> > label from the root directory. If it does not exist, then fallback to
> > label stored in boot sector. And when fatlabel is changing label it
> > updates both locations.
> >
> > So tools which already uses fatlabel for get & set operations should not
> > be affected as setting new label makes boot and root in sync.
> >
> > New proposed behavior is: Try to read label from the root directory. If
> > not exist, then treat disk as without label.
> >
> > As in current behavior there is no way via fatlabel to read "just only
> > label from boot sector", I think that problems for current scripts is
> > minimal.
> >
> > What about making this new behavior in fatlabel as default with new
> > switch --fallback-to-boot-sector (switch to current behavior) or
> > --read-only-boot-sector (ignores label in root directory) for people who
> > are interested in label stored in boot sector?
> 
> Dunno how others will react, but I think what you are proposing makes sense.
> 
> > And what to do with blkid? That cannot have any switch :-( and can have
> > only one behavior.
> 
> Btw, I don't see such tool in Debian unstable. Do you mean libblkid ?
> lsblk OTOH has switches.

https://packages.debian.org/search?suite=sid&arch=any&mode=path&searchon=contents&keywords=blkid

In Debian unstable, that tool is in binary package util-linux.

But you are right that implementation is in library libblkid and there
is no interface between blkid binary and libblkid for passing such
compatibility switches.

Also more application would use directly libblkid library and not blkid
binary...

And I would say that Karel (as maintainer of the util-linux upstream
project) does not want to see such switch in blkid just for FAT
partitions.

> >> > This makes behavior consistent with older MS-DOS
> >> > systems and also all Windows systems. This change would be a problem
> >> > only for users who have label stored only in boot sector. After change
> >> > they would not see label anymore -- exactly same what MS-DOS or Windows
> >> > show them. Seems that mkdosfs stores label to both location, since
> >> > support for label was introduced. So different label would be visible
> >> > only for users who used dosfslabel prior to version 3.0.16.
> >> >
> >> > What do you think?
> >>
> >> So, in summary it looks like a documentation needs update (to mark
> >> your research).
> >
> > Which documentation do you mean?
> 
> At least dosfstools (to mark that versions prior 3.0.16 better to avoid).
> 
> And any where new switch would have been added and / or default
> behaviour would have been changed.

Ok, I can prepare some updates for fatlabel manpage to describe how was
behavior changed in older versions. Andreas, do you agree?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Andy Shevchenko]

On Sun, Nov 5, 2017 at 4:34 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Sunday 05 November 2017 16:25:54 Andy Shevchenko wrote:
>> On Sun, Nov 5, 2017 at 4:07 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
>> > On Sunday 05 November 2017 15:56:53 Andy Shevchenko wrote:
>> >> On Sun, Nov 5, 2017 at 3:39 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
>> >> > On Tuesday 31 October 2017 10:35:48 Andy Shevchenko wrote:

>> >> > I did tests with MS-DOS and Windows versions (results in previous
>> >> > email), and they seems to be compatible how they read label.
>> >> >
>> >> > Based on results I would suggest to ignore label from the boot sector
>> >> > when reading label.
>> >>
>> >> So, for tools which are not doing that to add
>> >>
>> >>  --ignore-boot-sector-label (or alike) [recommended]
>> >>
>> >> right?
>> >>
>> >> We don't actually know how many users (scripts) are relying on current
>> >> behaviour.
>> >> If there are only few, we may introduce backward compatibility switch
>> >>
>> >> --read-boot-sector-label

>> > And what to do with blkid? That cannot have any switch :-( and can have
>> > only one behavior.
>>
>> Btw, I don't see such tool in Debian unstable. Do you mean libblkid ?
>> lsblk OTOH has switches.
>
> https://packages.debian.org/search?suite=sid&arch=any&mode=path&searchon=contents&keywords=blkid
>
> In Debian unstable, that tool is in binary package util-linux.

Found, it required me to be root or use full path.

In comparison lsblk might output partition label and FS label.

Looking to blkid help

       -L, --label label
             Look  up  the device that uses this filesystem label;
this is equal to --list-one --output device
             --match-token LABEL=label.

So, it can be PARTLABEL as well?

What the difference of LABEL vs. PARTLABEL for FAT?

> But you are right that implementation is in library libblkid and there
> is no interface between blkid binary and libblkid for passing such
> compatibility switches.
>
> Also more application would use directly libblkid library and not blkid
> binary...

Among other blkid manual has:

...lsblk(8) is also easy to use in scripts.  blkid is mostly designed
for system services and to test libblkid functionality.

which makes me think that we could just change it's behaviour to be sane.

OTOH libblkid is a root of such behaviour.

> And I would say that Karel (as maintainer of the util-linux upstream
> project) does not want to see such switch in blkid just for FAT
> partitions.

For me sane (default) behaviour in this case is to follow what windoze
/ dos does in most (default) cases.

-- 
With Best Regards,
Andy Shevchenko

Re: Linux & FAT32 label

[Pali Rohár]

On Sunday 05 November 2017 16:51:49 Andy Shevchenko wrote:
> In comparison lsblk might output partition label and FS label.
> 
> Looking to blkid help
> 
>        -L, --label label
>              Look  up  the device that uses this filesystem label;
> this is equal to --list-one --output device
>              --match-token LABEL=label.
> 
> So, it can be PARTLABEL as well?
> 
> What the difference of LABEL vs. PARTLABEL for FAT?

LABEL - label of the filesystem
PARTLABEL - label of the partition, supported e.g. by GPT scheme (not by MBR)

So nothing which filesystems in libblkid can set or use.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Theodore Ts'o]

On Sun, Nov 05, 2017 at 03:07:45PM +0100, Pali Rohár wrote:
> 
> Current behavior of the last blkid and fatlabel tools is: Try to read
> label from the root directory. If it does not exist, then fallback to
> label stored in boot sector. And when fatlabel is changing label it
> updates both locations.
> 
> So tools which already uses fatlabel for get & set operations should not
> be affected as setting new label makes boot and root in sync.
> 
> New proposed behavior is: Try to read label from the root directory. If
> not exist, then treat disk as without label.

Why is it important to ignore the label from the boot sector?  What is
the situation where if there is not a label in the root directory, and
there is a label in the boot sector, it is the Wrong Thing to return it?

For that matter, aside for a diskette from DOS 3.x (where using the
label from the boot sector *is* the right thing), why/when would we
ever have a label in the boot sector and not in the root director?

      	   	    	     	     	   - Ted

Re: Linux & FAT32 label

[Pali Rohár]

On Sunday 05 November 2017 15:35:42 Theodore Ts'o wrote:
> On Sun, Nov 05, 2017 at 03:07:45PM +0100, Pali Rohár wrote:
> > 
> > Current behavior of the last blkid and fatlabel tools is: Try to read
> > label from the root directory. If it does not exist, then fallback to
> > label stored in boot sector. And when fatlabel is changing label it
> > updates both locations.
> > 
> > So tools which already uses fatlabel for get & set operations should not
> > be affected as setting new label makes boot and root in sync.
> > 
> > New proposed behavior is: Try to read label from the root directory. If
> > not exist, then treat disk as without label.
> 
> Why is it important to ignore the label from the boot sector?  What is
> the situation where if there is not a label in the root directory, and
> there is a label in the boot sector, it is the Wrong Thing to return it?
> 
> For that matter, aside for a diskette from DOS 3.x (where using the
> label from the boot sector *is* the right thing), why/when would we
> ever have a label in the boot sector and not in the root director?

Easy way how to achieve this situation:

1. use mkdosfs to format hard disk to FAT32 with label LABEL42

2. boot Windows 10 (or XP) and set label of that FAT32 partition to
empty (via Explorer GUI)

3. profit

You would have stored LABEL42 in boot sector and no label in root
directory. Windows handle this situation as there is no label.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Karel Zak]

On Sun, Nov 05, 2017 at 03:34:11PM +0100, Pali Rohár wrote:
> On Sunday 05 November 2017 16:25:54 Andy Shevchenko wrote:
> > On Sun, Nov 5, 2017 at 4:07 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > On Sunday 05 November 2017 15:56:53 Andy Shevchenko wrote:
> > >> On Sun, Nov 5, 2017 at 3:39 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > >> > On Tuesday 31 October 2017 10:35:48 Andy Shevchenko wrote:
> > >> >> On Mon, Oct 16, 2017 at 4:12 AM, Andreas Bombe <aeb@debian.org> wrote:
> > >> >> > On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote:
> > >> >> >> On Thursday 12 October 2017 12:13:11 Karel Zak wrote:
> > >>
> > >> >> > I was worried that there might be some scripts or programs that expect
> > >> >>
> > >> >> If we really care about such scripts another approach might be to
> > >> >> introduce a CLI switch to "spec compatible mode" to each tool and
> > >> >> suggest in documentation to use it.
> > >> >>
> > >> >> There are also variants:
> > >> >> - spec compatible
> > >> >> - WinXX compatible
> > >> >> - DOS compatible
> > >> >> - etc
> > >> >
> > >> > I did tests with MS-DOS and Windows versions (results in previous
> > >> > email), and they seems to be compatible how they read label.
> > >> >
> > >> > Based on results I would suggest to ignore label from the boot sector
> > >> > when reading label.
> > >>
> > >> So, for tools which are not doing that to add
> > >>
> > >>  --ignore-boot-sector-label (or alike) [recommended]
> > >>
> > >> right?
> > >>
> > >> We don't actually know how many users (scripts) are relying on current
> > >> behaviour.
> > >> If there are only few, we may introduce backward compatibility switch
> > >>
> > >> --read-boot-sector-label

The current recommended way how to get filesystem label is to read it
from udev db. For example this is the way how lsblk reads labels by
default.

And udevd and some another tools are linked with libblkid. I don't
see an elegant way how to support something like "read-boot-sector-label" 
switch for the library to switch it on the fly.

Maybe it would be good enough to change the default behavior and add 
#ifdef to the library to switch to the old behavior. This is elegant
way how to move the decision to downstream maintainers. They have more
clue about importance of the FAT32 usage. I can imagine that for example
for some embedded systems it's more important than for example for
Fedora desktop. I prefer this solution.

The another way is to add an option to blkid.conf, but it will make
filesystems probing more complex and slow (we don't read the file
during superblocks probing now). I'm sure udev guys will hate me with
this solution. I'd like to avoid something like this.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Linux & FAT32 label

[Theodore Ts'o]

On Sun, Nov 05, 2017 at 10:12:49PM +0100, Pali Rohár wrote:
> Easy way how to achieve this situation:
> 
> 1. use mkdosfs to format hard disk to FAT32 with label LABEL42
> 
> 2. boot Windows 10 (or XP) and set label of that FAT32 partition to
> empty (via Explorer GUI)
> 
> 3. profit
> 
> You would have stored LABEL42 in boot sector and no label in root
> directory. Windows handle this situation as there is no label.

But why should we *care*?

Puzzled,

					- Ted

Re: Linux & FAT32 label

[Pali Rohár]

On Monday 06 November 2017 11:14:44 Karel Zak wrote:
> On Sun, Nov 05, 2017 at 03:34:11PM +0100, Pali Rohár wrote:
> > On Sunday 05 November 2017 16:25:54 Andy Shevchenko wrote:
> > > On Sun, Nov 5, 2017 at 4:07 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > > On Sunday 05 November 2017 15:56:53 Andy Shevchenko wrote:
> > > >> On Sun, Nov 5, 2017 at 3:39 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > > >> > On Tuesday 31 October 2017 10:35:48 Andy Shevchenko wrote:
> > > >> >> On Mon, Oct 16, 2017 at 4:12 AM, Andreas Bombe <aeb@debian.org> wrote:
> > > >> >> > On Thu, Oct 12, 2017 at 10:49:31PM +0200, Pali Rohár wrote:
> > > >> >> >> On Thursday 12 October 2017 12:13:11 Karel Zak wrote:
> > > >>
> > > >> >> > I was worried that there might be some scripts or programs that expect
> > > >> >>
> > > >> >> If we really care about such scripts another approach might be to
> > > >> >> introduce a CLI switch to "spec compatible mode" to each tool and
> > > >> >> suggest in documentation to use it.
> > > >> >>
> > > >> >> There are also variants:
> > > >> >> - spec compatible
> > > >> >> - WinXX compatible
> > > >> >> - DOS compatible
> > > >> >> - etc
> > > >> >
> > > >> > I did tests with MS-DOS and Windows versions (results in previous
> > > >> > email), and they seems to be compatible how they read label.
> > > >> >
> > > >> > Based on results I would suggest to ignore label from the boot sector
> > > >> > when reading label.
> > > >>
> > > >> So, for tools which are not doing that to add
> > > >>
> > > >>  --ignore-boot-sector-label (or alike) [recommended]
> > > >>
> > > >> right?
> > > >>
> > > >> We don't actually know how many users (scripts) are relying on current
> > > >> behaviour.
> > > >> If there are only few, we may introduce backward compatibility switch
> > > >>
> > > >> --read-boot-sector-label
> 
> The current recommended way how to get filesystem label is to read it
> from udev db. For example this is the way how lsblk reads labels by
> default.
> 
> And udevd and some another tools are linked with libblkid. I don't
> see an elegant way how to support something like "read-boot-sector-label" 
> switch for the library to switch it on the fly.
> 
> Maybe it would be good enough to change the default behavior and add 
> #ifdef to the library to switch to the old behavior. This is elegant
> way how to move the decision to downstream maintainers. They have more
> clue about importance of the FAT32 usage. I can imagine that for example
> for some embedded systems it's more important than for example for
> Fedora desktop. I prefer this solution.
> 
> The another way is to add an option to blkid.conf, but it will make
> filesystems probing more complex and slow (we don't read the file
> during superblocks probing now). I'm sure udev guys will hate me with
> this solution. I'd like to avoid something like this.

What about exporting e.g. BOOT_LABEL field from libblkid for vfat disks?
LABEL (which is shown to user, e.g. in GUI) would be that one from root
directory (same which is used by label on MS-DOS and Windows) and
BOOT_LABEL would be from boot sector. If somebody really needs to know
current label stored in boot sector he would be able to do it via blkid.
Also it would be possible then via blkid to read exact label stored in
root directory and also read what is stored in boot sector. Because
currently it is not possible to know from which location LABEL comes
from.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Pali Rohár]

On Tuesday 07 November 2017 12:28:41 Theodore Ts'o wrote:
> On Sun, Nov 05, 2017 at 10:12:49PM +0100, Pali Rohár wrote:
> > Easy way how to achieve this situation:
> > 
> > 1. use mkdosfs to format hard disk to FAT32 with label LABEL42
> > 
> > 2. boot Windows 10 (or XP) and set label of that FAT32 partition to
> > empty (via Explorer GUI)
> > 
> > 3. profit
> > 
> > You would have stored LABEL42 in boot sector and no label in root
> > directory. Windows handle this situation as there is no label.
> 
> But why should we *care*?

FAT is Microsoft's filesystem and the only usage of it on Linux is due
to interoperability with different non-Linux systems. So here we should
implement FAT in the similar/same way as other systems. It does not make
sense to implement it differently and specially in non-compatible way.
Because it lost reason what is primary usage of the FAT on Linux.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Karel Zak]

On Thu, Nov 09, 2017 at 09:59:09AM +0100, Pali Rohár wrote:
> What about exporting e.g. BOOT_LABEL field from libblkid for vfat disks?
> LABEL (which is shown to user, e.g. in GUI) would be that one from root
> directory (same which is used by label on MS-DOS and Windows) and
> BOOT_LABEL would be from boot sector. If somebody really needs to know
> current label stored in boot sector he would be able to do it via blkid.
> Also it would be possible then via blkid to read exact label stored in
> root directory and also read what is stored in boot sector. Because
> currently it is not possible to know from which location LABEL comes
> from.

This is good idea, there is no problem to export additional
information about filesystems. We already use it for another
filesystems too. Note, these details are visible for low-level
probing (blkid -p) and udev only. The high-level API follows
LABEL only.

Maybe it would be better to use LABEL_BOOT= or LABEL_FATBOOT= as name.

The important thing is the default behavior of the LABEL, this is what
use mount(8) and another tools.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Linux & FAT32 label

[Theodore Ts'o]

On Thu, Nov 09, 2017 at 10:01:45AM +0100, Pali Rohár wrote:
> > > You would have stored LABEL42 in boot sector and no label in root
> > > directory. Windows handle this situation as there is no label.
> > 
> > But why should we *care*?
> 
> FAT is Microsoft's filesystem and the only usage of it on Linux is due
> to interoperability with different non-Linux systems. So here we should
> implement FAT in the similar/same way as other systems. It does not make
> sense to implement it differently and specially in non-compatible way.
> Because it lost reason what is primary usage of the FAT on Linux.

The primary usage of FAT on Linux is for data interchange, primarily
with USB sticks.  I'm still failing to see how it might "spoil some
vast eternal plan"[1] if a USB stick which Windows would show as
having no label, blkid/udev showed as having the label "LABEL42"?

[1] to quote the song "If I were a rich man"

I'm just trying to understand why this specific detail of bit-for-bit
compatibility is so important.

						- Ted

Re: Linux & FAT32 label

[Pali Rohár]

On Thursday 09 November 2017 11:21:25 Theodore Ts'o wrote:
> On Thu, Nov 09, 2017 at 10:01:45AM +0100, Pali Rohár wrote:
> > > > You would have stored LABEL42 in boot sector and no label in root
> > > > directory. Windows handle this situation as there is no label.
> > > 
> > > But why should we *care*?
> > 
> > FAT is Microsoft's filesystem and the only usage of it on Linux is due
> > to interoperability with different non-Linux systems. So here we should
> > implement FAT in the similar/same way as other systems. It does not make
> > sense to implement it differently and specially in non-compatible way.
> > Because it lost reason what is primary usage of the FAT on Linux.
> 
> The primary usage of FAT on Linux is for data interchange, primarily
> with USB sticks.  I'm still failing to see how it might "spoil some
> vast eternal plan"[1] if a USB stick which Windows would show as
> having no label, blkid/udev showed as having the label "LABEL42"?
> 
> [1] to quote the song "If I were a rich man"
> 
> I'm just trying to understand why this specific detail of bit-for-bit
> compatibility is so important.

Then you can ask question: Why we are serving LABEL information to
users?

Some users really use LABEL as identifier for themself, what is either
stored on filesystem (in this case USB stick). And if somebody for some
reason want to remove label (just because it does not contain data which
label describe anymore), then user probably really want to use this
information.

LABEL is human readable identifier of particular filesystem on disk. If
one system show one label and another system show another different
label for same disk, then such information is useless.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Pali Rohár]

On Sunday 05 November 2017 14:06:08 Pali Rohár wrote:
> On Wednesday 11 October 2017 23:24:35 Pali Rohár wrote:
> > On Wednesday 04 October 2017 17:33:32 Pali Rohár wrote:
> > > Hi! There is a big inconsistency in Linux tools which read or write
> > > FAT32 label in filesystem images. The most common used are tools:
> > > blkid (from util-linux project), fatlabel (previously known as
> > > dosfslabel; from dosfstools project) and mlabel (from mtools project).
> > > 
> > > FAT32 is itself a big mess from Microsoft hell and even FAT32
> > > implementation in Microsoft Windows systems is not compliant to the
> > > released FAT32 documentation from Microsoft.
> > > 
> > > In past months I observed that Linux FAT32 tools has its own way how
> > > they interpret FAT32 label (known as volume id) and because every GUI
> > > application uses one of those low-level command line tool, it is a big
> > > mess if one application say that FAT32 label is A and another that it is
> > > B. And then Windows XP say, it is C.
> > > 
> > > I would like to open discussion if it would be possible to change
> > > behavior how blkid (from util-linux project) and fatlabel (from
> > > dosfstool project) handle FAT32 label. Ideally to report exactly same
> > > output.
> > > 
> > > Basic information about FAT32 label:
> > > 
> > > 1) It is stored in two locations: boot sector and root directory as
> > >    file name.
> > > 
> > > 2) In both location format is 11 bytes, padded with spaces (not nulls).
> > > 
> > > 3) Empty label in boot sector is stored as "NO NAME    " and not as
> > >    empty string.
> > > 
> > > 4) Empty label in root directory is stored either as name which starts
> > >    with byte 0xE5, or is not stored in root directory at all.
> > > 
> > > 5) If label contains leading byte 0xE5, then in root directory is stored
> > >    as byte 0x05.
> > > 
> > > 6) Label string is stored according to current DOS code page. Therefore
> > >    label string needs to be converted to bytes.
> > > 
> > > 7) Label string cannot contain control characters and characters from
> > >    the set   ? / \ | . , ; : + = [ ] < > "   plus lower case characters
> > >    are stored as their upper case variant (not only ASCII).
> > > 
> > > (Please correct me if I'm wrong in some of those points)
> > > 
> > > Plus Microsoft Windows systems fully ignores label stored in boot
> > > sector. Seems they do not read it nor they do not update it on changes.
> > > 
> > > Looks like that mlabel (from mtools) applies all above rules and uses
> > > DOS code page 850 by default (can be changed in config file).
> > > 
> > > blkid and fatlabel process special cases from 1) to 5) differently and
> > > they operates on raw bytes, not strings (in DOS code page).
> > > 
> > > mlabel reads label from the root directory (missing entry is interpreted
> > > as no label; there is no fallback to boot sector), but "set" operation
> > > modify label in both location boot sector + root directory. Basically it
> > > is near to Windows implementation. And reason why Gparted GUI
> > > application uses mlabel and not fatlabel.
> > > 
> > > As Linux does not have "current DOS code page" and argv arguments are
> > > not (Unicode) strings, but arbitrary bytes, I understand that for point
> > > 6) it is easier to operates not on FAT strings (in current code page),
> > > but rather on bytes. Which also would be same on all machines with any
> > > configuration.
> > > 
> > > But would it be possible to decide and unify handling of point 2), 3),
> > > 4), 5)? Ideally with combination how to handle situation when different
> > > label is stored in boot sector and root directory.
> > > 
> > > As Windows does not use label in boot sector, it is very common
> > > situation that label in boot sector differs from the root directory.
> > > 
> > > The best would be see in all cases same label from blkid, fatlabel and
> > > mlabel. Ideally same as Windows machines -- but due to DOS code page,
> > > this is possible only for ASCII subset of the 8bit encoding. IIRC most
> > > (or all?) DOS code page has same characters in printable ASCII range.
> > > 
> > > It is really bad situation if I open disk in Gparted which show me label
> > > via mlabel and then I open in KDE Partition Manager and I see different
> > > label string (as it reads it from fatlabel).
> > > 
> > > Also note that older version of fatlabel (when it was named dosfslabel)
> > > operated only the label stored in boot sector (and label stored in root
> > > directory was not read or touched).
> > > 
> > 
> > Hi! I did some testing of FAT32 label with different tools and here are
> > results:
> 
> Hi! I did more tests with MS-DOS and Windows systems and I'm extending
> result tables below:
> 
> >                                                  dosfslabel 3.0.12   fatlabel 4.1       blkid 2.20.1   mlabel 4.0.12   label.exe Windows XP
> > fat32_mkdosfs_label1                             'label1     '       'label1     '      'label1'       'label1     '   'label1'
> > fat32_mkdosfs_label1_dosfslabel_empty            '           '       '           '      none           '           '   none
> > fat32_mkdosfs_label1_dosfslabel_label2           'label2     '       'label2     '      'label2'       'label2     '   'label2'
> > fat32_mkdosfs_label1_dosfslabel_NO_NAME          'NO NAME    '       'NO NAME    '      none           'NO NAME    '   'NO NAME'
> > fat32_mkdosfs_label1_mlabel_erase                'NO NAME    '       'NO NAME    '      none           none            none
> > fat32_mkdosfs_label1_mlabel_NO_NAME              'NO NAME    '       'NO NAME    '      none           'NO NAME    '   'NO NAME'
> > fat32_mkdosfs_label1_xp_erase                    'label1'    '       0xE5'abel1     '   'label1'       none            none
> > fat32_mkdosfs_label1_xp_label2                   'label1'    '       'LABEL2     '      'LABEL2'       'LABEL2     '   'LABEL2'
> > fat32_mkdosfs_none                               '           '       '           '      none           none            none
> > fat32_mkdosfs_none_dosfslabel_label1             'label1     '       'label1     '      'label1'       none            none
> > fat32_mkdosfs_none_dosfslabel_label1_xp_label2   'label1'    '       'LABEL2     '      'LABEL2'       'LABEL2     '   'LABEL2'
> > fat32_mkdosfs_none_dosfslabel_NO_NAME            'NO NAME    '       'NO NAME    '      none           none            none
> > fat32_mkdosfs_none_xp_label1                     '           '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'
> > fat32_mkdosfs_none_xp_label1_dosfslabel_label2   'label2     '       'label2     '      'label2'       'label2     '   'label2'
> > fat32_xp_label1                                  'NO NAME    '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'
> > fat32_xp_none                                    'NO NAME    '       'NO NAME    '      none           none            none
> > fat32_xp_none_dosfslabel_label1                  'label1     '       'label1     '      'label1'       none            none
> > fat32_xp_none_mlabel_label1                      'LABEL1     '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'
> 
>                                                    label.exe MS-DOS 7.10   label.exe Windows 98   label.exe Windows 10
> fat32_mkdosfs_label1                               'label1'                'label1'               'label1'
> fat32_mkdosfs_label1_dosfslabel_empty              ''                      ''                     none
> fat32_mkdosfs_label1_dosfslabel_label2             'label2'                'label2'               'label2'
> fat32_mkdosfs_label1_dosfslabel_NO_NAME            'NO NAME'               'NO NAME'              'NO NAME'
> fat32_mkdosfs_label1_mlabel_erase                  none                    none                   none
> fat32_mkdosfs_label1_mlabel_NO_NAME                'NO NAME'               'NO NAME'              'NO NAME'
> fat32_mkdosfs_label1_xp_erase                      none                    none                   none
> fat32_mkdosfs_label1_xp_label2                     'LABEL2'                'LABEL2'               'LABEL2'
> fat32_mkdosfs_none                                 none                    none                   none
> fat32_mkdosfs_none_dosfslabel_label1               none                    none                   none
> fat32_mkdosfs_none_dosfslabel_label1_xp_label2     'LABEL2'                'LABEL2'               'LABEL2'
> fat32_mkdosfs_none_dosfslabel_NO_NAME              none                    none                   none
> fat32_mkdosfs_none_xp_label1                       'LABEL1'                'LABEL1'               'LABEL1'
> fat32_mkdosfs_none_xp_label1_dosfslabel_label2     'label2'                'label2'               'label2'
> fat32_xp_label1                                    'LABEL1'                'LABEL1'               'LABEL1'
> fat32_xp_none                                      none                    none                   none
> fat32_xp_none_dosfslabel_label1                    none                    none                   none
> fat32_xp_none_mlabel_label1                        'LABEL1'                'LABEL1'               'LABEL1'
> 
> Seems that behavior of reading label from FAT32 volume is consistent
> between MS-DOS and different Windows versions. The only exception is
> when in label in the root directory is stored as empty string (11
> spaces). MS-DOS and Windows 98 treat it as label with empty string, but
> Windows XP and Windows 10 as disk without label.
> 
> > In the first column is image name (all images are compressed and
> > attached) which contains steps of operations, e.g. file name
> > fat32_mkdosfs_none_dosfslabel_label1_xp_label2 means:
> > 
> > 1. create filesystem with mkdosfs without specifying label
> > 2. change label with dosfslabel (3.0.12) to 'label1'
> > 3. change label under Windows XP to 'label2'
> > 
> > From testing it looks like that different tools and different version of
> > them have different behavior how they read or write FAT32 label, see
> > following table:
> > 
> >                              read boot   write boot   read root   write root
> > dosfslabel 3.0.0  - 3.0.6    YES         YES          NO          NO
> > dosfslabel 3.0.7  - 3.0.15   YES         YES          NO          BUGGY (YES - if already exists; NO - otherwise)
> > dosfslabel 3.0.16 - 4.1      YES         YES          YES         YES
> > label.exe Windows XP         NO          NO           YES         YES
> > blkid                        YES         NO           YES         NO
> > mlabel                       NO          YES          YES         YES
> 
> label.exe MS-DOS 6.22          NO          YES          YES         YES
> label.exe MS-DOS 7.10          NO          YES          YES         YES
> label.exe Windows 98 SE        NO          YES          YES         YES
> label.exe Windows 10           NO          NO           YES         YES
> 
> Older MS-DOS 6.22 does not support FAT32 disks, only FAT16. MS-DOS 7.10
> has support for FAT32 and also for LFN. But both tested MS-DOS versions
> and Windows 98 updates label in both locations: boot sector and root
> directory. Also in case when label is changed in Windows 98 via
> "My Computer" GUI.
> 
> From above tests it can be seen that both MS-DOS and all Windows
> versions ignores label which is stored in boot sector and show to user
> only label from root directory.
> 
> Also it can be seen that both MS-DOS versions do not have problems when
> label contains lower case letters.
> 
> > Attached images in compressed form has only 600 kB and I think they can
> > be useful for testing either blkid or dosfstools project, so I'm sending
> > them here.
> 

So from all tests and discussion I would propose new unification:

1. Read label only from the root directory. If label in root directory
   is missing then disk would be treated as without label. Label from
   boot sector would not be read.

   --> Reason: Windows XP and mlabel ignores what is written in boot
       sector. Windows XP even do not update boot sector, so label
       stored in boot sector is incorrect after any change done by
       Windows XP.

       This logic is used by all tested MS-DOS and Windows versions,
       plus also by mtools on Linux.

2. Write label to to both location, boot sector and root directory.

   --> Reason: MS-DOS 6.22, MS-DOS 7.10, Windows 98 and also mtools on
       Linux do this. This is also what is written in FAT specification.

       It also provides backward compatibility with old dosfslabel
       versions which read label only from boot sector.

2. Process 'NO NAME    ' label in root directory as 'NO NAME' name. Not
   as empty label.

   --> Reason: 'NO NAME    ' is regular entry in root directory and both
       Windows XP and mlabel handle it in this way.

3. Process 'NO NAME    ' label in boot directory as empty label. Not as
   label with name 'NO NAME'.

   --> Reason: On Windows XP when formatting empty disk and label is not
       specified then 'NO NAME    ' is stored to boot sector.

       Also in FAT specification is written that empty label is stored
       as 'NO NAME    '.

With this change we would get compatibility with MS-DOS, Windows (both
DOS-based and NT-based) and also with Linux mtools, modulo problems DOS
code page.

There are just two negatives:

1) Labels set by old dosfslabel versions (which stored them only to boot
   sector) would not be visible. But they are already not visible on
   MS-DOS or Windows machines, and also via mlabel (from mtools).

2) Behavior of blkid and fatlabel would be changed as both tools have
   different as proposed above, and based on tests they also differ each
   from other.

Andreas, Karel, what do you think about it?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Pali Rohár]

On Thursday 09 November 2017 22:21:31 Pali Rohár wrote:
> On Sunday 05 November 2017 14:06:08 Pali Rohár wrote:
> > On Wednesday 11 October 2017 23:24:35 Pali Rohár wrote:
> > > On Wednesday 04 October 2017 17:33:32 Pali Rohár wrote:
> > > > Hi! There is a big inconsistency in Linux tools which read or write
> > > > FAT32 label in filesystem images. The most common used are tools:
> > > > blkid (from util-linux project), fatlabel (previously known as
> > > > dosfslabel; from dosfstools project) and mlabel (from mtools project).
> > > > 
> > > > FAT32 is itself a big mess from Microsoft hell and even FAT32
> > > > implementation in Microsoft Windows systems is not compliant to the
> > > > released FAT32 documentation from Microsoft.
> > > > 
> > > > In past months I observed that Linux FAT32 tools has its own way how
> > > > they interpret FAT32 label (known as volume id) and because every GUI
> > > > application uses one of those low-level command line tool, it is a big
> > > > mess if one application say that FAT32 label is A and another that it is
> > > > B. And then Windows XP say, it is C.
> > > > 
> > > > I would like to open discussion if it would be possible to change
> > > > behavior how blkid (from util-linux project) and fatlabel (from
> > > > dosfstool project) handle FAT32 label. Ideally to report exactly same
> > > > output.
> > > > 
> > > > Basic information about FAT32 label:
> > > > 
> > > > 1) It is stored in two locations: boot sector and root directory as
> > > >    file name.
> > > > 
> > > > 2) In both location format is 11 bytes, padded with spaces (not nulls).
> > > > 
> > > > 3) Empty label in boot sector is stored as "NO NAME    " and not as
> > > >    empty string.
> > > > 
> > > > 4) Empty label in root directory is stored either as name which starts
> > > >    with byte 0xE5, or is not stored in root directory at all.
> > > > 
> > > > 5) If label contains leading byte 0xE5, then in root directory is stored
> > > >    as byte 0x05.
> > > > 
> > > > 6) Label string is stored according to current DOS code page. Therefore
> > > >    label string needs to be converted to bytes.
> > > > 
> > > > 7) Label string cannot contain control characters and characters from
> > > >    the set   ? / \ | . , ; : + = [ ] < > "   plus lower case characters
> > > >    are stored as their upper case variant (not only ASCII).
> > > > 
> > > > (Please correct me if I'm wrong in some of those points)
> > > > 
> > > > Plus Microsoft Windows systems fully ignores label stored in boot
> > > > sector. Seems they do not read it nor they do not update it on changes.
> > > > 
> > > > Looks like that mlabel (from mtools) applies all above rules and uses
> > > > DOS code page 850 by default (can be changed in config file).
> > > > 
> > > > blkid and fatlabel process special cases from 1) to 5) differently and
> > > > they operates on raw bytes, not strings (in DOS code page).
> > > > 
> > > > mlabel reads label from the root directory (missing entry is interpreted
> > > > as no label; there is no fallback to boot sector), but "set" operation
> > > > modify label in both location boot sector + root directory. Basically it
> > > > is near to Windows implementation. And reason why Gparted GUI
> > > > application uses mlabel and not fatlabel.
> > > > 
> > > > As Linux does not have "current DOS code page" and argv arguments are
> > > > not (Unicode) strings, but arbitrary bytes, I understand that for point
> > > > 6) it is easier to operates not on FAT strings (in current code page),
> > > > but rather on bytes. Which also would be same on all machines with any
> > > > configuration.
> > > > 
> > > > But would it be possible to decide and unify handling of point 2), 3),
> > > > 4), 5)? Ideally with combination how to handle situation when different
> > > > label is stored in boot sector and root directory.
> > > > 
> > > > As Windows does not use label in boot sector, it is very common
> > > > situation that label in boot sector differs from the root directory.
> > > > 
> > > > The best would be see in all cases same label from blkid, fatlabel and
> > > > mlabel. Ideally same as Windows machines -- but due to DOS code page,
> > > > this is possible only for ASCII subset of the 8bit encoding. IIRC most
> > > > (or all?) DOS code page has same characters in printable ASCII range.
> > > > 
> > > > It is really bad situation if I open disk in Gparted which show me label
> > > > via mlabel and then I open in KDE Partition Manager and I see different
> > > > label string (as it reads it from fatlabel).
> > > > 
> > > > Also note that older version of fatlabel (when it was named dosfslabel)
> > > > operated only the label stored in boot sector (and label stored in root
> > > > directory was not read or touched).
> > > > 
> > > 
> > > Hi! I did some testing of FAT32 label with different tools and here are
> > > results:
> > 
> > Hi! I did more tests with MS-DOS and Windows systems and I'm extending
> > result tables below:
> > 
> > >                                                  dosfslabel 3.0.12   fatlabel 4.1       blkid 2.20.1   mlabel 4.0.12   label.exe Windows XP
> > > fat32_mkdosfs_label1                             'label1     '       'label1     '      'label1'       'label1     '   'label1'
> > > fat32_mkdosfs_label1_dosfslabel_empty            '           '       '           '      none           '           '   none
> > > fat32_mkdosfs_label1_dosfslabel_label2           'label2     '       'label2     '      'label2'       'label2     '   'label2'
> > > fat32_mkdosfs_label1_dosfslabel_NO_NAME          'NO NAME    '       'NO NAME    '      none           'NO NAME    '   'NO NAME'
> > > fat32_mkdosfs_label1_mlabel_erase                'NO NAME    '       'NO NAME    '      none           none            none
> > > fat32_mkdosfs_label1_mlabel_NO_NAME              'NO NAME    '       'NO NAME    '      none           'NO NAME    '   'NO NAME'
> > > fat32_mkdosfs_label1_xp_erase                    'label1'    '       0xE5'abel1     '   'label1'       none            none
> > > fat32_mkdosfs_label1_xp_label2                   'label1'    '       'LABEL2     '      'LABEL2'       'LABEL2     '   'LABEL2'
> > > fat32_mkdosfs_none                               '           '       '           '      none           none            none
> > > fat32_mkdosfs_none_dosfslabel_label1             'label1     '       'label1     '      'label1'       none            none
> > > fat32_mkdosfs_none_dosfslabel_label1_xp_label2   'label1'    '       'LABEL2     '      'LABEL2'       'LABEL2     '   'LABEL2'
> > > fat32_mkdosfs_none_dosfslabel_NO_NAME            'NO NAME    '       'NO NAME    '      none           none            none
> > > fat32_mkdosfs_none_xp_label1                     '           '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'
> > > fat32_mkdosfs_none_xp_label1_dosfslabel_label2   'label2     '       'label2     '      'label2'       'label2     '   'label2'
> > > fat32_xp_label1                                  'NO NAME    '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'
> > > fat32_xp_none                                    'NO NAME    '       'NO NAME    '      none           none            none
> > > fat32_xp_none_dosfslabel_label1                  'label1     '       'label1     '      'label1'       none            none
> > > fat32_xp_none_mlabel_label1                      'LABEL1     '       'LABEL1     '      'LABEL1'       'LABEL1     '   'LABEL1'
> > 
> >                                                    label.exe MS-DOS 7.10   label.exe Windows 98   label.exe Windows 10
> > fat32_mkdosfs_label1                               'label1'                'label1'               'label1'
> > fat32_mkdosfs_label1_dosfslabel_empty              ''                      ''                     none
> > fat32_mkdosfs_label1_dosfslabel_label2             'label2'                'label2'               'label2'
> > fat32_mkdosfs_label1_dosfslabel_NO_NAME            'NO NAME'               'NO NAME'              'NO NAME'
> > fat32_mkdosfs_label1_mlabel_erase                  none                    none                   none
> > fat32_mkdosfs_label1_mlabel_NO_NAME                'NO NAME'               'NO NAME'              'NO NAME'
> > fat32_mkdosfs_label1_xp_erase                      none                    none                   none
> > fat32_mkdosfs_label1_xp_label2                     'LABEL2'                'LABEL2'               'LABEL2'
> > fat32_mkdosfs_none                                 none                    none                   none
> > fat32_mkdosfs_none_dosfslabel_label1               none                    none                   none
> > fat32_mkdosfs_none_dosfslabel_label1_xp_label2     'LABEL2'                'LABEL2'               'LABEL2'
> > fat32_mkdosfs_none_dosfslabel_NO_NAME              none                    none                   none
> > fat32_mkdosfs_none_xp_label1                       'LABEL1'                'LABEL1'               'LABEL1'
> > fat32_mkdosfs_none_xp_label1_dosfslabel_label2     'label2'                'label2'               'label2'
> > fat32_xp_label1                                    'LABEL1'                'LABEL1'               'LABEL1'
> > fat32_xp_none                                      none                    none                   none
> > fat32_xp_none_dosfslabel_label1                    none                    none                   none
> > fat32_xp_none_mlabel_label1                        'LABEL1'                'LABEL1'               'LABEL1'
> > 
> > Seems that behavior of reading label from FAT32 volume is consistent
> > between MS-DOS and different Windows versions. The only exception is
> > when in label in the root directory is stored as empty string (11
> > spaces). MS-DOS and Windows 98 treat it as label with empty string, but
> > Windows XP and Windows 10 as disk without label.
> > 
> > > In the first column is image name (all images are compressed and
> > > attached) which contains steps of operations, e.g. file name
> > > fat32_mkdosfs_none_dosfslabel_label1_xp_label2 means:
> > > 
> > > 1. create filesystem with mkdosfs without specifying label
> > > 2. change label with dosfslabel (3.0.12) to 'label1'
> > > 3. change label under Windows XP to 'label2'
> > > 
> > > From testing it looks like that different tools and different version of
> > > them have different behavior how they read or write FAT32 label, see
> > > following table:
> > > 
> > >                              read boot   write boot   read root   write root
> > > dosfslabel 3.0.0  - 3.0.6    YES         YES          NO          NO
> > > dosfslabel 3.0.7  - 3.0.15   YES         YES          NO          BUGGY (YES - if already exists; NO - otherwise)
> > > dosfslabel 3.0.16 - 4.1      YES         YES          YES         YES
> > > label.exe Windows XP         NO          NO           YES         YES
> > > blkid                        YES         NO           YES         NO
> > > mlabel                       NO          YES          YES         YES
> > 
> > label.exe MS-DOS 6.22          NO          YES          YES         YES
> > label.exe MS-DOS 7.10          NO          YES          YES         YES
> > label.exe Windows 98 SE        NO          YES          YES         YES
> > label.exe Windows 10           NO          NO           YES         YES
> > 
> > Older MS-DOS 6.22 does not support FAT32 disks, only FAT16. MS-DOS 7.10
> > has support for FAT32 and also for LFN. But both tested MS-DOS versions
> > and Windows 98 updates label in both locations: boot sector and root
> > directory. Also in case when label is changed in Windows 98 via
> > "My Computer" GUI.
> > 
> > From above tests it can be seen that both MS-DOS and all Windows
> > versions ignores label which is stored in boot sector and show to user
> > only label from root directory.
> > 
> > Also it can be seen that both MS-DOS versions do not have problems when
> > label contains lower case letters.
> > 
> > > Attached images in compressed form has only 600 kB and I think they can
> > > be useful for testing either blkid or dosfstools project, so I'm sending
> > > them here.
> > 
> 
> So from all tests and discussion I would propose new unification:
> 
> 1. Read label only from the root directory. If label in root directory
>    is missing then disk would be treated as without label. Label from
>    boot sector would not be read.
> 
>    --> Reason: Windows XP and mlabel ignores what is written in boot
>        sector. Windows XP even do not update boot sector, so label
>        stored in boot sector is incorrect after any change done by
>        Windows XP.
> 
>        This logic is used by all tested MS-DOS and Windows versions,
>        plus also by mtools on Linux.
> 
> 2. Write label to to both location, boot sector and root directory.
> 
>    --> Reason: MS-DOS 6.22, MS-DOS 7.10, Windows 98 and also mtools on
>        Linux do this. This is also what is written in FAT specification.
> 
>        It also provides backward compatibility with old dosfslabel
>        versions which read label only from boot sector.
> 
> 2. Process 'NO NAME    ' label in root directory as 'NO NAME' name. Not
>    as empty label.
> 
>    --> Reason: 'NO NAME    ' is regular entry in root directory and both
>        Windows XP and mlabel handle it in this way.
> 
> 3. Process 'NO NAME    ' label in boot directory as empty label. Not as
>    label with name 'NO NAME'.
> 
>    --> Reason: On Windows XP when formatting empty disk and label is not
>        specified then 'NO NAME    ' is stored to boot sector.
> 
>        Also in FAT specification is written that empty label is stored
>        as 'NO NAME    '.
> 
> With this change we would get compatibility with MS-DOS, Windows (both
> DOS-based and NT-based) and also with Linux mtools, modulo problems DOS
> code page.
> 
> There are just two negatives:
> 
> 1) Labels set by old dosfslabel versions (which stored them only to boot
>    sector) would not be visible. But they are already not visible on
>    MS-DOS or Windows machines, and also via mlabel (from mtools).
> 
> 2) Behavior of blkid and fatlabel would be changed as both tools have
>    different as proposed above, and based on tests they also differ each
>    from other.
> 
> Andreas, Karel, what do you think about it?

Also for other people, do any have comments on my proposed solution?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Karel Zak]

On Sun, Nov 19, 2017 at 01:44:40PM +0100, Pali Rohár wrote:
> On Thursday 09 November 2017 22:21:31 Pali Rohár wrote:
> > So from all tests and discussion I would propose new unification:
> > 
> > 1. Read label only from the root directory. If label in root directory
> >    is missing then disk would be treated as without label. Label from
> >    boot sector would not be read.
> > 
> >    --> Reason: Windows XP and mlabel ignores what is written in boot
> >        sector. Windows XP even do not update boot sector, so label
> >        stored in boot sector is incorrect after any change done by
> >        Windows XP.
> > 
> >        This logic is used by all tested MS-DOS and Windows versions,
> >        plus also by mtools on Linux.
> > 
> > 2. Write label to to both location, boot sector and root directory.
> > 
> >    --> Reason: MS-DOS 6.22, MS-DOS 7.10, Windows 98 and also mtools on
> >        Linux do this. This is also what is written in FAT specification.
> > 
> >        It also provides backward compatibility with old dosfslabel
> >        versions which read label only from boot sector.
> > 
> > 2. Process 'NO NAME    ' label in root directory as 'NO NAME' name. Not
> >    as empty label.
> > 
> >    --> Reason: 'NO NAME    ' is regular entry in root directory and both
> >        Windows XP and mlabel handle it in this way.
> > 
> > 3. Process 'NO NAME    ' label in boot directory as empty label. Not as
> >    label with name 'NO NAME'.
> > 
> >    --> Reason: On Windows XP when formatting empty disk and label is not
> >        specified then 'NO NAME    ' is stored to boot sector.
> > 
> >        Also in FAT specification is written that empty label is stored
> >        as 'NO NAME    '.
> > 
> > With this change we would get compatibility with MS-DOS, Windows (both
> > DOS-based and NT-based) and also with Linux mtools, modulo problems DOS
> > code page.
> > 
> > There are just two negatives:
> > 
> > 1) Labels set by old dosfslabel versions (which stored them only to boot
> >    sector) would not be visible. But they are already not visible on
> >    MS-DOS or Windows machines, and also via mlabel (from mtools).
> > 
> > 2) Behavior of blkid and fatlabel would be changed as both tools have
> >    different as proposed above, and based on tests they also differ each
> >    from other.
> > 
> > Andreas, Karel, what do you think about it?
> 
> Also for other people, do any have comments on my proposed solution?

Go ahead and send patch :-) (also with LABEL_FATBOOT=)

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Linux & FAT32 label

[Pali Rohár]

On Monday 20 November 2017 12:12:56 Karel Zak wrote:
> On Sun, Nov 19, 2017 at 01:44:40PM +0100, Pali Rohár wrote:
> > On Thursday 09 November 2017 22:21:31 Pali Rohár wrote:
> > > So from all tests and discussion I would propose new unification:
> > > 
> > > 1. Read label only from the root directory. If label in root directory
> > >    is missing then disk would be treated as without label. Label from
> > >    boot sector would not be read.
> > > 
> > >    --> Reason: Windows XP and mlabel ignores what is written in boot
> > >        sector. Windows XP even do not update boot sector, so label
> > >        stored in boot sector is incorrect after any change done by
> > >        Windows XP.
> > > 
> > >        This logic is used by all tested MS-DOS and Windows versions,
> > >        plus also by mtools on Linux.
> > > 
> > > 2. Write label to to both location, boot sector and root directory.
> > > 
> > >    --> Reason: MS-DOS 6.22, MS-DOS 7.10, Windows 98 and also mtools on
> > >        Linux do this. This is also what is written in FAT specification.
> > > 
> > >        It also provides backward compatibility with old dosfslabel
> > >        versions which read label only from boot sector.
> > > 
> > > 2. Process 'NO NAME    ' label in root directory as 'NO NAME' name. Not
> > >    as empty label.
> > > 
> > >    --> Reason: 'NO NAME    ' is regular entry in root directory and both
> > >        Windows XP and mlabel handle it in this way.
> > > 
> > > 3. Process 'NO NAME    ' label in boot directory as empty label. Not as
> > >    label with name 'NO NAME'.
> > > 
> > >    --> Reason: On Windows XP when formatting empty disk and label is not
> > >        specified then 'NO NAME    ' is stored to boot sector.
> > > 
> > >        Also in FAT specification is written that empty label is stored
> > >        as 'NO NAME    '.
> > > 
> > > With this change we would get compatibility with MS-DOS, Windows (both
> > > DOS-based and NT-based) and also with Linux mtools, modulo problems DOS
> > > code page.
> > > 
> > > There are just two negatives:
> > > 
> > > 1) Labels set by old dosfslabel versions (which stored them only to boot
> > >    sector) would not be visible. But they are already not visible on
> > >    MS-DOS or Windows machines, and also via mlabel (from mtools).
> > > 
> > > 2) Behavior of blkid and fatlabel would be changed as both tools have
> > >    different as proposed above, and based on tests they also differ each
> > >    from other.
> > > 
> > > Andreas, Karel, what do you think about it?
> > 
> > Also for other people, do any have comments on my proposed solution?
> 
> Go ahead and send patch :-) (also with LABEL_FATBOOT=)

Ok, but what with fatlabel (from dosfstools)?
Andreas, any comments on this solution?

I can prepare patches for blkid (util-linux), but I do not like idea to
have different algorithm how is read label in fatlabel and blkid. Both
tools are used by different GUI programs and it is a bad if one GUI
program on linux (e.g. GParted) tells you that label is A and another
(e.g. KDE Partition Manager) that label is B. So I rather wait for final
decision.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Karel Zak]

On Wed, Nov 22, 2017 at 09:52:03AM +0100, Pali Rohár wrote:
> I can prepare patches for blkid (util-linux), but I do not like idea to
> have different algorithm how is read label in fatlabel and blkid. Both
> tools are used by different GUI programs and it is a bad if one GUI
> program on linux (e.g. GParted) tells you that label is A and another
> (e.g. KDE Partition Manager) that label is B. So I rather wait for final
> decision.

Maybe it's time to update all the GUI stuff to read LABELs and UUIDs
(and another attributes) from udev db.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Linux & FAT32 label

[Andrius Štikonas]

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

2017 m. lapkričio 22 d., trečiadienis 11:03:52 GMT rašėte:
> On Wed, Nov 22, 2017 at 09:52:03AM +0100, Pali Rohár wrote:
> > I can prepare patches for blkid (util-linux), but I do not like idea to
> > have different algorithm how is read label in fatlabel and blkid. Both
> > tools are used by different GUI programs and it is a bad if one GUI
> > program on linux (e.g. GParted) tells you that label is A and another
> > (e.g. KDE Partition Manager) that label is B. So I rather wait for final
> > decision.
> 
> Maybe it's time to update all the GUI stuff to read LABELs and UUIDs
> (and another attributes) from udev db.
> 
>     Karel
> 
> 

Indeed, it might be better. I can update KDE Partition Manager.
Maybe not too quickly, but sometime next year I can release it.

Andrius

-- 
I encourage the use of end to end email encryption

GPG key:   https://stikonas.eu/andrius.asc
Fingerprint:  1EE5 A320 5904 BAA2 B88C 0A9D 24FD 3194 0095 C0E1

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Linux & FAT32 label

[Pali Rohár]

On Wednesday 22 November 2017 12:03:52 Karel Zak wrote:
> On Wed, Nov 22, 2017 at 09:52:03AM +0100, Pali Rohár wrote:
> > I can prepare patches for blkid (util-linux), but I do not like idea to
> > have different algorithm how is read label in fatlabel and blkid. Both
> > tools are used by different GUI programs and it is a bad if one GUI
> > program on linux (e.g. GParted) tells you that label is A and another
> > (e.g. KDE Partition Manager) that label is B. So I rather wait for final
> > decision.
> 
> Maybe it's time to update all the GUI stuff to read LABELs and UUIDs
> (and another attributes) from udev db.

This is just one side of coin. Another is that these GUI applications
needs to set/change labels, UUIDs, ... What udev/blkid does not support.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Pali Rohár]

On Monday 20 November 2017 12:12:56 Karel Zak wrote:
> Go ahead and send patch :-) (also with LABEL_FATBOOT=)

Ok, I prepared patches for util-linux including LABEL_FATBOOT:
https://github.com/karelzak/util-linux/compare/master...pali:master

I have not created official pull request on github yet as Andreas have
not decided yet about dosfstools/fatlabel...

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Karel Zak]

On Sun, Nov 26, 2017 at 08:19:25PM +0100, Pali Rohár wrote:
> On Monday 20 November 2017 12:12:56 Karel Zak wrote:
> > Go ahead and send patch :-) (also with LABEL_FATBOOT=)
> 
> Ok, I prepared patches for util-linux including LABEL_FATBOOT:
> https://github.com/karelzak/util-linux/compare/master...pali:master

Seems good. I'll wait for official pull request. Thanks!

> I have not created official pull request on github yet as Andreas have
> not decided yet about dosfstools/fatlabel...

OK.

  Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Linux & FAT32 label

[Pali Rohár]

On Monday 20 November 2017 12:12:56 Karel Zak wrote:
> On Sun, Nov 19, 2017 at 01:44:40PM +0100, Pali Rohár wrote:
> > On Thursday 09 November 2017 22:21:31 Pali Rohár wrote:
> > > So from all tests and discussion I would propose new unification:
> > > 
> > > 1. Read label only from the root directory. If label in root directory
> > >    is missing then disk would be treated as without label. Label from
> > >    boot sector would not be read.
> > > 
> > >    --> Reason: Windows XP and mlabel ignores what is written in boot
> > >        sector. Windows XP even do not update boot sector, so label
> > >        stored in boot sector is incorrect after any change done by
> > >        Windows XP.
> > > 
> > >        This logic is used by all tested MS-DOS and Windows versions,
> > >        plus also by mtools on Linux.
> > > 
> > > 2. Write label to to both location, boot sector and root directory.
> > > 
> > >    --> Reason: MS-DOS 6.22, MS-DOS 7.10, Windows 98 and also mtools on
> > >        Linux do this. This is also what is written in FAT specification.
> > > 
> > >        It also provides backward compatibility with old dosfslabel
> > >        versions which read label only from boot sector.
> > > 
> > > 2. Process 'NO NAME    ' label in root directory as 'NO NAME' name. Not
> > >    as empty label.
> > > 
> > >    --> Reason: 'NO NAME    ' is regular entry in root directory and both
> > >        Windows XP and mlabel handle it in this way.
> > > 
> > > 3. Process 'NO NAME    ' label in boot directory as empty label. Not as
> > >    label with name 'NO NAME'.
> > > 
> > >    --> Reason: On Windows XP when formatting empty disk and label is not
> > >        specified then 'NO NAME    ' is stored to boot sector.
> > > 
> > >        Also in FAT specification is written that empty label is stored
> > >        as 'NO NAME    '.
> > > 
> > > With this change we would get compatibility with MS-DOS, Windows (both
> > > DOS-based and NT-based) and also with Linux mtools, modulo problems DOS
> > > code page.
> > > 
> > > There are just two negatives:
> > > 
> > > 1) Labels set by old dosfslabel versions (which stored them only to boot
> > >    sector) would not be visible. But they are already not visible on
> > >    MS-DOS or Windows machines, and also via mlabel (from mtools).
> > > 
> > > 2) Behavior of blkid and fatlabel would be changed as both tools have
> > >    different as proposed above, and based on tests they also differ each
> > >    from other.
> > > 
> > > Andreas, Karel, what do you think about it?
> > 
> > Also for other people, do any have comments on my proposed solution?
> 
> Go ahead and send patch :-) (also with LABEL_FATBOOT=)

Now I implemented changes for dosfstools project, pull request is there:
https://github.com/dosfstools/dosfstools/pull/73

Just waiting for the Andreas response...

Andy, you wanted some manpage update. I did it in this commit:
https://github.com/dosfstools/dosfstools/pull/73/commits/3f4f122b7ec8eeb4a0ae0db8e94b8829f51d1163
Can you check if changes in manpage are OK?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Pali Rohár]

On Thursday 09 November 2017 22:21:31 Pali Rohár wrote:
> So from all tests and discussion I would propose new unification:
> 
> 1. Read label only from the root directory. If label in root directory
>    is missing then disk would be treated as without label. Label from
>    boot sector would not be read.
> 
>    --> Reason: Windows XP and mlabel ignores what is written in boot
>        sector. Windows XP even do not update boot sector, so label
>        stored in boot sector is incorrect after any change done by
>        Windows XP.
> 
>        This logic is used by all tested MS-DOS and Windows versions,
>        plus also by mtools on Linux.
> 
> 2. Write label to to both location, boot sector and root directory.
> 
>    --> Reason: MS-DOS 6.22, MS-DOS 7.10, Windows 98 and also mtools on
>        Linux do this. This is also what is written in FAT specification.
> 
>        It also provides backward compatibility with old dosfslabel
>        versions which read label only from boot sector.
> 
> 2. Process 'NO NAME    ' label in root directory as 'NO NAME' name. Not
>    as empty label.
> 
>    --> Reason: 'NO NAME    ' is regular entry in root directory and both
>        Windows XP and mlabel handle it in this way.
> 
> 3. Process 'NO NAME    ' label in boot directory as empty label. Not as
>    label with name 'NO NAME'.
> 
>    --> Reason: On Windows XP when formatting empty disk and label is not
>        specified then 'NO NAME    ' is stored to boot sector.
> 
>        Also in FAT specification is written that empty label is stored
>        as 'NO NAME    '.
> 
> With this change we would get compatibility with MS-DOS, Windows (both
> DOS-based and NT-based) and also with Linux mtools, modulo problems DOS
> code page.
> 
> There are just two negatives:
> 
> 1) Labels set by old dosfslabel versions (which stored them only to boot
>    sector) would not be visible. But they are already not visible on
>    MS-DOS or Windows machines, and also via mlabel (from mtools).
> 
> 2) Behavior of blkid and fatlabel would be changed as both tools have
>    different as proposed above, and based on tests they also differ each
>    from other.
> 
> Andreas, Karel, what do you think about it?

Andreas, any comments? It is OK?

More then month passed... and I would like to move forward.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Linux & FAT32 label

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 3735 bytes --]

On Thursday 30 November 2017 00:21:26 Pali Rohár wrote:
> On Monday 20 November 2017 12:12:56 Karel Zak wrote:
> > On Sun, Nov 19, 2017 at 01:44:40PM +0100, Pali Rohár wrote:
> > > On Thursday 09 November 2017 22:21:31 Pali Rohár wrote:
> > > > So from all tests and discussion I would propose new unification:
> > > > 
> > > > 1. Read label only from the root directory. If label in root directory
> > > >    is missing then disk would be treated as without label. Label from
> > > >    boot sector would not be read.
> > > > 
> > > >    --> Reason: Windows XP and mlabel ignores what is written in boot
> > > >        sector. Windows XP even do not update boot sector, so label
> > > >        stored in boot sector is incorrect after any change done by
> > > >        Windows XP.
> > > > 
> > > >        This logic is used by all tested MS-DOS and Windows versions,
> > > >        plus also by mtools on Linux.
> > > > 
> > > > 2. Write label to to both location, boot sector and root directory.
> > > > 
> > > >    --> Reason: MS-DOS 6.22, MS-DOS 7.10, Windows 98 and also mtools on
> > > >        Linux do this. This is also what is written in FAT specification.
> > > > 
> > > >        It also provides backward compatibility with old dosfslabel
> > > >        versions which read label only from boot sector.
> > > > 
> > > > 2. Process 'NO NAME    ' label in root directory as 'NO NAME' name. Not
> > > >    as empty label.
> > > > 
> > > >    --> Reason: 'NO NAME    ' is regular entry in root directory and both
> > > >        Windows XP and mlabel handle it in this way.
> > > > 
> > > > 3. Process 'NO NAME    ' label in boot directory as empty label. Not as
> > > >    label with name 'NO NAME'.
> > > > 
> > > >    --> Reason: On Windows XP when formatting empty disk and label is not
> > > >        specified then 'NO NAME    ' is stored to boot sector.
> > > > 
> > > >        Also in FAT specification is written that empty label is stored
> > > >        as 'NO NAME    '.
> > > > 
> > > > With this change we would get compatibility with MS-DOS, Windows (both
> > > > DOS-based and NT-based) and also with Linux mtools, modulo problems DOS
> > > > code page.
> > > > 
> > > > There are just two negatives:
> > > > 
> > > > 1) Labels set by old dosfslabel versions (which stored them only to boot
> > > >    sector) would not be visible. But they are already not visible on
> > > >    MS-DOS or Windows machines, and also via mlabel (from mtools).
> > > > 
> > > > 2) Behavior of blkid and fatlabel would be changed as both tools have
> > > >    different as proposed above, and based on tests they also differ each
> > > >    from other.
> > > > 
> > > > Andreas, Karel, what do you think about it?
> > > 
> > > Also for other people, do any have comments on my proposed solution?
> > 
> > Go ahead and send patch :-) (also with LABEL_FATBOOT=)
> 
> Now I implemented changes for dosfstools project, pull request is there:
> https://github.com/dosfstools/dosfstools/pull/73
> 
> Just waiting for the Andreas response...

Seems... there is no activity since October in dosfstools github project.

Andreas, I have no response from you, are OK?

Just I would like to know if you are interested in changes and if I
should prepare another patches for dosfstools. I just do not want to go
coding and implement something which will be rejected...

> Andy, you wanted some manpage update. I did it in this commit:
> https://github.com/dosfstools/dosfstools/pull/73/commits/3f4f122b7ec8eeb4a0ae0db8e94b8829f51d1163
> Can you check if changes in manpage are OK?

Andy, can you check that manpage update?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Linux & FAT32 label

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

On Monday 27 November 2017 13:13:01 Karel Zak wrote:
> On Sun, Nov 26, 2017 at 08:19:25PM +0100, Pali Rohár wrote:
> > On Monday 20 November 2017 12:12:56 Karel Zak wrote:
> > > Go ahead and send patch :-) (also with LABEL_FATBOOT=)
> > 
> > Ok, I prepared patches for util-linux including LABEL_FATBOOT:
> > https://github.com/karelzak/util-linux/compare/master...pali:master
> 
> Seems good. I'll wait for official pull request. Thanks!
> 
> > I have not created official pull request on github yet as Andreas have
> > not decided yet about dosfstools/fatlabel...
> 
> OK.

Looks like that Andreas is not responding to mailing list, nor to
private emails, nor on github for 3-4 months ... I hope he is OK.

But I do not know what happened with dosfstools project now in this
case, if it is going to be fixed or not.

I have prepared more patches for dosfstools project, but do not know if
I should open new pull requests or wait (how long?) or do something
else.

If it helps for somebody, I can create fork of dosfstools project and
include there all changes which I have prepared.

Any opinion? What other people think about this situation right now?

Karel, do you want to create official pull request for above util-linux
changes, even without fixes in dosfstools project?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Linux & FAT32 label

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

On Wednesday 14 February 2018 22:52:33 Pali Rohár wrote:
> On Monday 27 November 2017 13:13:01 Karel Zak wrote:
> > On Sun, Nov 26, 2017 at 08:19:25PM +0100, Pali Rohár wrote:
> > > On Monday 20 November 2017 12:12:56 Karel Zak wrote:
> > > > Go ahead and send patch :-) (also with LABEL_FATBOOT=)
> > > 
> > > Ok, I prepared patches for util-linux including LABEL_FATBOOT:
> > > https://github.com/karelzak/util-linux/compare/master...pali:master
> > 
> > Seems good. I'll wait for official pull request. Thanks!
> > 
> > > I have not created official pull request on github yet as Andreas have
> > > not decided yet about dosfstools/fatlabel...
> > 
> > OK.
> 
> Looks like that Andreas is not responding to mailing list, nor to
> private emails, nor on github for 3-4 months ... I hope he is OK.
> 
> But I do not know what happened with dosfstools project now in this
> case, if it is going to be fixed or not.
> 
> I have prepared more patches for dosfstools project, but do not know if
> I should open new pull requests or wait (how long?) or do something
> else.
> 
> If it helps for somebody, I can create fork of dosfstools project and
> include there all changes which I have prepared.
> 
> Any opinion? What other people think about this situation right now?
> 
> Karel, do you want to create official pull request for above util-linux
> changes, even without fixes in dosfstools project?

CC linux-fsdevel@vger.kernel.org as there can be other people interested
in FAT & dosfstools...

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Linux & FAT32 label

[Karel Zak]

On Wed, Feb 14, 2018 at 10:54:30PM +0100, Pali Rohár wrote:
> On Wednesday 14 February 2018 22:52:33 Pali Rohár wrote:
> > On Monday 27 November 2017 13:13:01 Karel Zak wrote:
> > > On Sun, Nov 26, 2017 at 08:19:25PM +0100, Pali Rohár wrote:
> > > > On Monday 20 November 2017 12:12:56 Karel Zak wrote:
> > > > > Go ahead and send patch :-) (also with LABEL_FATBOOT=)
> > > > 
> > > > Ok, I prepared patches for util-linux including LABEL_FATBOOT:
> > > > https://github.com/karelzak/util-linux/compare/master...pali:master
> > > 
> > > Seems good. I'll wait for official pull request. Thanks!
> > > 
> > > > I have not created official pull request on github yet as Andreas have
> > > > not decided yet about dosfstools/fatlabel...
> > > 
> > > OK.
> > 
> > Looks like that Andreas is not responding to mailing list, nor to
> > private emails, nor on github for 3-4 months ... I hope he is OK.
> > 
> > But I do not know what happened with dosfstools project now in this
> > case, if it is going to be fixed or not.
> > 
> > I have prepared more patches for dosfstools project, but do not know if
> > I should open new pull requests or wait (how long?) or do something
> > else.
> > 
> > If it helps for somebody, I can create fork of dosfstools project and
> > include there all changes which I have prepared.

I think fork is possible way if you (or someone else) want to maintain
dosfstools. 

Please, try to talk about the current situation with downstream
dosfstools maintainers from Debian, Suse, Fedora/RHEL, Gentoo, ...

It's always good to have support from distros before you fork anything. 
Nobody wants to use unmaintained stuff in distros so I guess you will see
positive feedback.

> > Karel, do you want to create official pull request for above util-linux
> > changes, even without fixes in dosfstools project?

I have no problem with the pull request, but if you want to try to
fork dosfstools I can wait for any conclusion. 

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: Linux & FAT32 label

[Pali Rohár]

On Monday 27 November 2017 13:13:01 Karel Zak wrote:
> On Sun, Nov 26, 2017 at 08:19:25PM +0100, Pali Rohár wrote:
> > On Monday 20 November 2017 12:12:56 Karel Zak wrote:
> > > Go ahead and send patch :-) (also with LABEL_FATBOOT=)
> > 
> > Ok, I prepared patches for util-linux including LABEL_FATBOOT:
> > https://github.com/karelzak/util-linux/compare/master...pali:master
> 
> Seems good. I'll wait for official pull request. Thanks!
> 
> > I have not created official pull request on github yet as Andreas have
> > not decided yet about dosfstools/fatlabel...
> 
> OK.

Andreas now accepted this change into dosfstools project so I created
official pull request: https://github.com/karelzak/util-linux/pull/586

-- 
Pali Rohár
pali.rohar@gmail.com