Am Donnerstag, 25. Januar 2007 12:40 schrieb Ph. Marek: > > Your path traversal patch was applied, so it does not reliably seem > > to fix the partial commit problem. > That's really strange.
I think I can trigger it - the first commit after a sync-repos commits
files / directories outside of the specified partial commit directory.
Please see the attached test case. Even with a fully patched 1.0.15, it
outputs the following at the end:
# fsvs-1.0.15 sync-repos
Nm.. 5 ./dir1/1/Datei3
Nm.. 72 ./dir1/1
N... 96 ./dir1
Synchronized to revision 2.
(...)
# fsvs-1.0.15 ci -m ci11 dir1/1
..C. 96 ./dir1
N... 72 ./dir1/2
N... 6 ./dir1/2/Datei4
N... 5 ./Datei1
N... 5 ./Datei2
committed revision 3 on 2007-01-25T23:57:06.980444Z as gunter
So I commited your patch, extended the test script by a new testcase which
fails without and works with it, and I tried to add a test case which
reproduces this behaviour from the separate test case script I attached.
This failed, however, instead fsvs aborts with caught ENOENT and I do not
really understand why... Probably some dumb blunder from my part. I
disabled this last test by an "if false" block, but included it in my
commit anyway.
> >> Please commit the other patch, too ... I'd like to update and have
> >> it, too
I committed both patches.
Concerning commit performance, the log files I collected show the
following for a partial commit:
waa__read_or_build_tree[waa.c:1714] read tree = 0
waa__partial_update[waa.c:1981] update 0=dirA/dirB
hlp__lstat[helper.c:315] dirA/dirB: uid=1000 gid=1000 mode=040700
dev=0x807 ino=394755 rdev=0x0 size=192
ops__find_entry_byname[est_ops.c:674] found dirA on 0x80fedcc; ignored:
0x1
ops__find_entry_byname[est_ops.c:674] found dirB on 0x80fede0; ignored:
0x1
waa__update_tree[waa.c:1593] doing update for . ... 1 left in 0x80653ac
After that it starts to scan all entries in the repository, not just the
entries below. This does not seem to cause network transfers, but still
takes a while with my managed directory.
I had a look at the code in waa.c, but wasn't entirely sure what was
supposed to happen there. waa__update_tree first builds an in-memory tree
of the entiry working copy and filters it to the partial commit
directories after this step?
The extreme slowdown with continuous low bandwidth network traffic may
have been caused by the sync-repos problem mentioned above, but I'm not
yet sure. I'll keep an eye on it. Some operation fsvs performed extremely
often required a server roundtrip, which slowed everything to a crawl.
> > if it doesn't I'll try to figure out test cases to
> > provoke the misbehaviour.
> Why not just fix the problem ;-?
Well, I'll do if I can, but as I said I'm really occupied ATM and I'm
currently happy I finally found some hours to analyze this annoying
partial commit "break out" behaviour... ;)
Besides that, I'll see what I can do.
Greetings,
Gunter
--
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Nach uns der Syn-Flood!"
-- Autor unbekannt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ PGP-verschlüsselte Mails bevorzugt! +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
testcase_pci.sh
Description: application/shellscript
pgpCa1Pb5LWKL.pgp
Description: PGP signature
