lkml.org 
[lkml]   [2017]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Linux & FAT32 label
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

\
 
 \ /
  Last update: 2017-11-05 15:27    [W:0.124 / U:1.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site