[lkml]   [2006]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] UDF filesystem uid fix
On Mon, 13 Feb 2006, Phillip Susi wrote:
> Could you be more specific about what test cases fail? It worked fine for me
> so far.

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?

On Mon, 13 Feb 2006, Phillip Susi wrote:
> > 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.

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).


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 08:32    [W:0.077 / U:1.768 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site