Received: by 10.223.164.221 with SMTP id h29csp3181297wrb; Sun, 15 Oct 2017 18:58:37 -0700 (PDT) X-Google-Smtp-Source: AOwi7QA/Ix0fE25wi8DizJKzjI3osuUPr1hCCmctysz7dYpTkfl86KRYiHPV7w/3XzhH4shjTWX1 X-Received: by 10.159.252.203 with SMTP id o11mr7237151pls.293.1508119117395; Sun, 15 Oct 2017 18:58:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1508119117; cv=none; d=google.com; s=arc-20160816; b=S/gAYqAMu2wV6SiHZdeuEG5kjtaYveSkaT5j48qQC32pA0GIS+x+RkjFGdkBYEmiGn 29VkVSU/WW/+wg5CeIzdiKjl7VkvLgejP/3NQ6WFJTETGP7rORppz1jCbP+l0M2OAAlG wxxe6fxfzWmzwi/C9gvykAWkkOgWf1j9KkKjYNrVFFFMphyf71VmmM/aoJuUjVW4EAK5 /s/0Lpqx4ss3B2FmKf+DHpQ2zRiQv8i/b5JfayNYBU8+VwLHV4vnKH6m/myluLc4Te1+ 8VX5FbacYCoNZ4K0PYAGFbBCYifW9ouTxOOy00C6Mm8gSvqBePU/f2T+uJkUbwmrSGDO 1WyA== 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=nPHfIMj8jbvJPbdcKG6jOuTCwqWFgsYKJ7ORlr54doI=; b=VmGpI6Lz51LC2kjRDuOg6HF6MloPVcDLaw7+UvmsTkjkSt4yBcZgTa1ktqkz/dlZAs jLmLT6Xkp+aXCvS7iH++zxonDJFejTBzw/d54cw72oYaghgmuys08mQ8JbLDtc8Exkfs phPsP8G6EGAetLoqH0oyJxDh85roJslG9QVsWUiWjuHbk7JHA0fq3tzbQDAr1GzYGKQj 6xOpHUvOtU/r/J3B+zvAVMm3aBM0fqH2VEejCpd5qV30tegy1cBJIHva4GbMDlwXLDSk EMvTFobXnTm3+BGLKaaCPhAjT3yXzl5qx2/FDWEs7Lya79l9z1h5EvWGc5yf1wqx1hQv vfuA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h11si3436462pgp.611.2017.10.15.18.58.22; Sun, 15 Oct 2017 18:58:37 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751871AbdJPB5v (ORCPT + 99 others); Sun, 15 Oct 2017 21:57:51 -0400 Received: from infernal.debian.net ([83.169.17.123]:54786 "EHLO infernal.debian.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751671AbdJPB5t (ORCPT ); Sun, 15 Oct 2017 21:57:49 -0400 Received: from [2001:a61:318e:9e01:6a05:caff:fe16:d377] (helo=amos) by infernal.debian.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1e3txN-00038r-BE; Mon, 16 Oct 2017 03:12:37 +0200 Received: from andreas by amos with local (Exim 4.89) (envelope-from ) id 1e3txN-0008RX-42; Mon, 16 Oct 2017 03:12:37 +0200 Date: Mon, 16 Oct 2017 03:12:37 +0200 From: Andreas Bombe To: Pali =?iso-8859-1?Q?Roh=E1r?= Cc: Pavel Machek , Karel Zak , util-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Andrius =?iso-8859-15?Q?=A6tikonas?= , Curtis Gedak Subject: Re: Linux & FAT32 label Message-ID: <20171016011237.ropo5l6cpewrymd6@amos.fritz.box> References: <20171004153332.GA6696@pali> <20171011212435.znmtdnsxcd5ectub@pali> <20171011214426.wa5endlb3kb4yhbv@pali> <20171015065901.GD3916@xo-6d-61-c0.localdomain> <20171015220450.gsuwec2auekkqr52@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171015220450.gsuwec2auekkqr52@pali> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 16, 2017 at 12:04:50AM +0200, Pali Roh�r wrote: > On Sunday 15 October 2017 08:59:01 Pavel Machek wrote: > > Hi! > > > > > Based on results I would propose following unification: > > > > > ... > > > 4. Prefer label from the root directory. If there is none entry (means > > > there is also no erased entry), then read label from root sector. > > > > > > --> 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. > > > > > > But due to compatibility with older dosfslabel, which stores > > > label only to boot sector, there is need for some fallback. Due > > > to point 1. the best seems to be to process also erased label in > > > root directory (marked with leading 0xE5) and fallback to boot > > > sector only in case label in root directory is missing. > > > > > > What do you think about it? > > > > 4. seems dangerous. Assume we have "OLD" in boot sector and "0xe5-EW" in the directory > > entry. The label will change from to "OLD" when the directory entry is reused by > > "FOO.TXT", right? That seems surprising / dangerous. > > Hm... that is a good question what happen (I do not know). I think that > current situation when Windows XP show different label as Linux is also > _surprising_. > > Do you have a better idea what to do and how to handle this situation? I have been saying this, a deleted directory entry has no valid contents and its existence should not be considered meaningful. A Windows formatted FAT filesystem without label will have no root directory label entry and if an existing label is deleted, that deleted entry can be overwritten at any time. "Ignoring the presence of boot sector labels" is the only thing I see for practical Windows compatibility. From 1581362845528080090@xxx Sun Oct 15 22:05:30 +0000 2017 X-GM-THRID: 1580341666501472641 X-Gmail-Labels: Inbox,Category Forums