GNU bug report logs -
#14852
Fwd: mv fails when trying to overwrite a file in a (map) network drive
Previous Next
Reported by: Lluis faixó <lluis.faixo <at> gmail.com>
Date: Fri, 12 Jul 2013 16:19:02 UTC
Severity: normal
Tags: notabug
Done: Assaf Gordon <assafgordon <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14852 in the body.
You can then email your comments to 14852 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#14852
; Package
coreutils
.
(Fri, 12 Jul 2013 16:19:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Lluis faixó <lluis.faixo <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Fri, 12 Jul 2013 16:19:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Forgot to say I'm using minGw with Msys latest version:
mingw-get-inst-20120426
Sorry about that
---------- Forwarded message ----------
From: Lluis faixó <lluis.faixo <at> gmail.com>
Date: 2013/7/12
Subject: mv fails when trying to overwrite a file in a (map) network drive
To: bug-coreutils <at> gnu.org
If I am working in my harddisk I can move and overwrite files.
I'm working on Windows XP I have a network drive (Y:\)
file1 exists
file2 exists
if I try:
mv -f file1 file2
It complains:
mv: cannot move `file1' to `file2': File exists
Hope the explanation is good enough.
Cheers,
Lluis
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#14852
; Package
coreutils
.
(Wed, 24 Jul 2013 04:22:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 14852 <at> debbugs.gnu.org (full text, mbox):
Lluis faixó wrote:
> Forgot to say I'm using minGw with Msys latest version:
> mingw-get-inst-20120426
>
> Sorry about that
>
>
> ---------- Forwarded message ----------
> From: Lluis faix� <lluis.faixo <at> gmail.com>
> Date: 2013/7/12
> Subject: mv fails when trying to overwrite a file in a (map) network drive
> To: bug-coreutils <at> gnu.org
>
>
> If I am working in my harddisk I can move and overwrite files.
>
> I'm working on Windows XP I have a network drive (Y:\)
> file1 exists
> file2 exists
> if I try:
> mv -f file1 file2
>
> It complains:
>
> mv: cannot move `file1' to `file2': File exists
----
1) Are the 2 files on the same drive?
2) Are one or both on a remote system (sounds like the target it
but just being sure)
3) What OS running on the fileserver that you are copying to? Windows
or *nix?
4) Are you aware, if you are on windows, that windows locks files by locking
regions
on disk -- which makes it hard for anything to come along and delete a file
(like on linux)
becuase windows doesn't have file handles that are separable from disk-ranges.
So if a file
is open for write (or exclusive read) on windows, you won't be able to delete it
like you
can on *nix. **You might** get away with a method I think cygwin is using now
(after I
suggested it years ago when it was laughed at and likely forgotten)... and that is
renaming the target -- often even to another directory. That will work unless
they also locked
the parent directory (ug -- it's rare, but I've seen it done to prevent renaming
the file
so a new one could be put in place). But that's the key -- you can't "delete"
it or overwrite
it because both would involve writing into the locked-reserved range. But
renaming it --
that's in the file-system index -- a completely separate entity from the file
space (why
in Goddesses name that doesn't make windows file-walks faster than on unix, I
dunno -- but
they usually aren't.
The names and security attribs are kept in large chunks call the MftZone. It
used to take
200-1000MB, up to win7 when they switched to allocating 200MB at a time (it
appears). So the
names usually can renamed on the same device which can allow a copy to take place.
Usually then an entry goes in the win registry in the "pending renames/pending
deletes key(s)...
as a rename to a null filename is the same as a delete. They are not process
until reboot when
the file is no longer likely to be locked.
Anyway, that cp might support such a hairbrained scheme wouldn't be surprising
since MS needs
open source to surive, now that open source is MS only real competitor (some
might claim apple,
but market segments are pretty different).
Having a Windows away version of cp would be good. -- having it aware that if you do
a cp -al on a mapped file system on a *nix system that reads as having "my new
font.ttf"linked
with "My New Font.ttf" and using cp -au won't go out and delete both copies so
it can maintain
the link which I had happen once -- but was told that it would be fixed in
cygwin (never heard
anything about it afterwards -- and that was about 2 years ago). Sigh. I strongly
prefer the Win7 way of handling case now -- case preserving, but cause ignoring.
They realized
people wanted U/l case, and they coudn't simply convert one to the other w/o
causing loss of
information.
Anyway... windows is 'weird'...you might try the rename I mentioned manually to
even see
if it is something that might work...
But if cp can't remove the file (like it used to being able to do on an *nix
based machine,
then from it's perspective, it can't copy into the new file because it already
exists.
>
> Hope the explanation is good enough.
>
> Cheers,
> Lluis
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#14852
; Package
coreutils
.
(Sun, 21 Oct 2018 21:23:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 14852 <at> debbugs.gnu.org (full text, mbox):
tags 14852 notabug
close 14852
stop
(triaging old bugs)
On 23/07/13 10:21 PM, Linda Walsh wrote:
> Lluis faixó wrote:
>>[...]
>> It complains:
>>
>> mv: cannot move `file1' to `file2': File exists
> 1) Are the 2 files on the same drive?
> 2) Are one or both on a remote system (sounds like the target it
> but just being sure)
> 3) What OS running on the fileserver that you are copying to? Windows
> or *nix?
>
[....]
> But if cp can't remove the file (like it used to being able to do on an *nix
> based machine,
> then from it's perspective, it can't copy into the new file because it already
> exists.
With no further follow-ups in 5 years, I'm closing this bug.
-assaf
Added tag(s) notabug.
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Sun, 21 Oct 2018 21:23:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
14852 <at> debbugs.gnu.org and Lluis faixó <lluis.faixo <at> gmail.com>
Request was from
Assaf Gordon <assafgordon <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Sun, 21 Oct 2018 21:23:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 19 Nov 2018 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 272 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.