[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VdWXHtCHiRxnbAidr9inehVC=av6gp7-jtJqN6WPYh4fg@mail.gmail.com>
Date: Tue, 31 Oct 2017 10:35:48 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Andreas Bombe <aeb@...ian.org>
Cc: Pali Rohár <pali.rohar@...il.com>,
Karel Zak <kzak@...hat.com>, util-linux@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrius Štikonas <andrius@...konas.eu>,
Curtis Gedak <gedakc@...il.com>
Subject: Re: Linux & FAT32 label
On Mon, Oct 16, 2017 at 4:12 AM, Andreas Bombe <aeb@...ian.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
Powered by blists - more mailing lists