Repository navigation
Warpinator may delete files on receiver after interrupted transfer #240
Description
Distribution
Linux Mint 22.3
Package version
2.0.2+zena
Frequency
Always
Bug description
Warpinator can cause accidental data loss on the receiving device after an interrupted transfer.
If a file transfer is interrupted and later resumed, Warpinator may delete files on the receiving device that no longer exist on the sender, even though the user only intends to send files, not synchronize or delete them.
This behavior is unexpected and potentially dangerous, especially on mobile devices.
Steps to reproduce
-
Send files from Device A (mobile) to Device B using Warpinator.
-
Start sending the same files again from Device A to Device B.
-
Stop the transfer by denying/canceling the request.
-
On Device A, delete or move some of the previously sent files.
-
Send files again from Device A to Device B.
-
Warpinator shows the warning:
“Files may be overwritten.”
-
Accept the request.
Bugous result
Files that no longer exist on Device A are deleted from Device B, resulting in data loss.
Impact
- High risk of unintentional data loss
- Especially problematic for mobile usage where interrupted transfers are common
- Behavior is not clearly communicated to the user
Suggested Improvements
- Never delete receiver files by default.
- Add a clear confirmation dialog if deletions are about to occur.
- Treat transfers as copy-only, not synchronization.
- Improve warning message to explicitly mention possible deletions.
Environment
- App: Warpinator 2.0.2+zena / Warpinator for Android1.8.5
- Devices: Mobile → Desktop
Expected behavior
- Warpinator should never delete files on the receiving device unless the user explicitly confirms a delete or synchronization operation.
- Interrupted transfers should not lead to implicit file removal.
- The overwrite warning should not imply deletion of missing files.
Additional information
No response
Activity
mtwebster commentedon Nov 6, 2026
Warpinator is not a sync or merge tool. When you send a file or folder, the item with that name in the receiver's save folder is replaced with what the sender has. That is what the "Files may be overwritten" prompt is warning about, and it's why that prompt requires approval by default.
In your steps, once files were deleted from Device A (step 4) and the same folder was sent and accepted again (steps 5-7), the copy on Device B was replaced by a copy that no longer contains those files. The receiver can't treat the incoming folder as an update to the old one, because it has no way of knowing whether it's the same folder, a different folder with the same name, or something malicious using that name on purpose.
Both behaviors are deliberate and came out of the security hardening done for CVE-2022-42725 and CVE-2023-29380. The sender controls every path and symlink in a transfer, so each transfer has to start from a clean location that only its own data created. Writing into a tree that already exists lets one transfer redirect the files of another, which is why treating a transfer as a merge (#263) isn't an option.
I'll consider maybe changing the wording around the warning prompt (item will be replaced, not just that files may be overwritten), but the behavior needs to remain.