On Fri, 03 Feb 2006 10:07:11 -0600, Dave Kleikamp wrote:
>On Wed, 2006-02-01 at 20:04 +0100, Ingo wrote:
>> I got an annoying problem with accessing files on a JFS partitition:
>> Partitition was created under OS/2's JFS and also filled with data under OS/2.
>> I have tested since long the compatibility of a JFS filesystem with OS/2 and Linux:
>> Linux does not touch the EA's (extended attributes) created by OS/2
>> OS/2 does not touch UID and GID and access rights created by Linux.
>> So achtually all should be fine - and I never lost any data, but:
>> When I mount such a partitition under Linux, all the files written by OS/2 do
>> not have any acces rights assigned and the owner is 'root' and group is 'root'.
>> I have placed the mount-options in FSTAB for /dev/hda11 this way:
>> this does allow the mounting and umounting by me working as a 'user',
>> but I do not have any rights to access the files (those with no attributes).
>> The only way is to open a root-terminal and issue
>> chmod -R 777 <mountpoint>
>> chown -R ingo <mountpoint>
>> (<mountpoint> is the directory where the partitition is mounted to, ingo is
>> my user name).
>> This information is then written to the filesystem and becomes persistant.
>> But whenever I add a new file under OS/2, I first have to become root and
>> assigne the rights as above.
>> Unfortunately Linux-JFS does not accept the mount-options
>> uid, gid, umask=... added in the FSTAB, so it is very inconveniant to
>> exchange files between the two operating systems.
>> Does anybody know how to solve this dilemma - seems to be Linux-related?
>I've considered implementing the uid, gid and umask parameters in the
>past, but to be honest, there really hasn't been anybody complaining
>that they are missing. I don't think there are very many users out
>there actually switching between linux & os/2. The chmod workaround is
>probably sufficient for most users.
>If I were to implement uid, gid & umask, would it make sense to only
>replace use these values when uid = gid = permissions = 0, or should it
>override them no matter what is stored in the inode?
My proposal would be a similar beheaviour as for FAT, HPFS, ... and other
filesystems which 'do not support the Linuxx permission bits'. I read the following
in the man page mount(8):
Mount options for hpfs
uid=value and gid=value
Set the owner and group of all files. (Default: the uid and gid of the current process.)
Set the umask (the bitmask of the permissions that are not present). The default is the umask of the current process.
The value is given in octal.
case=lower / case=asis .....
If I do understand that information correct, the options uid=, gid= and umask= do not really write
those information to the filesystem (so they do not survive a reboot), but rather
'fake' the kernel or whatever by reporting the values assigned by the options to the system.
In case of JFS it is somewhat more complex, as JFS supports the permission-bits
and stores them in the inodes (if running under Linux). OS/2 definitely does not touch them!
The most convenient beheaviour would be:
1. if uid, gid, umask is not given all remains as it is - the normal Linux operating.
2. if uid, gid, umask is given in FSTAB or during MOUNT we have two cases:
a) reading the file system: uid, gid, umask define the permission
overruling all information stored in the inodes, but not changing it
(also if nothing stored like when data was written by OS/2)
b) writing to the file system: 2 possibilities exist
1. writing no permission information to the file system/inodes
I guess this is the easiest to implement and will do.
2. writing the permissions defined by uid, gid umask to the file sytem
(this will result in a vast mixture of files, with and without attributes,
so probably b1 is the better choice.
>Would you be interested in testing a kernel patch? If so, what level of
>kernel are you running?
I would like to try a kernel patch, but I am not yet very skilled with Linux, so some
guidence would be helpfull. Do I have to rebuild the whole kernel and modules,
or just apply a differential patch - that is definitely no problem
(i.e. like the SUSE online-update or the Vmware-any-any patch)?
My system is SUSE 10.0 Professional (Novell),
Kernel is 2.6.13-15.7
jfsutils are 1.1.8-3
>> Best regards,
>IBM Linux Technology Center
Many thanks for your prompt support,