duplicity-team team mailing list archive

[Peter Schuller <peter.schuller@xxxxxxxxxxxx>]

> You're on FreeBSD, right?  

Yes.

> Are the semantics for file handling any
> different than Linux?  The reason I ask is that there may be a problem
> with the way I flush the file using the following sequence:
>         self.fileobj.flush()
>         os.fsync(self.fileobj.fileno())
> which should do the job completely, however, it looks like its not
> working on your system at all.  Is this possibly the problem?

I very very much doubt it. fsync() is extremely basic and it being
broken to that extent feels very very unlikely, or almost all serious
apps would be broken on FreeBSD. This is also on ZFS, so even without
any fsync there is a practical ordering guarantee (and besides,
fsync() would never matter except in the case of crashes anyway, or
possibly SIGKILL depending on kernel).

> It's possible that instead of flush(), we need to close and reopen,
> which is what i was trying to avoid because of the high overhead.

I'm not sure why you think this is the problem though. I mean it's
picking up empty files, and even if flush/fsync was somehow broken, a
killed duplicity would still be able to leave empty files behind on a
system where it wasn't. I'll check the source and see where that code
is from later on but won't be able to until tonight. I take it you're
saying some file is being created after another file should have been
written to but wasn't?

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@xxxxxxxxxxxx>'
Key retrieval: Send an E-Mail to getpgpkey@xxxxxxxxx
E-Mail: peter.schuller@xxxxxxxxxxxx Web: http://www.scode.org

Attachment: pgpM5tPqk9eG6.pgp
Description: PGP signature