On Tue, Apr 14, 2026 at 03:48:06PM +0100, Ian Jackson wrote: > This is sent to two bugs: > > #1133774 [dput-ng] sftp method silently overwrites files > #1130552 [dgit-infrastructure] want tag2upload to use dput-ng in sftp mode > > tag2upload would like a way of calling dput that will DTRT if the > network craps out halway through and the same command is run again. > I think probably many humans would like that too :-). > > I'm not sure precisely what scenario is being described as "uploads > were sometimes rejected because their .orig.tar had already been > removed" since the sftp method behaviour doesn't seem to involve > removing anything.
The sftp method itself doesn't involve removing anything, but the system as a whole does. The target of sftp will typically be some kind of queue. The thing processing the queue typically removes the upload when it's finished. If you have a shared queue directory (as I think most of these things do, with the exception of Launchpad), then that means that things can go wrong if you have two uploads in the queue at the same time that both mention the same .orig.tar file in their .changes. Having dput fail all but one of the uploads in that situation seems strictly better to me, since it allows outer systems to retry cleanly rather than apparently succeeding and then resulting in emailed error messages later. Having per-upload queue directories is strictly better for this purpose, but it's also rather a lot of effort to retrofit, perhaps even infeasible. And historically it hasn't been entirely without its downsides, since it normally means that people need to resume large uploads from scratch. (Of course, t2u offers a quite different solution to that problem.) > The whole dput (whether ftp or sftp) and queue daemon protocol is > rather janky. I don't know if it's possible to achieve my "retries > work every time" goal. > > Perhaps using sftp mode isn't the right answer for t2u but it's > difficult to see how to do better with anonftp. It would be a shame > if changes to dput-ng made it harder rather than easier to make > tag2upload more reliable in the face of network trouble. I'm certainly not trying to make t2u's life harder. With my proposal, would it be sufficient for t2u to just use `dput --force`? At the moment I believe that just has the effect of ignoring a pre-existing .upload file, which shouldn't make any difference for t2u, but it would communicate the "no really, I want to overwrite the previous attempt" intent to dput; and if a user needs to communicate the same intent outside of t2u, then they very likely also have a .upload file lying around, so piggybacking on the existing --force option seems like the right thing to do. -- Colin Watson (he/him) [[email protected]]
