Pekka J Enberg wrote:
I don't haven an UDF partition to test on so I am only reading the code.
With your patch, every time an in-memory inode has the same uid/gid as the
one you passed as mount option, the id on disk will become -1, no? So for
example, doing chown 100 for a file writes -1 to disk if you passed 100
as uid mount option. Am I missing something here?
That is exactly correct.
Yes, I agree that the current code is broken. I was talking about what the
semantics should be and that your patch doesn't quite get us there. Do you
disagree with that? The UDF specification I am looking at [1] says that -1
is used by operating systems that do not support uid/gid to denote an
invalid id (although ECMA-167 doesn't seem to have such rule), which is
why I think it's an bad idea for Linux to ever write it on disk. Instead,
we should always write the proper id on disk unless it was invalid in the
first place and we did not explicity change it (via chown, for example).
Sometimes you DON'T want a valid UID written to the disk. In the case
of a typical desktop user, there is only one uid that is ever going to
access the disk, but that uid may be different on each computer, even
though it's the same person. Thus they want to be able to take the disc
from computer to computer, and have access to their files. Since the
existing uid/gid override mount options only apply if the on disk id is
-1, it seemed a simple and appropriate thing to store -1 in the case
where the id matches the mount option. The only use case that this
patch changes is where the id matches the mount option. In that case,
the user expected behavior is for the files on the disc to appear to be
owned by the specified uid, with the added benefit that this will hold
true if you remount with another uid specified, possibly even on another
machine. This seems to meet user expectations much better than the
previous behavior of changing ownership to root when unmounted.
If you want real IDs to be stored, then do nothing. Simply continue to
use the system just like before, where you did not specify a uid as a
mount option.
-
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]