From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751460AbdKEOvx (ORCPT ); Sun, 5 Nov 2017 09:51:53 -0500 Received: from mail-qt0-f194.google.com ([209.85.216.194]:43831 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750907AbdKEOvv (ORCPT ); Sun, 5 Nov 2017 09:51:51 -0500 X-Google-Smtp-Source: ABhQp+QLda2kV6n37crwogZUyffrmuC+2TO4DEJdliXjt3vysXqdBZX58//E+DP3lm7upT9+KwfXXuaT/ny8+qLY9SE= MIME-Version: 1.0 In-Reply-To: <20171105143411.aynz5tr3igobuh6e@pali> References: <20171012085658.iwrusvy4ay4s7hbb@ws.net.home> <20171012092113.2bsb3pzv6un4xahr@pali> <20171012101311.zfvg6edfvszlujom@ws.net.home> <20171012204931.tfd2bhmwu5b6rbpz@pali> <20171016011243.zurh5jhb2y6mczx7@amos.fritz.box> <20171105133929.7cscboxymmpkw634@pali> <20171105140745.ze4ttkazeczrqsy7@pali> <20171105143411.aynz5tr3igobuh6e@pali> From: Andy Shevchenko Date: Sun, 5 Nov 2017 16:51:49 +0200 Message-ID: Subject: Re: Linux & FAT32 label To: =?UTF-8?Q?Pali_Roh=C3=A1r?= Cc: Andreas Bombe , Karel Zak , util-linux@vger.kernel.org, "linux-kernel@vger.kernel.org" , =?UTF-8?Q?Andrius_=C5=A0tikonas?= , Curtis Gedak , Pavel Machek 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 vA5EpxqD030575 On Sun, Nov 5, 2017 at 4:34 PM, 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 wrote: >> > On Sunday 05 November 2017 15:56:53 Andy Shevchenko wrote: >> >> On Sun, Nov 5, 2017 at 3:39 PM, Pali Rohár 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