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

[Linda Walsh]

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