Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E631D4900F
Date:   Mon, 6 Nov 2017 11:14:44 +0100
From:   Karel Zak <kzak@redhat.com>
To:     Pali =?iso-8859-1?Q?Roh=E1r?= <pali.rohar@gmail.com>
Cc:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        Andreas Bombe <aeb@debian.org>, util-linux@vger.kernel.org,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Andrius =?utf-8?B?xaB0aWtvbmFz?= <andrius@stikonas.eu>,
        Curtis Gedak <gedakc@gmail.com>, Pavel Machek <pavel@ucw.cz>
Subject: Re: Linux & FAT32 label
Message-ID: <20171106101444.m5kxevutsdxx34kl@ws.net.home>
References: <20171012092113.2bsb3pzv6un4xahr@pali>
 <20171012101311.zfvg6edfvszlujom@ws.net.home>
 <20171012204931.tfd2bhmwu5b6rbpz@pali>
 <20171016011243.zurh5jhb2y6mczx7@amos.fritz.box>
 <CAHp75VdWXHtCHiRxnbAidr9inehVC=av6gp7-jtJqN6WPYh4fg@mail.gmail.com>
 <20171105133929.7cscboxymmpkw634@pali>
 <CAHp75VfwLh9eH992nB1TiOVYOpEV6OSTGkbLau=eQRPeczeFyA@mail.gmail.com>
 <20171105140745.ze4ttkazeczrqsy7@pali>
 <CAHp75VfeNj16k_nMmLxVJTWLr=gwFUMXiga6FYmbLb3pvWJxaw@mail.gmail.com>
 <20171105143411.aynz5tr3igobuh6e@pali>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20171105143411.aynz5tr3igobuh6e@pali>
User-Agent: NeoMutt/20170912-66-504cd9
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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

From 1583262287642750632@xxx Sun Nov 05 21:16:19 +0000 2017
X-GM-THRID: 1580341666501472641
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread