[lkml]   [2006]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] UDF filesystem uid fix
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-02-14 16:58    [W:0.070 / U:0.904 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site