(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

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. :-( )

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.

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.

Logged In: YES 
user_id=11375

Closing.