Hi Ben, On Sun, Jan 28, 2018 at 12:20:17PM +1100, Ben Finney wrote: > On 7-Sep-2011, Marc Haber wrote: > > Additionally, the chmod should be optional or configurable. It fails > > when the scp target account has its shell set to scponly.
> On 26-Sep-2017, Ansgar Burchardt wrote: > > The separate `chmod` call [after ‘rsync’ upload] can be replaced by > > `--chmod=F644` or `--chmod=ugo=rwX`. Please also include an option > > to *not* affect permissions and just use the default permissions. > > The ‘dput’ command currently forces a change of file permission (a > ‘chmod’ operation) when uploading via some methods. This is > undesirable in some environments. > > Implement configuration options to specify: I'm wondering if new options are not just extra effort. In which usecases is chmodding actually useful? Why not keep the default that the remote assigns? We just had some uploads fail, because: - scp is nowadays sftp - our remote does not allow starting shells, only sftp - when I set this up, dput just worked - when mika used it, it failed, because his -local- files were mode 0664 instead of 0644. And that's just a very strange failure IMO. tl;dr: can the chmod call just go away? Chris
