Pádraig Brady writes:
> On 01/31/2013 07:06 PM, j...@dockes.org wrote:
> >
> > When moving a file having extended attributes to a target filesystem which
> > does not support them (e.g. an NFS mount), the attributes are silently
> > lost.
> >
> > I think that mv should not complete the move in this case, as the current
> > behaviour leads to silent and unexpected data loss.
> >
> > Ideally, this behaviour should be controlled by an option, but I think that
> > the default should be to refuse to lose data.
> >
> > mv version: mv (GNU coreutils) 8.13
> > Checked on Ubuntu 12.04 (probably not relevant).
>
> The previous discussion on that was at:
> http://lists.gnu.org/archive/html/bug-coreutils/2009-04/threads.html#00174
> and the corresponding diagnostics supression patch at:
> http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=941bd48
>
> I'm inclined to agree there should be some diagnostics.
> Perhaps we could output diagnostics as normal, but only
> try the operation once that gives ENOTSUP?
>
> thanks,
> Pádraig.
Hi,
I should have guessed that this was not the first time this came up, but I
could not find another bug report.
Here is what I think in a bit more detail: extended attributes could be
very useful, but people won't use them as long as commands treat them as
discardable data. They are as precious as main file data (think tagging for
example, a lot of effort).
In my opinion the default for 'mv' should be to not complete the operation
if it would lose data from the source:
- This is consistent with 'dangerous' uses of 'mv' which may sometimes
clobber the target but *never* lose the source.
- This is just plain common sense, as most people are not aware of
subtle filesystem differences, and, for example, will mostly not know
that NFS does not support extended attributes. You should not have to
be a filesystem expert to use the command line safely.
Completing the move and printing an error message is just adding insult
to injury: the data is gone and the message indicates that 'mv' should
have known not to do it but did it anyway ! 'cp' does not present the same
issue as as the original is still there.
If there is a strong reason not to implement this behaviour (I can only
imagine some POSIXy compliance issue), there should at the very least exist
a non-default option for 'mv' to behave in this way, like -i will prevent
clobbering a target. One possibility would be to overload -i (not an
optimal approach). People could then alias the option into their common
usage or not.
I would prefer the first approach, with -f to force the move for example.
I should add for the record that I have been using a command line since
1986 (Unix v7). This current behaviour in 'mv' hurts both my rationality
and a sense of style which had some time to form...
Regards,
Jean-François Dockès
