On Sat, Dec 20, 2008 at 05:48:50PM +0530, Y Giridhar Appaji Nag wrote: > On 08/12/19 20:42 -0600, Steve M. Robbins said ... > > I have reconsidered: if a file exists on the server, I think the > > correct behaviour is to continue rather than aborting. > > > > Please consider the enclosed patch. > > Thank you for this patch. I think this behaviour is nice. > > However, in many cases, the file that is already present may have been > partially uploaded (in particular the last file that was uploaded)
A partial upload is precisely the situation that prompted my patch. :-)
In May, when I first thought about this, I was worried about having
a corrupt file on the server, as you suggest. But when it happened
again this week, I thought that probably the FTP server will delete
a file that wasn't completely transferred (so you don't really need
to worry).
I'm not sure which hypothesis is true. If you find out, please
let me know.
> it needs to be dcut and then dput again. I committed the patch to git
> with the message modified a bit to indicate this.
If the FTP server retains the corrupt/truncated file, then the
sequence is the following:
1. dput foo.changes
... fails partway through ...
2. submit dcut request
3. wait for acknowledgement by mail
4. dput foo.changes
Waiting (step 3) is crucial, since the dcut requests are handled in
batches by a cron job or similar.
If you don't wait, what happens is that the newly-uploaded file (step
4) is cut and you'll get a message from DAK or whatever about a
partially-uploaded package. I can tell you this from personal
experience. :-(
SO: if we need to consider this case, then the message for an upload
failure in step 1 needs to suggest *both* steps 2 and 3 before
re-trying the dput.
Regards,
-Steve
signature.asc
Description: Digital signature
