Transfers that were canceled are not deleted

[aronovgj]

1. Share on PC
2. Download in App
3. Cancel transfer on PC
4. Now you have a broken file in your download folder

[tfg13]

This should also affect the PC version, right?
The main purpose of the cancel button is to have a quick way to restart hanging transfers.
Since re-downloading overwrites the files, this never came up.

I'll look in this.

[aronovgj]

Yep, if sharing on smartphone the files are also not removed on pc.

[tfg13]

Not sure about this ticket. Currently, it does not delete cancelled transfers, because that may be pretty unexpected:

1. Start downloading multiple files / a directory.
2. Wait halfway, then cancel.
3. Situation: 50% of files were overwritten, 50% of files are still in the previous state.
4. ??? - What to do now? We can't revert the files to how they were before the transfer started, but I also don't want to delete files that existed before the transfer began.

[aronovgj]

If I want to overwrite a file I don't need it anyway. But you also don't need a broken file. Those are entirely useless. You can just as well delete them completely.

Another way would be this:
when overwriting create a new file first. Say the file you overwrite is file.txt. You create file.txt.lxc and after transfer is completed you delete file.txt and rename file.txt.lxc to file.txt. Else you remove file.txt.lxc

You would need double the free space of the file you want to overwrite

[tfg13]

Hmm maybe I explained that wrong.

If I want to overwrite a file I don't need it anyway.

I often do, because overwriting is updating. Granted, this is not super important for single files, but I often (re-)download full directories to effectively update their contents. And I definitively don't want anything to be deleted, just because I decide to stop the update.

Another way would be this: when overwriting create a new file first

I considered this a couple of times over the years, but my issues with this approach are:

• It requires twice the memory. What if there is not enough memory? I often share really large files. I experimented with features that "adapt" to the amount of free memory in the past, and that was inconsistent and confusing for most users.
• Writing to a secondary file and then switching only solves the problem for single files. I could implement something similar with directories, but the target directory may contain files the source directory doesn't - and switching would delete them.

Don't get me wrong: I don't think the current situation is very good and I do value your input. However, I spent quite some time thinking about some of these features, and some rather trivial sounding things turn out to be quite complex when directories are included in the mix.

While the current policy of "overwrite without asking, leave everything on cancel" might not be the best, it is at least simple and consistent for both directories and files.

[aronovgj]

I often do, because overwriting is updating. Granted, this is not super important for single files, but I often (re-)download full directories to effectively update their contents. And I definitively don't want anything to be deleted, just because I decide to stop the update.

But you end up with a broken file or inconsistencies anyway even if you want to update.

It requires twice the memory. What if there is not enough memory? I often share really large files. I experimented with features that "adapt" to the amount of free memory in the past, and that was inconsistent and confusing for most users.

You mean storage I assume. I don't have a solution for this. Usually if you don't have enough storage then you don't have enough storage. All the apps I saw tell you to free up space in these cases.

Writing to a secondary file and then switching only solves the problem for single files. I could implement something similar with directories, but the target directory may contain files the source directory doesn't - and switching would delete them.

You could implement a setting to let the user decide how to deal with this.

[tfg13]

But you end up with a broken file or inconsistencies anyway even if you want to update.

This is possible, yes.

I don't have a solution for this. Usually if you don't have enough storage then you don't have enough storage.

This is what frustrates me about the file-replacement solution. It requires double the storage, which means downloading files might no longer be possible when free storage is low. Even worse: LanXchange cannot know beforehand if a transfer might fail: Before the transfer, only the total file size of a directory is known. If free storage < directory size, the transfer might still be possible, but might also fail at runtime, because of a very large file. Blocking downloads unless free storage > total size works, but prevents transfers in cases where they would be possible.

Well, it is a surprisingly complicated issue with no easy solution, I need to think about this.