Repository navigation
Ticket #5176: disable full file cloning when destination exists - #5178
Conversation
|
Tested on macOS with an FTP destination (default settings, file cloning enabled): overwriting an existing remote file now does |
…ation exists (MidnightCommander#5176) Signed-off-by: Phil Krylov <phil@krylov.eu> Signed-off-by: Yury V. Zaytsev <yury@shurup.com>
d27c00c to
6804370
Compare
Conflict in src/filemanager/file.c resolved in favour of upstream MidnightCommander#5178, which supersedes our earlier fix a201db8 (copy: don't remove a remote destination before file cloning).
|
the commit message is (again) totally unacceptable by my standards. that makes it rather hard to argue about the change. i'll do that in the issue instead. |
For me, a much more impressive revelation is that in the PRs that I have run through Claude so far, it seemed to always find a large number of data corruption and crasher issues. And these are not (only) pre-existing issues, of which there are more than enough, but the ones introduced in the new submissions. Also, this is putting all nitpicking aside - only genuine faults. None of that seems to be picked up by humans. Particularly saddening was the editor PR. On that backdrop, the commit message bickering just adds a layer of noise for me, unless it contributes to the crash suppression, which in theory it should, but in practice seems to not matter at all. At least this PR is more about saving the data than silently erasing the data, commit message notwithstanding. |
Proposed changes
The "full file cloning" copy path that is taken on MacOS and Oracle Solaris requires that the destination does not exist before the cloning attempt. Removing the destination before cloning has various undesirable effects described in #5176. So, don't attempt to clone when the destination already exists on these platforms.
Checklist
git commit --amend -smake indent && make check)