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 <user> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
