GNU bug report logs - #13601
mv should not silently lose file extended attributes

Previous Next

To reply to this bug, email your comments to 13601 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: jf <at> dockes.org
To: <bug-coreutils <at> gnu.org>
Subject: mv should not silently lose file extended attributes
Date: Thu, 31 Jan 2013 20:06:30 +0100

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).

Regards,

J.F. Dockès

Message #8 received at 13601 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: jf <at> dockes.org
Cc: 13601 <at> debbugs.gnu.org
Subject: Re: bug#13601: mv should not silently lose file extended attributes
Date: Fri, 01 Feb 2013 00:25:52 +0000

On 01/31/2013 07:06 PM, jf <at> 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.

Message #11 received at 13601 <at> debbugs.gnu.org (full text, mbox):

From: jf <at> dockes.org
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 13601 <at> debbugs.gnu.org
Subject: Re: bug#13601: mv should not silently lose file extended attributes
Date: Fri, 1 Feb 2013 07:59:24 +0100

Pádraig Brady writes:
 > On 01/31/2013 07:06 PM, jf <at> 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

Message #16 received at 13601 <at> debbugs.gnu.org (full text, mbox):

From: Joshua Krämer <joshua.kraemer <at> gmail.com>
To: 13601 <at> debbugs.gnu.org
Subject: bug#13601
Date: Sun, 21 Feb 2021 17:45:32 +0100

I second this request. 'mv' should really not move files if this
results in silent data loss. The proposal of requiring '-f' in such a
case seems reasonable to me.

Kind regards,
Joshua Krämer

Message #19 received at 13601 <at> debbugs.gnu.org (full text, mbox):

From: "Abraham S.A.H." <arash.sah <at> tuta.io>
To: 13601 <13601 <at> debbugs.gnu.org>
Subject: Re: bug#13601: mv should not silently lose file extended attributes
Date: Mon, 11 Dec 2023 21:03:19 +0100 (CET)

Seriously?
How many years have to pass so that we can have a sane default behaviour regarding extended attributes in mv and others?
Do you consider it as a Wishlist bug? Like, if most people don't use extended attributes now, it is just because there is enough risk to lose their precious data if they use extended attributes. A significantly useful feature of filesystems is not used by users just because userspace commands and tools are not supporting them properly.

As far as they don't support and perserve extended attributes properly, this feature does not practically exist! Better say there is no user-xattr in gnu/linux at the moment.
Blessings...--
Best Regards,
Abraham
Sent with Tutanota; https://tuta.com

Message #22 received at 13601 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "Abraham S.A.H." <arash.sah <at> tuta.io>, 13601 <13601 <at> debbugs.gnu.org>
Subject: Re: bug#13601: mv should not silently lose file extended attributes
Date: Mon, 11 Dec 2023 14:38:56 -0800

On 12/11/23 12:03, Abraham S.A.H. via GNU coreutils Bug Reports wrote:
> a sane default behaviour regarding extended attributes in mv and others?

What's wrong with the default behavior in current GNU mv? Please give a 
specific example (specify platform, filesystems, mv version, etc.).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.