Received: by 10.223.164.202 with SMTP id h10csp3674687wrb; Mon, 20 Nov 2017 03:14:26 -0800 (PST) X-Google-Smtp-Source: AGs4zMYlzWhhPobjIkDzV5hESbM51RbnCcYY4KV48S6Rh9fCLhg54YJlU8Td4moryFMhiyWIX7fU X-Received: by 10.84.132.42 with SMTP id 39mr13380978ple.382.1511176466085; Mon, 20 Nov 2017 03:14:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511176466; cv=none; d=google.com; s=arc-20160816; b=Ct4zobsjMIEHvtLkU+8q3HW3lE8D9GdN3sklMWfT1fEKN3LiUM51EHW1OY9ayGP0wF UP2XS1axH8DMEKPU9NFRtU3ObWCQP49+xnC8ZfID6rM/Sio0mwVrf7yWuCm1Ogd45IMp zv8dQBQgTYb7NbgfPdBAJwZbv8gLn3UM5SDDKs69H3NOpmB9NVKcTHMIDY/JvPfinGii vtXie1WaGSXD45arHi22AMh5FbCmKc8oKWwy3cxx4njSp0HIHoHSugNRjG8L4acbvWBF emMUb+/6knSk4T0F0AXtPVQY2TI0XeW3ZDuh1QrQPC+7o+9ufIllbyWPNtq3CwSPZgc7 B9yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=R/Noog1oqSTj6aICW8sNMGBCoS53JvRy11yKkVw1NvM=; b=W6eusmjcU6sw6JQq63Olai8MWlEhAVJwp1iPFcIVPS1X9/brrWHE/eWYgqJED/eMKt OOxXsU7gKudX8E8ciBrV8tPULa+DJsEoP8fW+bTK3dhhY6dRRqLKgpZ8Vwx+z3gQMBYd e9KMFDXevz8RSOklCaKtnGr9N0S8Zzy8LRF++aTzlz+L40tMMhJT61enWucFaGf45Nnm VpKfVy9s6OEVvPsVC5AbmcE5kpWFWzRrXJ7Ki9DBuF5YT+nAvy3a1GqtvrguLSQYnaHv akYou9CM7QjtOsRYxYJZn56zQJRPvr/pd+yXs6kz/tgX5whJdBrYMqLuFoWUOWWF/f1c hVGA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o4si7845100pgf.8.2017.11.20.03.14.15; Mon, 20 Nov 2017 03:14:26 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751155AbdKTLNE (ORCPT + 68 others); Mon, 20 Nov 2017 06:13:04 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44000 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751109AbdKTLNB (ORCPT ); Mon, 20 Nov 2017 06:13:01 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5351D68419; Mon, 20 Nov 2017 11:13:01 +0000 (UTC) Received: from ws.net.home (ovpn-117-195.ams2.redhat.com [10.36.117.195]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 582446BF9B; Mon, 20 Nov 2017 11:12:59 +0000 (UTC) Date: Mon, 20 Nov 2017 12:12:56 +0100 From: Karel Zak To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Andreas Bombe , util-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Andrius =?utf-8?B?xaB0aWtvbmFz?= , Curtis Gedak , Andy Shevchenko , Pavel Machek Subject: Re: Linux & FAT32 label Message-ID: <20171120111256.zqvmpzdcf6ncyi5m@ws.net.home> References: <20171004153332.GA6696@pali> <20171011212435.znmtdnsxcd5ectub@pali> <20171105130608.5oww3b2fnnrwe7ok@pali> <20171109212131.uxraxzwpvrlyfyys@pali> <20171119124440.ffxx64zjmwedmtdp@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171119124440.ffxx64zjmwedmtdp@pali> User-Agent: NeoMutt/20170912-66-504cd9 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 20 Nov 2017 11:13:01 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Nov 19, 2017 at 01:44:40PM +0100, Pali Roh�r wrote: > On Thursday 09 November 2017 22:21:31 Pali Roh�r wrote: > > So from all tests and discussion I would propose new unification: > > > > 1. Read label only from the root directory. If label in root directory > > is missing then disk would be treated as without label. Label from > > boot sector would not be read. > > > > --> Reason: Windows XP and mlabel ignores what is written in boot > > sector. Windows XP even do not update boot sector, so label > > stored in boot sector is incorrect after any change done by > > Windows XP. > > > > This logic is used by all tested MS-DOS and Windows versions, > > plus also by mtools on Linux. > > > > 2. Write label to to both location, boot sector and root directory. > > > > --> Reason: MS-DOS 6.22, MS-DOS 7.10, Windows 98 and also mtools on > > Linux do this. This is also what is written in FAT specification. > > > > It also provides backward compatibility with old dosfslabel > > versions which read label only from boot sector. > > > > 2. Process 'NO NAME ' label in root directory as 'NO NAME' name. Not > > as empty label. > > > > --> Reason: 'NO NAME ' is regular entry in root directory and both > > Windows XP and mlabel handle it in this way. > > > > 3. Process 'NO NAME ' label in boot directory as empty label. Not as > > label with name 'NO NAME'. > > > > --> Reason: On Windows XP when formatting empty disk and label is not > > specified then 'NO NAME ' is stored to boot sector. > > > > Also in FAT specification is written that empty label is stored > > as 'NO NAME '. > > > > With this change we would get compatibility with MS-DOS, Windows (both > > DOS-based and NT-based) and also with Linux mtools, modulo problems DOS > > code page. > > > > There are just two negatives: > > > > 1) Labels set by old dosfslabel versions (which stored them only to boot > > sector) would not be visible. But they are already not visible on > > MS-DOS or Windows machines, and also via mlabel (from mtools). > > > > 2) Behavior of blkid and fatlabel would be changed as both tools have > > different as proposed above, and based on tests they also differ each > > from other. > > > > Andreas, Karel, what do you think about it? > > Also for other people, do any have comments on my proposed solution? Go ahead and send patch :-) (also with LABEL_FATBOOT=) Karel -- Karel Zak http://karelzak.blogspot.com From 1584498588773332036@xxx Sun Nov 19 12:46:48 +0000 2017 X-GM-THRID: 1580341666501472641 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread