Issue 810879: shutil.copyfile fails when dst exists read-only (original) (raw)

Created on 2003-09-22 23:21 by pascor, last changed 2022-04-10 16:11 by admin. This issue is now closed.

Messages (5)
msg18260 - (view)	Author: Ray Pasco (pascor)	Date: 2003-09-22 23:21
(WIN32): shutil.copyfile fails when the dst file already exists, but in read-only mode. As the old file is about to be clobbered, a fix I've been using is to delete the orginal file first. The attached my be inelegant, but works fine
msg18261 - (view)	Author: A.M. Kuchling (akuchling) *	Date: 2003-09-25 18:37
Logged In: YES user_id=11375 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( )
msg18262 - (view)	Author: Tim Peters (tim.peters) *	Date: 2004-02-16 23:52
Logged In: YES user_id=31435 Andrew, what does this do on Unix? I don't *want* copyfile() to clobber read-only files, so I view this report as a small lack in the docs (which unconditionally say dst will be replaced). If the user lacks sufficient write permissions on Unix (a decent approximation to Windows "read only" state), does copyfile() succeed anyway? I sure hope not. On Windows, fdst = open(dst, 'wb') dies with a (thoroughly appropriate, according to me) IOError: [Errno 13] Permission denied: <dst_value> when dst is read-only.
msg18263 - (view)	Author: A.M. Kuchling (akuchling) *	Date: 2004-05-05 17:10
Logged In: YES user_id=11375 On Unix it fails with the same os.error. I'll tweak the wording of the docs a bit, and then close this bug.
msg18264 - (view)	Author: A.M. Kuchling (akuchling) *	Date: 2004-05-05 17:22
Logged In: YES user_id=11375 Closing.