Re: [RFC][PATCH] UDF filesystem uid fix

[Pekka J Enberg <penberg@cs.Helsinki.FI>]

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

  1. http://www.osta.org/specs/pdf/udf260.pdf

				Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/