Version: 3.5.3 (using KDE 3.5.3 Level "a" , unofficial build of SUSE ) Compiler: Target: i586-suse-linux OS: Linux (i686) release 2.6.16.13-4-default When using konqueror to overwrite a file in sftp:// URL, the overwriting fails due to renaming failure in case the destination directory allows no writes, but the files itself does. sftp://server/dir has protection rxrxrx sftp://server/dir/file has protection rwrwrw Copying local file to sftp://server/dir/file fails, as konqueror tries a rename first, before writing file. These security mechanism is fine, but in case it fails a direct overwrite should be attempted (maybe after asking user).
Well, it would be possible to do that, but it will slow down copying even more. There is already a stat call and if I have to add another one, it will slow down things even more. Do you think this it it worth? I would prefer to close this bug as WONTFIX.
What about following: When writing failed, offer to try overwriting directly (only once/for all files). This will not change normal operation. The dialogs need anyway a bit of tuning. So writing failures (due to space shortages and so on) still do not allow a retry (e.g. when I deleted something to get space). So this bug is theoretically a "Implement better Retry" in reality.
I have to take a look if I can do something in the kio_sftp slave. The SlaveBase class should help to handle/fix this.
I am afraid this really doesn't make sense for sftp specifically. The behavior is perfectly in line with the rest of KIO. Protocols that support resuming will attempt to write $target.part. If it cannot write the .part file it will error out. It's the same for file:// and smb:// and all others that can resume. Adding bespoke retry logic to sftp specifically seems wrong here, in particular when file:// itself behaves as described from what I can tell. You can simply run `kcmshell5 netpref` and disable partial upload marking, which would then disable the .part tech and always write to the target file directly. That is not to say that I don't think the behavior could change, but that change would have to first be in the file protocol as it is kind of the gold standard for KIO's behaviour. In point of fact, CopyJob itself could force a retry with MarkPartial=false which would then force the protocol implementations to avoid the .part file altogether. Both of these opaque retries have the problem that they are messing with expectation though, the reason we have the partial tech is that should the transfer get interrupted the target file will not be half written. That would no longer be the case if we just randomly try to bypass the .part files. So, I am not exactly a fan of that. I'm bouncing the bug to KIO for dfaure to decide what to do with it.
I agree with Harald's reasoning. And this seems very very corner-case (a setup where one can't create new files, only overwrite existing ones). If it only bothered 2 users in 14 years, it seems OK to close this report. Reopen if you disagree...