Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932227AbWBMQwL (ORCPT ); Mon, 13 Feb 2006 11:52:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932236AbWBMQwL (ORCPT ); Mon, 13 Feb 2006 11:52:11 -0500 Received: from iriserv.iradimed.com ([69.44.168.233]:5147 "EHLO iradimed.com") by vger.kernel.org with ESMTP id S932227AbWBMQwK (ORCPT ); Mon, 13 Feb 2006 11:52:10 -0500 Message-ID: <43F0B8FC.6020605@cfl.rr.com> Date: Mon, 13 Feb 2006 11:51:08 -0500 From: Phillip Susi User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Pekka Enberg CC: Peter Osterlund , linux-kernel@vger.kernel.org, bfennema@falcon.csc.calpoly.edu, Christoph Hellwig , Al Viro , Andrew Morton Subject: Re: [RFC][PATCH] UDF filesystem uid fix References: <84144f020602130149k72b8ebned89ff5719cdd0c2@mail.gmail.com> In-Reply-To: <84144f020602130149k72b8ebned89ff5719cdd0c2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2006 16:52:58.0543 (UTC) FILETIME=[F1822BF0:01C630BD] X-TM-AS-Product-Ver: SMEX-7.2.0.1122-3.52.1006-14265.000 X-TM-AS-Result: No--17.350000-5.000000-31 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2417 Lines: 48 Pekka Enberg wrote: > The UDF code really seems broken. It fails for new inodes and some > chown cases, when the mount options are being used. Phillip's patch > does not look like a complete fix, though, as it will store invalid > uid/gid (-1) for some cases where we probably should be storing the > real uid/gid. For example, doing chown when the same user is > passed as mount option, we'll get -1 on disk, instead of user's uid. > Could you be more specific about what test cases fail? It worked fine for me so far. Also the storage of -1 id is very much intentional. Prior to this patch, if you mount with uid=yourid then you create a file, it would appear to be owned by you. If you unmounted and remounted the volume however, it would suddenly be owned by root. Clearly that is not acceptable. With this patch applied, the file appears to be owned by you both before and after the remount. The actual value written to disk is -1, which on a read is translated to the value from the mount option, giving the appearance that the file is owned by the user specified in the mount, which is the expected behavior. Should the desktop user insert this media in another machine where they have a different uid ( that is specified in the mount options ) then they would still have access to their files, as the -1 will be translated to the correct uid on that system. Should you chown files to a user other than the one given in the mount option, then that actual uid is stored on the disk. Also if you do not specify a uid/gid when you mount, then the actual uid is stored. > I think the semantics you want is: "if uid/gid is invalid on disk, > leave it that way unless we explicitly change it via chown; otherwise > we can always overwrite it." Hmm? > No, the semantics is if the uid/gid on disk is invalid, then use the id specified in the mount options. That was the case before, however when you created new files or chowned files to you ( and you gave your id in the mount options ), an id of 0 was written to disk instead. Now -1 is written, which when read, is mapped back to your id specified in the mount options. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/