This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New rename(2) function


On Aug  9 21:23, Eric Blake wrote:
> According to Christian Franke on 8/9/2007 10:38 AM:
> > 
> > $ mv Foo foo
> > mv: `Foo' and `foo' are the same file
> 
> It looks like mv uses stat() before trying rename(); and on a
> case-insensitive system, both spellings name the same file.  Are you
> suggesting that I should look into a cygwin-local patch to coreutils that
> tries the rename if all that differs is case, even when stat() says it is
> the same file?  But it looks like you are right - rename("A","a") only
> sees a link count of 1, so the current implementation skips the same id
> check, and then falls through to the Windows rename operation, which
> apparently really does change the case.

But it's a mere coincidence.  If you try to fix the case of a file
with more than 1 link, you're stuck.  I will add a test which looks if
the file only differs by case and then falls through to the rename
operation without further testing.

> > $ mkdir Bar
> > 
> > $ mv Bar bar
> > mv: cannot move `Bar' to a subdirectory of itself, `bar/Bar'
> 
> If you wanted rename semantics with directories, you should use 'mv -T Bar
> bar'.  But that said, this probably falls in the same category as 'mv Foo
> foo' for non-directories - it would need a cygwin-specific patch to try
> the rename() even when stat() says there is no point to it.  And it would
> require that we make the conscious decision to keep the current behavior,
> where rename("A","a") with case-insensitive behavior changes the case.

I'm wondering if the coreutils team wouldn't be interested to solve this
problem independently of the OS.  That's not a Cygwin problem, it's a
problem with case preserving/not case sensitive file systems, even on
"real" OSes.  Here's an example using a FAT filesystem under Linux:

$ uname -a
Linux vmrhel4.vinschen.de 2.6.9-55.0.2.EL #1 Tue Jun 12 17:47:10 EDT 2007 i686 athlon i386 GNU/Linux
$ mount -t vfat /dev/sdb1 /mnt
$ cd /mnt
$ touch q
$ stat q
  File: `q'
  Size: 0               Blocks: 0          IO Block: 8192   regular empty file
Device: 811h/2065d      Inode: 114         Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (  500/ corinna)   Gid: (  100/   users)
Access: 2007-08-10 11:33:47.282195512 +0200
Modify: 2007-08-10 11:33:47.282195512 +0200
Change: 2007-08-10 11:33:47.282195512 +0200
$ stat Q
  File: `Q'
  Size: 0               Blocks: 0          IO Block: 8192   regular empty file
Device: 811h/2065d      Inode: 114         Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (  500/ corinna)   Gid: (  100/   users)
Access: 2007-08-10 11:33:47.282195512 +0200
Modify: 2007-08-10 11:33:47.282195512 +0200
Change: 2007-08-10 11:33:47.282195512 +0200
$ mv q Q
mv: `q' and `Q' are the same file

So, from my point of view, this is a generic bug in coreutils, not just
a corner case in a forlorn OS from ZZ9 Plural Z Alpha.

Here's a question:  Why isn't the decision if 'a' and 'A' are the same
file left as an exercise to the OS call rename(2)?  And why isn't there
*at least* a switch to override these tests so as to serve case
preserving file systems?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]