GNU bug report logs - #10471
Severe or critical - deletes existing files and leaves nothing. (cp)

Previous Next

Full log

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

From: "L. A. Walsh" <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bug-coreutils <at> gnu.org, 10471 <at> debbugs.gnu.org
Subject: Re: bug#10471: Severe or critical - deletes existing files and leaves
 nothing. (cp)
Date: Thu, 09 Apr 2015 15:17:24 -0700

Paul Eggert wrote:
> L. A. Walsh wrote:
>> I was wondering if the changes to 'mv' might also have fixed this
>> (10468/10471) bug.
> 
> Haven't a clue.  Why don't you try the bleeding-edge version of 
> coreutils and see?  Presumably you have the oddball file system in 
> question available, and can easily try it out.  (I don't have it, and I 
> don't expect other maintainers to have it either.)
----

How was the bug with 'mv' fixed? -- it mentions duplicating it on 
on HFS (MacOS) that also has a case insensitive option.  
Specifically, a "mv file File" (where both were hard linked) the
mv operation would result in 'file' being removed.

As far as developers not having access to HFS(I seem to remember reading
that case insensitivity was the default now on MacOS), Solaris or BSD(ZFS-- don't
know its default status), Windows(NTFS - is default), Linux(xfs -- not
a default config) -- what OS's do developers work with?

Seems like it is reproducible on MacOS, linux, Solaris and Windows --
but was closed out because the claim was such file systems were "oddball"
but HFS, NTFS are default FS's, and ZFS and XFS don't seem that
rare on Solaris, BSD or linux... 

In my case, instead of 'mv', it was a 'cp' w/ -a or --preserve-hardlinks
that triggered the problem, _including_ in the presence of "-u" (which
I thought should have been non-destructive (i.e. not deleting linked
files if only 1 of the names on the source was 'newer' (and not hardlinked)).

Seems like "race" conditions w/hardlinked files (especially on
case-ignoring filesystems) and/or w/update look like they haven't
really been strongly thought out.

My issue here is that I reported the problem 3 years ago and it
got ignored because some thought it was windows+cygwin+NTFS only,
(even though at the time I pointed out it could be dupped on linux
w/xfs).  But the bug still got ignored -- where as now it is
being seen on HFS (and can likely be seen on ZFS from what (I've
been told).  

Given the number of file systems and OS's the behavior can be
reproduced on -- are you still claiming all of those OS's+FS's
are the "oddball case" -- they seem to be growing (i.e. case
ins.  was added to HFS and ZFS) since I first found the problem
on NTFS and claimed it also applied to XFS.

I will easily accept that resources are such that it is a 
low priority (as I said 3 years ago), but it is a bit galling
to have removal of needed features from 'rm' taking precedence
over data-loss cases.

Previous Next

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