delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/01/19/11:20:05

Date: Sun, 19 Jan 1997 18:03:02 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: djgpp AT delorie DOT com
cc: DJ Delorie <dj AT delorie DOT com>
Subject: Bug in `rename' and `mv'
Message-ID: <Pine.SUN.3.91.970119175451.23317I-100000@is>
MIME-Version: 1.0

People who use `rename' library function and the `mv' program from the 
ported GNU Fileutils, please note that there is a bug in `rename' which 
will rear its ugly head if you try something like so:

	rename ("xyzzy", "xyzzy/abcd");
or
	mv xyzzy xyzzy/abcd

where `xyzzy' is a directory.  (This is clearly not something which makes 
sense to say, but it can happen due to a typo.)  In such cases, instead 
of failing the call, `rename' and `mv' will create a deeply nested 
directory structure:

	xyzzy/abcd
	xyzzy/abcd/abcd
	xyzzy/abcd/abcd/abcd

etc., ad nauseum, until the limit on pathname length imposed by your 
system eventually fails the call.

A version of `mv' linked against a patched library is available as 
ftp://is.elta.co.il/pub/mv.exe; for those who want to patch their 
libraries, here's the context diff:

*** src/libc/ansi/stdio/rename.c~0	Sun Jan 19 12:14:18 1997
--- src/libc/ansi/stdio/rename.c	Sun Jan 19 12:34:10 1997
***************
*** 358,363 ****
--- 358,377 ----
            simple_should_do = 1;
          }
      }
+   else if ((source_attr & 0x10) == 0x10)
+     {
+       /* Fail to rename OLD -> OLD/whatever.  */
+       char new_true[FILENAME_MAX], old_true[FILENAME_MAX];
+ 
+       errno = 0;
+       if (is_parent(_truename(old, old_true), _truename(new, new_true)))
+ 	{
+ 	  errno = EINVAL;
+ 	  return -1;
+ 	}
+       else if (errno)
+ 	return -1;
+     }
  
    /* On to some REAL work for a change.  Let DOS do the simple job:
       moving a regular file, or renaming a directory.  Note that on

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019