[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.021 / U:154.208 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site