David Glasser wrote:
> Oh, huh. So, um, which FS is implementing the FS API correctly then?
> This sort of difference should not be externally observable...
Sometime after FSFS was added, this additional restriction on the API was
added to the docstring:
* The caller must send all delta windows including the terminating
* NULL window to @a *contents_p before making further changes to the
* transaction.
And, really, this restriction only makes any sense at all for FSFS, because
BDB doesn't care if you start sending some windows, then go off and do other
stuff, and then come back later to finish up the textdelta.
So FSFS enforces this requirement, though I suspect not explicitly. (If you
try to violate it, you get the generic error, "Cannot write to the prototype
revision file of transaction 'f00' because a previous representation is
currently being written by this process".) BDB doesn't even try, and really
has no way to do so.
So, in answer to your question, both FS APIs behave correctly if said APIs
are used as demanded by the docstring and no problems occur. If a problem
occurs such that the window-sending doesn't complete successfully, *and* the
FS API driver decides not to care and commit the transaction anyway, I
noticed that BDB would register text-mod changes on the file that was being
edited even though those changes never "took". Now, having just typed that,
I've looked into the FSFS code, and it records the change at the same time
that BDB did -- when editing was started, not when it was finalized. But I
don't know enough about FSFS to say if that leads to the same busted place
that BDB does, though, and I can't easily construct a test case that obeys
the API's documented rules *and* still triggers the problem.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=991039
Received on 2008-12-23 23:52:23 CET