[Ocfs2-users] Symbolic Link issues in ocfs
Joel Becker
Joel.Becker at oracle.com
Wed Apr 16 00:04:01 PDT 2008
On Tue, Apr 15, 2008 at 03:59:19PM +1000, Brendan Beveridge wrote:
> if i change the owner of the link using chmod:
> node1:# chown -h user1 /opt/link
> node1:# ls -lah link
> # ls -lah link
> lrwxrwxrwx 1 user1 root 9 2008-04-15 15:35 link -> /opt/file
> and on node2:
> node2:# ls -lah link
> # ls -lah link
> lrwxrwxrwx 1 user1 root 9 2008-04-15 15:35 link -> /opt/file
>
>
> So now i unmount the ocfs parition on node1, then remount it and check
> the file again:
> node1# umount /opt
> node1# mount /opt
> node1# ls -lah /opt/link
> lrwxrwxrwx 1 root root 9 2008-04-15 15:35 /opt/link -> /opt/file
I just checked, and this does indeed happen. My best guess? We
don't provide ->setattr() for symlinks. Most filesystems don't. They
let the regular inode_setattr() handle it, which calls
mark_inode_dirty(). When that dirty inode is written, it hits disk.
I'm guessing that our dirty handling, which is slightly different,
doesn't work here. Mark might have a quick idea, or I'll look more when
I get back from vacation.
> Note that the owner has changed back to root?
> Note that standard files do not have this issue
Out of curiosity, why do you want to do this? Symlinks are
always 777.
Joel
--
"Senator let's be sincere,
As much as you can."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127
More information about the Ocfs2-users
mailing list