this post was submitted on 21 Mar 2026
77 points (100.0% liked)
Open Source
45684 readers
441 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
- !libre_culture@lemmy.ml
- !libre_software@lemmy.ml
- !libre_hardware@lemmy.ml
- !linux@lemmy.ml
- !technology@lemmy.ml
Community icon from opensource.org, but we are not affiliated with them.
founded 6 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
i never understood this behavior. starting a large data transfer only to come back an hour later to find it halted at 5% due to some conflict. why not put those files at the end of the queue and resume with the rest?
It doesn't work that way. Conflicts are resolved before any transfer starts. The flow is:
Scan both sides and compare (compute file hashes or just compare mtime, no data transferred)
Show conflicts if any → you resolve them
Show copy/delete summary → you approve
Only then does the actual transfer begin. So you never come back to find it halted mid-transfer. All decisions happen upfront while it's just reading metadata, which is fast even for large trees.
This makes so much more sense than the Windows behavior.