From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751826AbdJaIfy (ORCPT ); Tue, 31 Oct 2017 04:35:54 -0400 Received: from mail-qk0-f178.google.com ([209.85.220.178]:54757 "EHLO mail-qk0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750725AbdJaIfu (ORCPT ); Tue, 31 Oct 2017 04:35:50 -0400 X-Google-Smtp-Source: ABhQp+SuVwtE/xWOO4OM7juwI1SIO/3/Krzf0Z39TQak1JLIv1wcp5SYRsOJnEoS0VgQ5v+C9Am1U7DRYHJOqvQDg4M= MIME-Version: 1.0 In-Reply-To: <20171016011243.zurh5jhb2y6mczx7@amos.fritz.box> References: <20171004153332.GA6696@pali> <20171011212435.znmtdnsxcd5ectub@pali> <20171011214426.wa5endlb3kb4yhbv@pali> <20171012085658.iwrusvy4ay4s7hbb@ws.net.home> <20171012092113.2bsb3pzv6un4xahr@pali> <20171012101311.zfvg6edfvszlujom@ws.net.home> <20171012204931.tfd2bhmwu5b6rbpz@pali> <20171016011243.zurh5jhb2y6mczx7@amos.fritz.box> From: Andy Shevchenko Date: Tue, 31 Oct 2017 10:35:48 +0200 Message-ID: Subject: Re: Linux & FAT32 label To: Andreas Bombe Cc: =?UTF-8?Q?Pali_Roh=C3=A1r?= , Karel Zak , util-linux@vger.kernel.org, "linux-kernel@vger.kernel.org" , =?UTF-8?Q?Andrius_=C5=A0tikonas?= , Curtis Gedak Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v9V8a0iX013308 On Mon, Oct 16, 2017 at 4:12 AM, Andreas Bombe 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