[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14852: Fwd: mv fails when trying to overwrite a file in a (map) netw

From: Linda Walsh
Subject: bug#14852: Fwd: mv fails when trying to overwrite a file in a (map) network drive
Date: Tue, 23 Jul 2013 21:21:32 -0700
User-agent: Thunderbird

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� <address@hidden>
> Date: 2013/7/12
> Subject: mv fails when trying to overwrite a file in a (map) network drive
> To: address@hidden
> 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 
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 
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 

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

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

> Hope the explanation is good enough.
> Cheers,
> Lluis

reply via email to

[Prev in Thread] Current Thread [Next in Thread]