File corruption when overwriting files in export

[v-kawade]

If NativeFilePicker.ExportFile() overwrites an existing file (XML) with contents of a smaller size, the contents of the existing file will remain and the file will be corrupted.

• Unity version: 6000.1.2f1
• Platform: Android
• Device: 'Xiaomi Pad 6' and 'Xperia 5II'
• How did you download the plugin: Asset Store (v1.4.0)

[yasirkula]

If original XML (A) was 50 KB and the new XML (B) is 20 KB, is the resulting XML 70 KB (A+B) or the first 20 KB of A is replaced with B while the remaining 30 KB of A remain the same (i.e. a 50 KB output)?

[v-kawade]

Hi, thanks,

• The original XML (A) was 6,153 Bytes.
• The new XML (B) is 4,011 Bytes.
• The resulting XML is first 4,011 Bytes of A is replaced with B while the remaining 2,142 Bytes of A remain the same.

[yasirkula]

I've found out that this is a common problem:

• writeFile() not truncating file contents on Android 10 itinance/react-native-fs#837
• Overwriting existing file during export doesn't properly work AntennaPod/AntennaPod#5819
• etc.

I think this is a stupid default behaviour. Thank you for bringing this to my attention. I'll hopefully release a fix in a couple of days.

[yasirkula]

Please let me know if the issue persists in v1.4.1.

[v-kawade]

Thanks. I have confirmed that the problem has been resolved in v1.4.1.
For reference, when overwriting an existing file, the 'Xiaomi Pad 6' no longer confirms the overwrite and the file name now ends with a (1) or something similar.
'Xperia 5II' has the same overwrite confirmation as before and exports correctly with the original file name.

[yasirkula]

This change shouldn't affect the overwrite dialog because the changed code takes place after the overwrite dialog.

[v-kawade]

'Xiaomi Pad 6', when calling ExportFile() with an existing file name, (1) was given without confirmation if the file browser did nothing and OK, and there was an overwrite confirmation when the same file name was selected in the file browser.
I see. This behavior seems to have been the case originally.

[yasirkula]

I think this behaviour depends on the device vendor: https://developer.android.com/training/data-storage/shared/documents-files#create-file

Note: ACTION_CREATE_DOCUMENT cannot overwrite an existing file. If your app tries to save a file with the same name, the system appends a number in parentheses at the end of the file name.

For example, if your app tries to save a file called confirmation.pdf in a directory that already has a file with that name, the system saves the new file with the name confirmation(1).pdf.