Is there an existing issue for this?
Midnight Commander version and build configuration
GNU Midnight Commander 4.8.33
Built with GLib 2.84.3
Built with S-Lang 2.3.3 with terminfo database
With builtin editor
With subshell support as default
With support for background operations
With mouse support on xterm
With internationalization support
With multiple codepages support
With ext2fs attributes support
Virtual File Systems:
cpiofs, tarfs, sfs, extfs, ext2undelfs, ftpfs, shell
Data types:
char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; uintmax_t: 64;
Operating system
Linux blumenoid 6.18.12-gentoo #3 SMP PREEMPT_DYNAMIC Fri May 1 18:25:04 CEST 2026 x86_64 AMD Ryzen 7 7800X3D 8-Core Processor AuthenticAMD GNU/Linux
Is this issue reproducible using the latest version of Midnight Commander?
How to reproduce
- Take a bunch of big files, start copying the first one
- Abort during the copying process, choose Keep
- Select multiple files, starting with the one that was partially copied
- Start copying again. Choose Reget to append the rest of the first file
Expected behavior
All files should copy, first one should finish, the rest should be copied normally. Source and destination files should be exactly the same.
Actual behavior
After copying is finished the first file is the only one that matches the source. Every other file is shorter by the partial length of the first file when copying was aborted. All files were copied starting from the same offset as the first one.
Additional context
Serious data corruption, especially when copying disk images and not checking file lengths / checksums
Is there an existing issue for this?
Midnight Commander version and build configuration
Operating system
Linux blumenoid 6.18.12-gentoo #3 SMP PREEMPT_DYNAMIC Fri May 1 18:25:04 CEST 2026 x86_64 AMD Ryzen 7 7800X3D 8-Core Processor AuthenticAMD GNU/LinuxIs this issue reproducible using the latest version of Midnight Commander?
How to reproduce
Expected behavior
All files should copy, first one should finish, the rest should be copied normally. Source and destination files should be exactly the same.
Actual behavior
After copying is finished the first file is the only one that matches the source. Every other file is shorter by the partial length of the first file when copying was aborted. All files were copied starting from the same offset as the first one.
Additional context
Serious data corruption, especially when copying disk images and not checking file lengths / checksums