Andreas Dilger wrote: > [...] > A more "obvious" solution would be to just have the filesystem mounted > with this option to make ALL files appear to be owned by the UID specified > to the "uid=${localuid}", which would at least more closely match the > behaviour of the fat/vfat filesystems with the uid= option. Well, I don't mind. The change to have it that way is trivial. > New files > could be created using the local UID with no more effort than creating > them with uid=0, but there would be less surprise on another system if > files don't magically appear as owned by root. Sure, the disadvantage is that by using the local id the fs might aggregate many different uids over time which looks weird on a legacy system though. > My further suggestion was that if it is possible to optionally specify > the remote UID then at least one side does not have to have this patch > in order to mount and use the filesystem. Hence, my suggestion to have > "uid={localuid}[={diskuid}]". The [={diskuid}] part could be optional, > and doesn't add any significant complication to the patch, AFAICS. > Initialize the diskuid = localuid, and if the additional diskuid is given > use that instead, for all inodes written to the disk. Hmm, ok. Could be used to have all files root owned too. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html