Icedrive_Portable_Win_x64.exe sha256 of the EXE file 0A1AFFB436CA1269F002F56FE431C17DD52DB81EEB84D7016143884D62589D16
Windows 11 Home
Issue
For some reason I have frequent Transfers errors, reported like “Upload Error”. I’m currently in an area with poor internet access and I need reliable access to my files. It makes me anxious to use this Application as I never trust whether my files are uploaded or downloaded correctly and completely.
I request a feature in Settings (it should be enabled by default to like 3 attempts) to have like a number of retries to perform a transfer operation, between 0 and infinity (possibly with some configurable delay functionality between transfers attempts).
For downloading I worked around it with sync functionality from the another Application, as it seemed more reliable for retries of transfers.
Question, do you check the files whether they are uploaded/downloaded correctly by size+checksum? If there is no control of integrity of the files I request to address it promptly.
The application seems careless with this problem. Recently I spent 3 full-days full-time trying to download my IceDrive file collection. Every then and now I had to manually reset the software to try to resume/retry the file transfer. Now, on upload it looks like the situation is same or more stressful.
Update:
I just check files before uploading and after uploading+downloading.
Example original file:
Size 11773358 bytes (11 MiB)
CRC32 123ABF12
After upload + download:
10670734 bytes (10 MiB)
CRC32 72A1A8A7
The computer (RAM, disk) are flawless. Right now this problem is fatal to me and I need to hold on updating my files until this problem is resolved.
I think that download/upload restart on transfer failures (configurable number of attempts and delay between them) + integrity check for file/directory sync would do the job.
Right now I get a report that e.g. IMG1.jpg was failed to be fully uploaded, icedrive still keeps malformed file in the cloud and due to a generic name I am not able even manually simply get idea which file has to be reuploaded manually. This is hit and miss and a losing battle leading to unhappy ending.
For sync, I realize that getting crc32 or similar from a file might be CPU cost of the cloud infrastructure, but it’s still better than forcing a user to do a cycle of upload+download to do the integrity check manually. In the case of encrypted data just checksum the encrypted files and encrypt+checksum on the client side. This can be configurable in the application.
Another idea of avoiding file loss is that once a file transfer was interrupted, then just delete it - both for upload from the cloud storage and from download from a local device.
At least checking file size would be a good start as I think most malformed file transfers would be just truncated. The rest handles TCP.
Please keep me updated as I am depending on this with my potential further usage of my subscription.
I think the simplest method to transfer files and avoid truncated data is to first transfer them to a file with a different name like with a suffix .part and then after a successful transfer perform atomic file rename.