Hi! [ Please CC: me, I'm not subscribed. Yet. ] The problem have beaten me before. And now I have it again. Imaging external hard drive with "proper" file system (proper == supports posix permissions) where files were created by user A and then it (ext. hard drive) was brought to another location/computer and user B tried to read them. Failure. Why? Because Linux preserved permissions on hard drive - though they are already irrelevant on system fs is currently mounted on. And that renders literally all files accessible only by root. What is needed is special mount option to tell file system (*): (1) to ignore permissions when file/directory is read; (2) when file/directory is created it receives automatically "world writable" permissions 0666 (I cannot imaging how to simulate "user friendly" file attribute "read-only", though it seems not relevant to external storage anyway). I'm looking into the code and it seems that every file system parses option on their own. Global flags (ro/rw, nodev, etc) are handled by mount(8) itself and passed to sys_mount() as bitmask. How gid/uid are passed to file system? I do not see them in parameter list to sys_mount(). Or they are handled somehow otherwise? Any ideas on how I can simulate such behavior and or on how to implement such attribute would be appreciated. P.S. chmod/chown isn't option since (1) they do not work for ro file system and (2) doing that every time on NNNk files might quite tiresome - every time disk is reattached. P.P.S. BTW MacOSX has such option and it is automatically selected for external hard drives. P.P.P.S. That doesn't happen with most external hard drives since they are all FAT32. I moved to ext2/hfs+ in part to avoid the recurring nightmares of past when I have worked with FAT32 all day long. And also ext2/hfs+ (under Linux/MacOSX) are better than FAT*. And also I need "case sensitiveness". -- Don't walk behind me, I may not lead. Don't walk in front of me, I may not follow. Just walk beside me and be my friend. -- Albert Camus (attributed to) - 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
