GNU bug report logs - #10284
23.2; "Renaming: permission denied" file-error in Windows

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10284 in the body.
You can then email your comments to 10284 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: LynX <_LynX <at> bk.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.2; "Renaming: permission denied" file-error in Windows
Date: Mon, 12 Dec 2011 22:35:22 +0200

Hello,

I found that dired in Windows does not provide you possibility to move a 
directory to a new location if this new location resides on a different 
logical disk.

For instance you have two opened dired buffers: `c:\dir1' and
`f:\dir2'. To move some files from `dir1' to `dir2' you can use "R", but
if you try to move some directory from `dir1' to `dir2' you will get
`Renaming: permission denied' error message.

For more details and temporary workaround please refer to the emacs-devel
mail list:
http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00253.html

Regards,
LX


In GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600)
 of 2010-05-08 on G41R2F1
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags 
-Ic:/xpm/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: RUS
  value of $XMODIFIERS: nil
  locale-coding-system: cp1251
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> M-x r e p o <tab> r t - <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
call-interactively: End of buffer [2 times]

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc
time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1
hex-util hashcash mail-utils emacsbug help-mode easymenu view tooltip
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp
w32-win w32-vars tool-bar dnd fontset image fringe lisp-mode register
page menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)

Message #8 received at 10284 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: LynX <_LynX <at> bk.ru>
Cc: 10284 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: "Renaming: permission denied" file-error in Windows
Date: Sun, 25 Dec 2011 04:39:18 -0500

[Redirected to the bug tracker, to keep the entire discussion archived.]

> Date: Sun, 25 Dec 2011 09:33:34 +0200
> From: LynX <_LynX <at> bk.ru>
> CC: emacs-devel <at> gnu.org, eggert <at> cs.ucla.edu
> 
> I've opened a bug report here:
> 
> 10284: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10284

Thanks.

>     result = rename (temp, newname);
> 
>     if (result < 0
> -      && errno == EEXIST
> -      && _chmod (newname, 0666) == 0
> -      && _unlink (newname) == 0)
> -    result = rename (temp, newname);
> +      && errno == EEXIST)
> +    {
> +      if (_chmod (newname, 0666) != 0)
> +	return result;
> +      if (_unlink (newname) != 0)
> +	return result;
> +      result = rename (temp, newname);
> +    }
> +
> +  /* The implementation of `rename' on Windows does not return
> +     errno = EXDEV when you are moving a directory to a different
> +     storage device (ex. logical disk). It returns EACCES
> +     instead. So here we handle such situations and return EXDEV.   */
> +
> +  if (result < 0
> +      && errno == EACCES
> +      && newname_dev != oldname_dev)
> +    errno = EXDEV;

This first removes the target, and only then compares the device
numbers.  Wouldn't it be better to do it the other way around, at
least when the target is a directory?  That way, the target is left
intact if the caller doesn't want to copy over the target, and also
the filesystem is left in the same state as on Posix hosts in this
case, i.e. the contract of `rename' is preserved on all systems.

Thanks for working on this.

Message #11 received at 10284 <at> debbugs.gnu.org (full text, mbox):

From: LynX <_LynX <at> bk.ru>
To: 10284 <at> debbugs.gnu.org
Subject: Re: "Renaming: permission denied" file-error in Windows
Date: Wed, 28 Dec 2011 21:53:39 +0200

Dear Eli,

Thank you for your response.

I just want to double check that I understood you right.

> This first removes the target, and only then compares the device
> numbers.  Wouldn't it be better to do it the other way around, at
> least when the target is a directory?  That way, the target is left
> intact if the caller doesn't want to copy over the target, and also
> the filesystem is left in the same state as on Posix hosts in this
> case, i.e. the contract of `rename' is preserved on all systems.

You mean that before setting errno to EXDEV we also need to check that 
target is a directory (since files are moved correctly)?

Regards,
LX

25.12.2011 11:40, Eli Zaretskii пишет:
>> Date: Sun, 25 Dec 2011 09:33:34 +0200
>> From: LynX<_LynX <at> bk.ru>
>> Cc: eggert <at> cs.ucla.edu, emacs-devel <at> gnu.org
>>
>> Dear Eli,
>>
>> I've opened a bug report here:
>>
>> 10284: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10284
>>
>> Here is the patch for this issue (it is done for the latest source
>> package emacs-23.3b.tar.bz2):
>
> I've redirected this discussion to the bug tracker,
> 10284 <at> debbugs.gnu.org.
>
> Please respond there, not here.
>
>

Message #14 received at 10284 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: LynX <_LynX <at> bk.ru>
Cc: 10284 <at> debbugs.gnu.org
Subject: Re: bug#10284: "Renaming: permission denied" file-error in Windows
Date: Thu, 29 Dec 2011 01:18:02 -0500

> Date: Wed, 28 Dec 2011 21:53:39 +0200
> From: LynX <_LynX <at> bk.ru>
> 
>  > This first removes the target, and only then compares the device
>  > numbers.  Wouldn't it be better to do it the other way around, at
>  > least when the target is a directory?  That way, the target is left
>  > intact if the caller doesn't want to copy over the target, and also
>  > the filesystem is left in the same state as on Posix hosts in this
>  > case, i.e. the contract of `rename' is preserved on all systems.
> 
> You mean that before setting errno to EXDEV we also need to check that 
> target is a directory (since files are moved correctly)?

Yes, but that's not the important part of my comment above.  The
important part is to move the check for different devices _before_ the
call to _unlink which removes the target file/directory if it exists.
In other words, we should fail and report EXDEV without risking the
removal of the target, and let the caller decide what to do with the
failure.  (If the caller decides to leave things unchanged, it will
not be The Right Thing for us to remove the target.)

Message #17 received at 10284 <at> debbugs.gnu.org (full text, mbox):

From: LynX <_LynX <at> bk.ru>
To: 10284 <at> debbugs.gnu.org
Subject: Re: bug#10284: "Renaming: permission denied" file-error in Windows
Date: Fri, 30 Dec 2011 21:31:26 +0200

[Message part 1 (text/plain, inline)]

Hello Eli,

Thank you for the clarification.

Please review this patch.

--- w32.c.orig	2011-11-26 05:20:20.000000000 +0200
+++ w32.c	2011-12-30 21:22:56.734375000 +0200
@@ -2857,6 +2857,8 @@
 {
   BOOL result;
   char temp[MAX_PATH];
+  int newname_dev;
+  int oldname_dev;

   /* MoveFile on Windows 95 doesn't correctly change the short file name
      alias in a number of circumstances (it is not easy to predict when
@@ -2873,6 +2875,9 @@

   strcpy (temp, map_w32_filename (oldname, NULL));

+  /* volume_info is set indirectly by map_w32_filename */
+  oldname_dev = volume_info.serialnum;
+
   if (os_subtype == OS_WIN95)
     {
       char * o;
@@ -2916,13 +2921,36 @@
      all the permutations of shared or subst'd drives, etc.)  */

   newname = map_w32_filename (newname, NULL);
+
+  /* volume_info is set indirectly by map_w32_filename */
+  newname_dev = volume_info.serialnum;
+
   result = rename (temp, newname);

-  if (result < 0
-      && errno == EEXIST
-      && _chmod (newname, 0666) == 0
-      && _unlink (newname) == 0)
-    result = rename (temp, newname);
+  if (result < 0)
+    {
+
+      if (errno == EACCES
+	  && newname_dev != oldname_dev)
+	{
+	  /* The implementation of `rename' on Windows does not return
+	     errno = EXDEV when you are moving a directory to a different
+	     storage device (ex. logical disk). It returns EACCES
+	     instead. So here we handle such situations and return EXDEV. */
+	  DWORD attributes;
+	  if ((attributes = GetFileAttributes(temp)) != -1
+	      && attributes & FILE_ATTRIBUTE_DIRECTORY)
+	    errno = EXDEV;
+	}
+      else if (errno == EEXIST)
+	{
+	  if (_chmod (newname, 0666) != 0)
+	    return result;
+	  if (_unlink (newname) != 0)
+	    return result;
+	  result = rename (temp, newname);
+	}
+    }

   return result;
 }

I've added check whether it is a directory or not, and moved all this 
before the unlink operation.

Regards,
LX

29.12.2011 8:18, Eli Zaretskii пишет:
>> Date: Wed, 28 Dec 2011 21:53:39 +0200
>> From: LynX<_LynX <at> bk.ru>
>>
>>   >  This first removes the target, and only then compares the device
>>   >  numbers.  Wouldn't it be better to do it the other way around, at
>>   >  least when the target is a directory?  That way, the target is left
>>   >  intact if the caller doesn't want to copy over the target, and also
>>   >  the filesystem is left in the same state as on Posix hosts in this
>>   >  case, i.e. the contract of `rename' is preserved on all systems.
>>
>> You mean that before setting errno to EXDEV we also need to check that
>> target is a directory (since files are moved correctly)?
>
> Yes, but that's not the important part of my comment above.  The
> important part is to move the check for different devices _before_ the
> call to _unlink which removes the target file/directory if it exists.
> In other words, we should fail and report EXDEV without risking the
> removal of the target, and let the caller decide what to do with the
> failure.  (If the caller decides to leave things unchanged, it will
> not be The Right Thing for us to remove the target.)
>
>

[w32.c.patch (text/plain, attachment)]

Message #20 received at 10284 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: LynX <_LynX <at> bk.ru>
Cc: 10284 <at> debbugs.gnu.org
Subject: Re: bug#10284: "Renaming: permission denied" file-error in Windows
Date: Fri, 30 Dec 2011 22:23:04 +0200

> Date: Fri, 30 Dec 2011 21:31:26 +0200
> From: LynX <_LynX <at> bk.ru>
> 
> Please review this patch.

Looks good, thanks.

Did you test it with UNC filenames, btw?

Message #23 received at 10284 <at> debbugs.gnu.org (full text, mbox):

From: LynX <_LynX <at> bk.ru>
To: 10284 <at> debbugs.gnu.org
Subject: Re: bug#10284: "Renaming: permission denied" file-error in Windows
Date: Fri, 30 Dec 2011 23:35:38 +0200

Dear Eli,

> Did you test it with UNC filenames, btw?

Nope, but I tried it now with Cyrillic names and it worked.

If you asked this because of GetFileAttributes, I think that it is 
mapped somewhere to GetFileAttributesW (since when I tried 
GetFileAttributesA with Cyrillic names it failed :).

Regards,
LX

Message #26 received at 10284 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: LynX <_LynX <at> bk.ru>
Cc: 10284 <at> debbugs.gnu.org
Subject: Re: bug#10284: "Renaming: permission denied" file-error in Windows
Date: Sat, 31 Dec 2011 08:48:50 +0200

> Date: Fri, 30 Dec 2011 23:35:38 +0200
> From: LynX <_LynX <at> bk.ru>
> 
> > Did you test it with UNC filenames, btw?
> 
> Nope, but I tried it now with Cyrillic names and it worked.

Thanks.  But "UNC" doesn't mean "Unicode", it means "Universal Naming
Convention", and refers to the \\server\share\foo style of file names
on remote machines.

> If you asked this because of GetFileAttributes, I think that it is 
> mapped somewhere to GetFileAttributesW (since when I tried 
> GetFileAttributesA with Cyrillic names it failed :).

No, I was thinking about what volume_info.serialnum will give you for
UNC filenames.

Message #29 received at 10284 <at> debbugs.gnu.org (full text, mbox):

From: LynX <_LynX <at> bk.ru>
To: 10284 <at> debbugs.gnu.org
Subject: Re: bug#10284: "Renaming: permission denied" file-error in Windows
Date: Fri, 06 Jan 2012 22:46:00 +0200

Dear Eli,

> Thanks.  But "UNC" doesn't mean "Unicode", it means "Universal Naming
> Convention", and refers to the \\server\share\foo style of file names
> on remote machines.

Sorry now I got it :)

Today I tested it and it worked fine. I was able to move non-empty 
directory to remote shared directory (\\remote_host\shared) and then 
moved it back successfuly.

Regards,
LX

Message #34 received at 10284-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: LynX <_LynX <at> bk.ru>
Cc: 10284-done <at> debbugs.gnu.org
Subject: Re: bug#10284: "Renaming: permission denied" file-error in Windows
Date: Sat, 07 Jan 2012 11:54:28 +0200

> Date: Fri, 06 Jan 2012 22:46:00 +0200
> From: LynX <_LynX <at> bk.ru>
> 
> > Thanks.  But "UNC" doesn't mean "Unicode", it means "Universal Naming
> > Convention", and refers to the \\server\share\foo style of file names
> > on remote machines.
> 
> Sorry now I got it :)
> 
> Today I tested it and it worked fine. I was able to move non-empty 
> directory to remote shared directory (\\remote_host\shared) and then 
> moved it back successfuly.

Thanks.  I committed the changes for you (as trunk revision 106818),
and I'm closing this bug.

Note that this patch is as much as we can accept from you without
legal papers, so if you want to continue contributing to Emacs, I
encourage you to sign legal papers that assign copyright for your
changes to the FSF.

Thanks again for working on this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.