Hi Steve, On 08/12/20 12:26 -0600, Steve M. Robbins said ... > 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.
Partial FTP uploads are allowed by the FTP protocol and the FTP server
will not delete them.
> 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. :-(
That is right. And it is important to re-instate the full file before
the .changes is uploaded.
> 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.
Certainly. I tried to clarify this a bit but struggled to not make the
diplayed message excessively long. Does the following message that I
just committed to git look OK?
Leaving existing %s on the server and continuing
NOTE: This existing file may have been previously uploaded partially.
For official Debian upload queues, the dcut(1) utility can be
used to remove this file, and after an acknowledgement mail is
received in response to dcut, the upload can be re-initiated.
Cheers,
Giridhar
--
Y Giridhar Appaji Nag | http://people.debian.org/~appaji/
signature.asc
Description: Digital signature
