MoveFile_bug.aia (19.6 KB)
MoveFile ASD/perro_50.png to ASD/animal.png works (the first time)
MoveFile ASD/gato_50.png to ASD/animal.png crash app because the animal.png file already exists.
MoveFile_bug.aia (19.6 KB)
MoveFile ASD/perro_50.png to ASD/animal.png works (the first time)
MoveFile ASD/gato_50.png to ASD/animal.png crash app because the animal.png file already exists.
One solution would be to delete the destination file before moving it.
BTW, we can delete a file that doesn't exist without getting an error.
I have not looked at the sources, but when a file is created (such as with move) there should be a flag/option set (to "false") to allow an existing file to be overwritten.
Yes, this is another bug. You must
Btw, the same with Niotron.
Yes, but for whatever reason, that's not the case.
I tried
TaifunFile
with the async move block (and this works).
I was just working on some file related issues yesterday so I'll try to see if we can get this taken care of.
@Juan_Antonio Which version of Android are you testing on? There is different logic for Android 8 and later versus earlier versions of Android.
I checked it now on Android 5, 9 and 11 (Companion).
Only on Android 5 it works.
On Android 8.1.0 it does not work.
Android 9
A lot of the Java NIO functionality was added in Android O (SDK 26). The benefit of this functionality is that it can defer to the OS and filesystem level to perform the operation in the most effective way possible.
For earlier versions where we don't have this benefit, we've implemented the fallback logic needed to make it work. To do it safely we have to copy the file first in case that we need to roll things back in case of failure during the operation. Otherwise, we can end up in a situation where the target file is deleted but the move part fails and now data have been lost (which ideally should never be the case).
Ok, but I've done it hundreds of times on dozens of devices and all Android versions with the TaifunFile
extension and never had any problems.
It's expected that the success condition is the most prevalent though. I think we'd be all hard pressed if moving files in any context was bound to fail more than succeed. The real challenge is accounting for the corner cases that might come up which is what the code for older Android versions represents. However, everyone has reported using a newer version of Android so the Java NIO path is the one that's taken. The issue was that we were not passing the necessary flag to overwrite the destination, and, as was pointed out, this could be worked around by deleting the destination first.
In any case, the change that fixes this issue is now an open PR on GitHub: