Synchronous shutil.copyfile()

Hugo Ferreira bytter at gmail.com
Wed Jan 31 15:47:12 CET 2007


I'm banging my head over this one... sometimes it just works... *argh*

Here's a snip of my problem:

import win32com.client
import shutil
import time

engine = win32com.client.Dispatch("DAO.DBEngine.36")
table = 'STUFFTODELETE'
dstFilename = 'in.mdb'
workingfile = 'work.mdb'

shutil.copyfile(dstFilename, workingfile)

print 'Sleeping 5 after copy...'
time.sleep(5)

dstDb = engine.OpenDatabase(workingfile)

print 'Sleeping 5 after open...'
time.sleep(5)

dstDb.Execute('DELETE FROM ' + table)

At at *exactly* this line, I get the error:

C:\Python24\lib\site-packages\win32com\gen_py\00025E01-
0000-0000-C000-000000000046x0x5x0.py    510
com_error: (-2147352567, 'Exception occurred.', (0, 'DAO.Database', 'Not a
valid bookmark.', 'jeterr40.chm', 5003159, -2146825129), None)

Sometimes... Yes, the database is a %"#$"# MSAccess. This script is running
under windows.

Any ideas?

On 1/31/07, Hugo Ferreira <bytter at gmail.com> wrote:
>
> Well.. Thx for the answers.
>
> The only way I had to make it work was to use a time.sleep(10) after the
> shutil.copyfile(). Since this is a night-run script, I can waste 10
> seconds, but it still knocks me out "why" it happens...
>
> Cheers!
>
> Hugo Ferreira
>
> On 30 Jan 2007 18:06:15 +0000 (GMT), Matthew Woodcraft <mattheww at chiark.greenend.org.uk>
> wrote:
> >
> > Hugo Ferreira < bytter at gmail.com> wrote:
> > > I have a problem. I'm using calling shutil.copyfile() followed by
> > > open(). The thing is that most of the times open() is called before
> > > the actual file is copied. I don't have this problem when doing a
> > > step-by-step debug, since I give enough time for the OS to copy the
> > > file, but at run-time, it throws an exception.
> > >
> > > Is there anyway to force a sync copy of the file (make python wait for
> > > the completion)?
> >
> > shutil.copyfile() closes both files before it returns, so I suspect
> > this is an OS-level bug.
> >
> > The most likely culprits are buggy network filesystems and buggy
> > on-access virus scanners.
> >
> > -M-
> >
> > --
> > http://mail.python.org/mailman/listinfo/python-list
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20070131/af7d1044/attachment.html>


More information about the Python-list mailing list