* "Renaming: permission denied" file-error in Windows @ 2011-12-11 0:16 LynX 2011-12-11 5:30 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: LynX @ 2011-12-11 0:16 UTC (permalink / raw) To: emacs-devel 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. The problem occurs when dired calls Emacs function which delegates the call to native POSIX function `rename'. In Windows `rename' operates a bit different than in other systems. According to MSDN [http://msdn.microsoft.com/en-us/library/zw5t957f.aspx]: -- "You can use rename to move a file from one directory or device to another by giving a different path in the newname argument. However, you cannot use rename to move a directory." -- Whereas, in standard POSIX spec such constraint was not found. Following code workarounds this problem by wrapping dired function `dired-rename-file'. So when `Renaming: permission denied' error occurs, it tries to move the directory again by moving each of it files recursively to a new destination, recreating the source directory with its subdirectory structure. If it also fails to do this due to real permission problems then it sends original error message. Regards, LX (defadvice dired-rename-file (around my-dired-rename-file (file newname ok-if-already-exists)) "This advice definition helps to deal with `Renaming: permission denied' error message when moving directories between different logical disks in dired. This is a Windows specific problem." (condition-case err ad-do-it (file-error (and (string-starts-with (error-message-string err) "Renaming: permission denied") (file-directory-p file) (move-directory-recursively file newname))))) (ad-activate 'dired-rename-file t) (defun move-directory-recursively (dir-src dir-dst) "Moves directory DIR-SRC to the DIR-DST recursively. To move directory dir1 into the directory dir2 you should call this function like as follows: (move-directory-recursively `dir1' `dir2/dir1') To move content of the directory dir1 into the directory dir2: (move-directory-recursively `dir1' `dir2') If dir2 does not exist it will be created." (let ((queue (list (cons dir-src dir-dst))) dir-dst dir-src remove-later) (while queue (let ((dir-src-dst (car queue))) (setq dir-src (car dir-src-dst)) (setq dir-dst (cdr dir-src-dst))) (setq queue (cdr queue)) ;; if dir-dst is a file signal an error (and (file-exists-p dir-dst) (not (file-directory-p dir-dst)) (signal 'file-error (format "Error: file %s exist" dir-dst))) ;; if dir-dst does not exist - create it (if (not (file-exists-p dir-dst)) (make-directory dir-dst)) (dolist (file (directory-files dir-src)) (and (not (string= file ".")) (not (string= file "..")) (let ((path (concat dir-src "/" file))) (if (file-directory-p path) ;; it is a directory (progn ;; place it to the queue (setq queue (cons (cons path (concat dir-dst "/" file)) queue)) ;; and store it path to remove it later (push path remove-later)) ;; not a dir (progn (message (format "Moving %s to %s" path dir-dst)) (rename-file path dir-dst))))))) ;; after we moved all content we can remove the ;; empty directories in dir-src (dolist (dir remove-later) (condition-case err (dired-delete-file dir 'always) (error ;; catch errors from failed deletions (dired-log "%s\n" err))))) (dired-delete-file dir-src 'always)) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "Renaming: permission denied" file-error in Windows 2011-12-11 0:16 "Renaming: permission denied" file-error in Windows LynX @ 2011-12-11 5:30 ` Eli Zaretskii 2011-12-11 5:32 ` Tekk 2011-12-11 8:32 ` Paul Eggert 0 siblings, 2 replies; 21+ messages in thread From: Eli Zaretskii @ 2011-12-11 5:30 UTC (permalink / raw) To: LynX; +Cc: emacs-devel > Date: Sun, 11 Dec 2011 02:16:45 +0200 > From: LynX <_LynX@bk.ru> > > 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. Does Emacs on Unix or GNU/Linux systems allow moving a directory to a different filesystem? (I cannot test this where I'm typing this.) If not, the Windows behavior is not a bug. > The problem occurs when dired calls Emacs function which delegates the > call to native POSIX function `rename'. > > In Windows `rename' operates a bit different than in other systems. > According to MSDN [http://msdn.microsoft.com/en-us/library/zw5t957f.aspx]: Emacs doesn't call `rename' from the MS library, it has its own replacement `sys_rename'. So if we decide to modify this behavior, we can. > -- "You can use rename to move a file from one directory or device to > another by giving a different path in the newname argument. However, you > cannot use rename to move a directory." -- But you _can_ rename or move a directory on MS-Windows, as long as the destination is on the same drive. Try it. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "Renaming: permission denied" file-error in Windows 2011-12-11 5:30 ` Eli Zaretskii @ 2011-12-11 5:32 ` Tekk 2011-12-11 5:42 ` Eli Zaretskii 2011-12-11 8:32 ` Paul Eggert 1 sibling, 1 reply; 21+ messages in thread From: Tekk @ 2011-12-11 5:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: LynX, emacs-devel On Sun, 11 Dec 2011, Eli Zaretskii wrote: >> Date: Sun, 11 Dec 2011 02:16:45 +0200 >> From: LynX <_LynX@bk.ru> >> >> 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. > > Does Emacs on Unix or GNU/Linux systems allow moving a directory to a > different filesystem? (I cannot test this where I'm typing this.) If > not, the Windows behavior is not a bug. > >> The problem occurs when dired calls Emacs function which delegates the >> call to native POSIX function `rename'. >> >> In Windows `rename' operates a bit different than in other systems. >> According to MSDN [http://msdn.microsoft.com/en-us/library/zw5t957f.aspx]: > > Emacs doesn't call `rename' from the MS library, it has its own > replacement `sys_rename'. So if we decide to modify this behavior, we > can. > >> -- "You can use rename to move a file from one directory or device to >> another by giving a different path in the newname argument. However, you >> cannot use rename to move a directory." -- > > But you _can_ rename or move a directory on MS-Windows, as long as the > destination is on the same drive. Try it. > but that's not his issue, he filed the bug about not being able to move onto a different drive, not being unable to move at all. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "Renaming: permission denied" file-error in Windows 2011-12-11 5:32 ` Tekk @ 2011-12-11 5:42 ` Eli Zaretskii 0 siblings, 0 replies; 21+ messages in thread From: Eli Zaretskii @ 2011-12-11 5:42 UTC (permalink / raw) To: Tekk; +Cc: _LynX, emacs-devel > Date: Sun, 11 Dec 2011 00:32:36 -0500 (EST) > From: Tekk <tekk@parlementum.net> > cc: LynX <_LynX@bk.ru>, emacs-devel@gnu.org > > >> -- "You can use rename to move a file from one directory or device to > >> another by giving a different path in the newname argument. However, you > >> cannot use rename to move a directory." -- > > > > But you _can_ rename or move a directory on MS-Windows, as long as the > > destination is on the same drive. Try it. > > > but that's not his issue, he filed the bug about not being able to move > onto a different drive, not being unable to move at all. I know, but I was referring to the part he cited (see above), that tells you cannot rename or move a directory at all. That is not true. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "Renaming: permission denied" file-error in Windows 2011-12-11 5:30 ` Eli Zaretskii 2011-12-11 5:32 ` Tekk @ 2011-12-11 8:32 ` Paul Eggert 2011-12-11 12:51 ` Eli Zaretskii 1 sibling, 1 reply; 21+ messages in thread From: Paul Eggert @ 2011-12-11 8:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: LynX, emacs-devel On 12/10/11 21:30, Eli Zaretskii wrote: > Does Emacs on Unix or GNU/Linux systems allow moving a directory to a > different filesystem? (I cannot test this where I'm typing this.) Yes it does. Emacs first tries to rename the directory, and when that fails (because rename fails with errno == EXDEV) it copies the directory recursively. > If not, the Windows behavior is not a bug. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "Renaming: permission denied" file-error in Windows 2011-12-11 8:32 ` Paul Eggert @ 2011-12-11 12:51 ` Eli Zaretskii 2011-12-11 19:30 ` LynX 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2011-12-11 12:51 UTC (permalink / raw) To: Paul Eggert; +Cc: _LynX, emacs-devel > Date: Sun, 11 Dec 2011 00:32:33 -0800 > From: Paul Eggert <eggert@cs.ucla.edu> > CC: LynX <_LynX@bk.ru>, emacs-devel@gnu.org > > On 12/10/11 21:30, Eli Zaretskii wrote: > > Does Emacs on Unix or GNU/Linux systems allow moving a directory to a > > different filesystem? (I cannot test this where I'm typing this.) > > Yes it does. Thanks. > Emacs first tries to rename the directory, and when that > fails (because rename fails with errno == EXDEV) it copies the > directory recursively. Ah, I see the problem now: the implementation of `rename' on Windows does not return errno = EXDEV in that case, so the recursive copying does not happen. I encourage the OP to file a bug report (using "M-x report-emacs-bug") about this. It should be easy to fix this. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "Renaming: permission denied" file-error in Windows 2011-12-11 12:51 ` Eli Zaretskii @ 2011-12-11 19:30 ` LynX 2011-12-11 18:03 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: LynX @ 2011-12-11 19:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Paul Eggert, emacs-devel On 12/11/2011 12:51 PM, Eli Zaretskii wrote: > Ah, I see the problem now: the implementation of `rename' on Windows > does not return errno = EXDEV in that case, so the recursive copying > does not happen. Oh, yes you are right :). Here is a simple c code which demonstrates this: #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <errno.h> int main(int argc, char* argv[]) { // in Windows path of course was a bit different :) int ret = rename("/media/c/toDel/test", "/media/g/Temp"); perror("error"); printf("ret %d errno %d\n", ret, errno); if (errno == EXDEV) { printf("EXDEV\n"); } else if (errno == EACCES) { printf("EACCES\n"); } while(1); return 0; } In Linux output is: ret -1 errno 18 EXDEV In Windows: error: Permission denied ret -1 errno 13 EACCES So for Windows rename returns EACCES instead of EXDEV. Maybe to fix it in Windows we need to check rename error code not only for EXDEV but for EACCES also. > > I encourage the OP to file a bug report (using "M-x report-emacs-bug") > about this. It should be easy to fix this. > > Sorry, what "OP" means? :) Regards, LX ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "Renaming: permission denied" file-error in Windows 2011-12-11 19:30 ` LynX @ 2011-12-11 18:03 ` Eli Zaretskii 2011-12-11 21:45 ` LynX 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2011-12-11 18:03 UTC (permalink / raw) To: LynX; +Cc: eggert, emacs-devel > Date: Sun, 11 Dec 2011 19:30:11 +0000 > From: LynX <_LynX@bk.ru> > CC: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel@gnu.org > > So for Windows rename returns EACCES instead of EXDEV. Yes. > Maybe to fix it in Windows we need to check rename error code not only > for EXDEV but for EACCES also. No, we should modify sys_rename (in w32.c) to return EXDEV in these cases. > > I encourage the OP to file a bug report (using "M-x report-emacs-bug") > > about this. It should be easy to fix this. > > > > > > Sorry, what "OP" means? :) "Original Poster". That is, you. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "Renaming: permission denied" file-error in Windows 2011-12-11 18:03 ` Eli Zaretskii @ 2011-12-11 21:45 ` LynX 2011-12-11 21:31 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: LynX @ 2011-12-11 21:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, emacs-devel Dear Eli, Thank you for you response. If you don't mind I would like to try to fix it. It just would take some time to prepare my environment to build Emacs. Do I need to provide bug report in such case either? Regards, LX On 12/11/2011 06:03 PM, Eli Zaretskii wrote: >> Date: Sun, 11 Dec 2011 19:30:11 +0000 >> From: LynX<_LynX@bk.ru> >> CC: Paul Eggert<eggert@cs.ucla.edu>, emacs-devel@gnu.org >> >> So for Windows rename returns EACCES instead of EXDEV. > > Yes. > >> Maybe to fix it in Windows we need to check rename error code not only >> for EXDEV but for EACCES also. > > No, we should modify sys_rename (in w32.c) to return EXDEV in these > cases. > >>> I encourage the OP to file a bug report (using "M-x report-emacs-bug") >>> about this. It should be easy to fix this. >>> >>> >> >> Sorry, what "OP" means? :) > > "Original Poster". That is, you. > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "Renaming: permission denied" file-error in Windows 2011-12-11 21:45 ` LynX @ 2011-12-11 21:31 ` Eli Zaretskii 2011-12-25 7:33 ` LynX 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2011-12-11 21:31 UTC (permalink / raw) To: LynX; +Cc: eggert, emacs-devel > Date: Sun, 11 Dec 2011 21:45:02 +0000 > From: LynX <_LynX@bk.ru> > CC: eggert@cs.ucla.edu, emacs-devel@gnu.org > > Thank you for you response. > If you don't mind I would like to try to fix it. > It just would take some time to prepare my environment to build Emacs. > > Do I need to provide bug report in such case either? It is better to do that, so that we have a record of the problem. Thanks. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "Renaming: permission denied" file-error in Windows 2011-12-11 21:31 ` Eli Zaretskii @ 2011-12-25 7:33 ` LynX 2011-12-25 9:39 ` bug#10284: " Eli Zaretskii 2011-12-25 9:40 ` Eli Zaretskii 0 siblings, 2 replies; 21+ messages in thread From: LynX @ 2011-12-25 7:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: eggert, emacs-devel 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): --- w32.c.orig 2011-11-26 05:20:20.000000000 +0200 +++ w32.c 2011-12-25 09:22:37.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,31 @@ 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); + && 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; return result; } Fix is done as you proposed: >> Maybe to fix it in Windows we need to check rename error code not only >> for EXDEV but for EACCES also. >No, we should modify sys_rename (in w32.c) to return EXDEV in these >cases. I've tested it (Windows XP sp3) and was able to move the directories between different storage devices. Regards, LX 11.12.2011 23:31, Eli Zaretskii пишет: >> Date: Sun, 11 Dec 2011 21:45:02 +0000 >> From: LynX<_LynX@bk.ru> >> CC: eggert@cs.ucla.edu, emacs-devel@gnu.org >> >> Thank you for you response. >> If you don't mind I would like to try to fix it. >> It just would take some time to prepare my environment to build Emacs. >> >> Do I need to provide bug report in such case either? > > It is better to do that, so that we have a record of the problem. > > Thanks. > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10284: "Renaming: permission denied" file-error in Windows 2011-12-25 7:33 ` LynX @ 2011-12-25 9:39 ` Eli Zaretskii 2011-12-25 9:40 ` Eli Zaretskii 1 sibling, 0 replies; 21+ messages in thread From: Eli Zaretskii @ 2011-12-25 9:39 UTC (permalink / raw) To: LynX; +Cc: 10284, eggert [Redirected to the bug tracker, to keep the entire discussion archived.] > Date: Sun, 25 Dec 2011 09:33:34 +0200 > From: LynX <_LynX@bk.ru> > CC: emacs-devel@gnu.org, eggert@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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: "Renaming: permission denied" file-error in Windows 2011-12-25 7:33 ` LynX 2011-12-25 9:39 ` bug#10284: " Eli Zaretskii @ 2011-12-25 9:40 ` Eli Zaretskii 2011-12-28 19:53 ` bug#10284: " LynX 1 sibling, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2011-12-25 9:40 UTC (permalink / raw) To: LynX; +Cc: eggert, emacs-devel > Date: Sun, 25 Dec 2011 09:33:34 +0200 > From: LynX <_LynX@bk.ru> > Cc: eggert@cs.ucla.edu, emacs-devel@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@debbugs.gnu.org. Please respond there, not here. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10284: "Renaming: permission denied" file-error in Windows 2011-12-25 9:40 ` Eli Zaretskii @ 2011-12-28 19:53 ` LynX 2011-12-29 6:18 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: LynX @ 2011-12-28 19:53 UTC (permalink / raw) To: 10284 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@bk.ru> >> Cc: eggert@cs.ucla.edu, emacs-devel@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@debbugs.gnu.org. > > Please respond there, not here. > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10284: "Renaming: permission denied" file-error in Windows 2011-12-28 19:53 ` bug#10284: " LynX @ 2011-12-29 6:18 ` Eli Zaretskii 2011-12-30 19:31 ` LynX 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2011-12-29 6:18 UTC (permalink / raw) To: LynX; +Cc: 10284 > Date: Wed, 28 Dec 2011 21:53:39 +0200 > From: LynX <_LynX@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.) ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10284: "Renaming: permission denied" file-error in Windows 2011-12-29 6:18 ` Eli Zaretskii @ 2011-12-30 19:31 ` LynX 2011-12-30 20:23 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: LynX @ 2011-12-30 19:31 UTC (permalink / raw) To: 10284 [-- Attachment #1: Type: text/plain, Size: 3120 bytes --] 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@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.) > > [-- Attachment #2: w32.c.patch --] [-- Type: text/plain, Size: 1748 bytes --] --- 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; } ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10284: "Renaming: permission denied" file-error in Windows 2011-12-30 19:31 ` LynX @ 2011-12-30 20:23 ` Eli Zaretskii 2011-12-30 21:35 ` LynX 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2011-12-30 20:23 UTC (permalink / raw) To: LynX; +Cc: 10284 > Date: Fri, 30 Dec 2011 21:31:26 +0200 > From: LynX <_LynX@bk.ru> > > Please review this patch. Looks good, thanks. Did you test it with UNC filenames, btw? ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10284: "Renaming: permission denied" file-error in Windows 2011-12-30 20:23 ` Eli Zaretskii @ 2011-12-30 21:35 ` LynX 2011-12-31 6:48 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: LynX @ 2011-12-30 21:35 UTC (permalink / raw) To: 10284 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10284: "Renaming: permission denied" file-error in Windows 2011-12-30 21:35 ` LynX @ 2011-12-31 6:48 ` Eli Zaretskii 2012-01-06 20:46 ` LynX 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2011-12-31 6:48 UTC (permalink / raw) To: LynX; +Cc: 10284 > Date: Fri, 30 Dec 2011 23:35:38 +0200 > From: LynX <_LynX@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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10284: "Renaming: permission denied" file-error in Windows 2011-12-31 6:48 ` Eli Zaretskii @ 2012-01-06 20:46 ` LynX 2012-01-07 9:54 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: LynX @ 2012-01-06 20:46 UTC (permalink / raw) To: 10284 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#10284: "Renaming: permission denied" file-error in Windows 2012-01-06 20:46 ` LynX @ 2012-01-07 9:54 ` Eli Zaretskii 0 siblings, 0 replies; 21+ messages in thread From: Eli Zaretskii @ 2012-01-07 9:54 UTC (permalink / raw) To: LynX; +Cc: 10284-done > Date: Fri, 06 Jan 2012 22:46:00 +0200 > From: LynX <_LynX@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. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2012-01-07 9:54 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-12-11 0:16 "Renaming: permission denied" file-error in Windows LynX 2011-12-11 5:30 ` Eli Zaretskii 2011-12-11 5:32 ` Tekk 2011-12-11 5:42 ` Eli Zaretskii 2011-12-11 8:32 ` Paul Eggert 2011-12-11 12:51 ` Eli Zaretskii 2011-12-11 19:30 ` LynX 2011-12-11 18:03 ` Eli Zaretskii 2011-12-11 21:45 ` LynX 2011-12-11 21:31 ` Eli Zaretskii 2011-12-25 7:33 ` LynX 2011-12-25 9:39 ` bug#10284: " Eli Zaretskii 2011-12-25 9:40 ` Eli Zaretskii 2011-12-28 19:53 ` bug#10284: " LynX 2011-12-29 6:18 ` Eli Zaretskii 2011-12-30 19:31 ` LynX 2011-12-30 20:23 ` Eli Zaretskii 2011-12-30 21:35 ` LynX 2011-12-31 6:48 ` Eli Zaretskii 2012-01-06 20:46 ` LynX 2012-01-07 9:54 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.