Strange -u t behaviour

[Digital Parasite]

I have been uploading my offline machine buffered structures in preparation for the protein changeover tomorrow but I noticed a strange behaviour with the DF client when using -u t.

It will be uploading the fileset 12/346 and everything runs fine, and it got as far as 320/346 when all of a sudden the machine crashed. I know the DF client had nothing to do with the crash, but what suprised me was that all 346 buffered files were still on the hard drive. I would have thought they'd get deleted after being uploaded and verified. So when I started the DF client again with -ut, sure enough it started over from teh beginning 1/346.

Is that the intended behaviour?

Jeff.

[Paratima]

Probably not wholly intended, but I've noticed it also. The old gens just kinda hang around until the last one gets verified, then *whoosh*, off they go. AND whatever it is that counts them doesn't update until the end. I thought that would cause problems if the load got interrupted. Now I know. I'm pretty sure it's been reported before, too. Seems like a strange way to handle it. :rolleyes:

Maybe Howard/Elena can put that on the TODO list, if it isn't there already.

[Brian the Fist]

Hmm, sounds like a bug but we'll have to try it ourselves and see whats going on.

[bwkaz]

It's pretty easy to replicate -- run the client in -if mode for a bunch of generations, then notice how all the result files build up in the directory you run it from. Then restart it in -ut -it mode, and watch the files not go away until the end of the uploading. ;)

It doesn't cause any problems, I don't think (other than X number of gens worth of 910 errors when we try the second upload, because the files have already been processed).

[Xelas]

It doesn't cause any problems, I don't think (other than X number of gens worth of 910 errors when we try the second upload, because the files have already been processed).

It just wastes oodles of time, especially when uploading 400+ gens over a 31.2K dialup link, and the machine borks on gen #309. Yay! Another 2 hours babysitting the machine. :crazy:

It also causes unneccessary traffic for the blueprint site . . . .:rolleyes: