When Warpinator reports “Transfer Failed,” record whether the transfer never started, stopped partway through, or finished but produced an unexpected result. That distinction helps avoid changing network settings for a receiving-folder problem.
Preserve the original and read both screens
Keep the source file until you have checked the received copy. Record the exact message on the sending and receiving devices, the file size, the destination folder, and the point at which the transfer failed. Do not assume a partial destination file is complete.
| Observed behaviour | First investigation |
|---|---|
| The peer never becomes ready | Connection troubleshooting, before file-specific changes. |
| A small file works but one large file fails | Destination storage, free space, removable-drive limits, and interruptions. |
| One file fails repeatedly but others work | Source readability, filename/path, permissions, and the exact error. |
| Only folders or multiple selections fail | Client feature support and whether one particular item triggers the failure. |
1. Check the destination directly
On the receiver, confirm that the selected drive is still mounted and that you can create a small local file in the destination folder. Check free space on that drive, not just on the system drive. If a removable disk is involved, check its filesystem and single-file limits.
For a sandboxed application, the folder visible inside the app may not be the folder you expected. Re-select an accessible receiving folder through the application’s own controls and retry with a non-sensitive test file. Avoid granting access to your entire filesystem as an initial workaround.
2. Isolate the failing item
Try a small file from the same source folder. If that works, try the original item by itself. Confirm you can open or copy the source locally. A failure limited to one item is a reason to inspect that item; it is not proof that it is corrupted.
For a folder, narrow the selection in smaller groups. Note whether a name, deep path, or unsupported item type corresponds with the failure. Keep the original structure intact while investigating.
3. Check interruptions
Note whether either device slept, changed networks, lost its removable storage, or closed the receiving app. Repeat one short test with both devices active. If it works only in that condition, investigate power or background restrictions for the specific client rather than disabling restrictions globally.
4. Reproduce once with useful evidence
Record both app names and versions, the failed filename or a harmless equivalent, and the receiver’s storage type. Use the client’s documented logging option and reproduce a single failure. Redact personal paths and group codes before sending logs to its maintainer.
5. Verify completion
After a successful retry, compare the size and open the destination file. For important data, compare a checksum with an appropriate tool on both endpoints. Do not delete your source merely because a progress indicator reached 100%.
For consistently slow but successful transfers, use the measurement guide. Report errors in this article to Warpinator Guide Team.