[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