On Tue, Feb 04, 2020 at 11:54:01PM +1100, Ben Finney wrote: > Control: tags -1 + moreinfo > > On 04-Feb-2020, Mark Brown wrote: > > I recently attempted to use dcut to cancel an upload which > > someone had done with commands like
> > dcut ftp-master *zlib* > > This appeared to have succeded and produced no error message > As defined, the ‘dcut(1)’ command can only send commands to the > command server. Once the commands file is successfully sent, the > program succeeds and its execution is complete. If dcut is generating commands which produce no response from the server that seems like a really bad bug in dcut. > > but did not in fact result in the upload being cancelled which is > > somewhat irritating given that there's no way to inspect the upload > > queue. > That is unfortunate. I Think ‘dcut’ cannot do anything about that, > though, with the command server interface as is? If there is genuinely no way to guarantee a response from the server that seems like something where the dcut developers need to work with the archive people to ensure that there's a way to do that. > > I would expect that dcut would detect any errors that will not be > > being reported by ftp-master. > My understanding is that the channel to upload commands to the server > has no way for those errors to come back to the ‘dcut’ program as it > runs. Is this something the uploading program can detect? The program should at least know what the server requires in order to ensure that a response is generated and do local validation of those requirements. Even if it were to add some command that's guaranteed to report an error that'd be a massive improvement.
signature.asc
Description: PGP signature
