bug in built-in function copy-file

bug in built-in function copy-file

[Barman Brakjoller]

I think I have found a bug in how copy-file works, at least on my
Windows 2000 system. See below for how to reproduce it:

(The reason for using eshell to describe this "bug" is that it is easy
to follow what I'm doing. I am NOT trying to report an eshell error
here.)

c:/tst $ echo file1 > file1
c:/tst $ echo file2 > file2
c:/tst $ attrib +r file1
c:/tst $ ll
total 0
-r--r--r--   1 Barman B 5               5 jun 30 11:11 file1
-rw-rw-rw-   1 Barman B 5               5 jun 30 11:11 file2
c:/tst $ (copy-file "file2" "file1" t)
Copying file: invalid argument, c:/tst/file2, c:/tst/file1

You may not think this is a bug, but I think so. I think copy-file
should either:

 a) report a error message that actually tells the user what the
    problem is (you have to agree that "invalid argument" when trying
    to copy one file to another does not tell the user very much)

 b) try to handle the read-only file in the same way that save-buffer
    and write-file does, i.e asking user for permission to overwrite
    the file, then try to temporarily change the file permission bits
    (if the file is not writable), write the file and restore the file
    permission bits.

 c) add a new optional argument to copy-file so that it works
 something like in b) above, but without the confirmation

I'd think that b) and/or c) would be the preferred way to solve this.

Btw, the same procedure in Linux (using chmod instead of attrib of
course) gives the following error message (which is much better):

 Opening output file: permission denied, /tmp/file1

So at least there is an inconsistency in how this is handled on the
two systems I have tested on.

I'm using GNU Emacs 21.1.1 on Windows 2000 and Mandrake Linux 8.0.

bug in built-in function copy-file

[Barman Brakjoller]

I think I have found a bug in how copy-file works, at least on my
Windows 2000 system. See below for how to reproduce it:

(The reason for using eshell to describe this "bug" is that it is easy
to follow what I'm doing. I am NOT trying to report an eshell error
here.)

c:/tst $ echo file1 > file1
c:/tst $ echo file2 > file2
c:/tst $ attrib +r file1
c:/tst $ ll
total 0
-r--r--r--   1 Barman B 5               5 jun 30 11:11 file1
-rw-rw-rw-   1 Barman B 5               5 jun 30 11:11 file2
c:/tst $ (copy-file "file2" "file1" t)
Copying file: invalid argument, c:/tst/file2, c:/tst/file1

You may not think this is a bug, but I think so. I think copy-file
should either:

a) report a error message that actually tells the user what the
    problem is (you have to agree that "invalid argument" when trying
    to copy one file to another does not tell the user very much)

b) try to handle the read-only file in the same way that save-buffer
    and write-file does, i.e asking user for permission to overwrite
    the file, then try to temporarily change the file permission bits
    (if the file is not writable), write the file and restore the file
    permission bits.

c) add a new optional argument to copy-file so that it works
something like in b) above, but without the confirmation

I'd think that b) and/or c) would be the preferred way to solve this.

Btw, the same procedure in Linux (using chmod instead of attrib of
course) gives the following error message (which is much better):

Opening output file: permission denied, /tmp/file1

So at least there is an inconsistency in how this is handled on the
two systems I have tested on.

I'm using GNU Emacs 21.1.1 on Windows 2000 and Mandrake Linux 8.0.



_________________________________________________________________
På MSN hittar du det roliga, intressanta och användbara på internet: 
http://www.msn.se

Re: bug in built-in function copy-file

[Eli Zaretskii]

On Sun, 30 Jun 2002, Barman Brakjoller wrote:

> c:/tst $ (copy-file "file2" "file1" t)
> Copying file: invalid argument, c:/tst/file2, c:/tst/file1

Thanks, I think this bug is already fixed for the next release.