[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
bug#14852: Fwd: mv fails when trying to overwrite a file in a (map) network drive
Tue, 23 Jul 2013 21:21:32 -0700
Lluis faixó wrote:
> Forgot to say I'm using minGw with Msys latest version:
> 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
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
can on *nix. **You might** get away with a method I think cygwin is using now
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
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
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
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
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.
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
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
then from it's perspective, it can't copy into the new file because it already
> Hope the explanation is good enough.