Re: [PATCH] e2p: fix getflags for link file

[Theodore Ts'o <tytso@mit.edu>]

On Wed, Dec 06, 2017 at 09:19:26AM +0800, Wang Shilong wrote:
> > But this is one of our customers feedback, this is not good that
> > lsattr/chattr did not support symlink, we might need make it
> > clear, for example, we support symlink, but it always follow
> > original files, that is even better than output errors.

What is the basis of the customer's complaint?  I could imagine
printing a more explanatory message.  So instead of:

lsattr: Operation not supported While reading flags on /foo/bar/baz

maybe:

/foo/bar/baz: file attributes not supported for symlinks

It's not clear to me at all that following symlinks is the right
thing.

> >
> > In this way, we need fix chattr too.
> 
> Just to think more, there is a problem to follow symlink for chattr:
> consider following case that users want to use directory quota:
> 
> dir1/dir1.1         --->project ID is 1
> dir2/dir2.link.1.1 ----->dir2's Project ID is 2, link file to dir1.1
> 
> Considering if users do something like:
> #chattr -p 1 -R dir1
> #chattr -p 2 -R dir2/
> 
> This will break some users expected behavior, since dir1.1
> will be set to project ID 2 which expected as 1.
> 
> So i supposed we should disallow follow symlink for chattr?

... and this is why I don't think we should change the behavior for
lsattr *or* chattr.

I could imagine adding an option which causes lsattr and chattr to
follow symlinks (but in the absense of the option, lsattr and chattr
will do what it does today, which is not follow symlinks, possibly
with a friendly error message), or maybe which causes lsattr to print
something like this:

--------------e---- /usr/bin/emacsclient.emacs24
   <symlink>        /usr/bin/emacs -> /etc/alternatives/emacs

... but honestly, is it really worth it?

					- Ted