Subject: Re: B20, Win95: cp destroys file
From: [email-masked] (Bob McGowan)

21 Nov 1998 04:57:21 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
To: [email-masked]

Mumit Khan wrote:
> > 
> > Earnie Boyd <[email-masked]> writes:
> > > ---"Henry S. Warren, Jr." <[email-masked]> wrote:
> > > >
> > > > If you copy, using cp, a file to itself, and the target and source
> > > files
> > > > differ in capitalization, then the content of the file is wiped out;
> > > it
> > > > becomes a file of 0-length.  Example: "cp hilbert.c hilbert.C" trashes
> > > > file hilbert.c.
> > > >    The Win95 "copy" command gives the error message "File cannot be
> > > > copied onto itself" in this situation (much preferable)
> > >
> > > Hmm.  It used to do it that way in b19.  Is it possible that inode or
> > > stat routine has become buggy?
> > 
> > Are you by any chance doing this on a SMB mounted filesystem? I remember
> > playing with this a while back, and it worked on FAT and NTFS, but not
> > on SAMBA disk (didn't try SMB disks from non-SAMBA server, such as NT).
> > 
> > I believe that the problem is in MoveFileEx (WIN API), which doesn't do
> > the right thing. However, the rename in MSVC runtime does somehow do
> > it correctly on all filesystems, so it's doing something more than using
> > MoveFileEx. (fyi, mv uses the rename runtime routine in winsup that in
> > turn uses MoveFileEx to do the actual renaming).
> 
> Isn't this the same as the win32 `cat foo >foo' problem?
> I find it hard to believe that this is related to a bug in

No, this is not the same as the cat with I/O redirection.  The I/O redirect is done by the shell and cat has no way of knowing what it is actually writing to.

The problem has to do with case sensitive versus case insensitive file systems.  Try copying a file with the same name/case and you get the following, under bash/b20:

  bash-2.02$ cp abc abc
  cp: `abc' and `abc' are the same file
  bash-2.02$

The cp is simply assuming that a name with the same characters but different case are in fact different files, which is true on UNIX type systems but not in Windows/DOS environments.

It seems to me that the simplest solution would be to translate all file system names to lower case in the DLL (or other low level area) and let the high level utilities do what they do naturally.  I think this would eliminate a lot of headaches and would match the way I have to think about files anyway on Windows systems when working outside of the Cygnus environment.

Bob McGowan

-----
See the original message at http://www.egroups.com/list/gnu-win32/?start=9441
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".