Skip to content

Ticket #5176: disable full file cloning when destination exists - #5178

Merged
zyv merged 1 commit into
MidnightCommander:masterfrom
tuffnatty:cloning-by-path-early-removal
Oct 10, 2026
Merged

zyv merged 1 commit into
MidnightCommander:masterfrom
tuffnatty:cloning-by-path-early-removal

Conversation

@tuffnatty

Copy link
Copy Markdown
Contributor

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

  • I have referenced the issue(s) resolved by this PR (if any)
  • I have signed-off my contribution with git commit --amend -s
  • Lint and unit tests pass locally with my changes (make indent && make check)
  • I have added tests that prove my fix is effective or that my feature works
  • I have added the necessary documentation (if appropriate)

@github-actions github-actions Bot added the needs triage Needs triage by maintainers label Oct 10, 2026
@github-actions github-actions Bot added this to the Future Releases milestone Oct 10, 2026
@github-actions github-actions Bot added the prio: medium Has the potential to affect progress label Oct 10, 2026
@gereoffy

Copy link
Copy Markdown
Contributor

Tested on macOS with an FTP destination (default settings, file cloning enabled): overwriting an existing remote file now does STOR with the new content, no DELE, so the data loss from #5176 is gone. Overwrites go through the normal O_TRUNC path again, which also keeps owner/permissions/hard links of local destinations. LGTM, thanks!

@zyv zyv changed the title Disable cloning on MacOS and Solaris when destination exists (#5176) Ticket #5176: disable cloning on MacOS and Solaris when destination exists Oct 10, 2026
@zyv zyv changed the title Ticket #5176: disable cloning on MacOS and Solaris when destination exists Ticket #5176: disable file cloning when destination exists Oct 10, 2026
@zyv zyv changed the title Ticket #5176: disable file cloning when destination exists Ticket #5176: disable full file cloning when destination exists Oct 10, 2026
@zyv zyv added area: core Issues not related to a specific subsystem and removed needs triage Needs triage by maintainers labels Oct 10, 2026
@zyv zyv modified the milestones: Future Releases, 4.9.0 Oct 10, 2026
…ation exists (MidnightCommander#5176)

Signed-off-by: Phil Krylov <phil@krylov.eu>
Signed-off-by: Yury V. Zaytsev <yury@shurup.com>
@zyv
zyv force-pushed the cloning-by-path-early-removal branch from d27c00c to 6804370 Compare October 10, 2026 15:33

@zyv zyv left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, folks!

@zyv
zyv merged commit fa8105c into MidnightCommander:master Oct 10, 2026
10 checks passed
gereoffy added a commit to gereoffy/mc that referenced this pull request Oct 10, 2026
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).
@ossilator

Copy link
Copy Markdown
Contributor

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.

@zyv

zyv commented Oct 10, 2026

Copy link
Copy Markdown
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: core Issues not related to a specific subsystem prio: medium Has the potential to affect progress

Development

Successfully merging this pull request may close these issues.

Overwriting a file on a remote VFS deletes it without copying the new one (macOS, Solaris: file cloning)

4 participants