1812788 - Downloading files with the same name overwrites the old file

Status: RESOLVED FIXED

(Firefox for Android :: Downloads, defect, P2)

Description

[Jeff Boek [:boek]]

From github: https://github.com/mozilla-mobile/fenix/issues/24346.

Steps to reproduce

1. Download a file, for example a picture named 001.jpg
2. Move the file to a different folder. For example, I used Simple Gallery
3. Download another file with the exact same name, in this case 001.jpg

Expected behaviour

The new file is saved in the Downloads folder. The original file is untouched.

Actual behaviour

The original file is overwritten by the new file, silently clobbering user data.

Device name

Moto G100

Android version

Android 11

Firefox release type

Firefox

Firefox version

97.1.1

Device logs

No response

Additional information

No response

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

Comment 1

[Jonathan Almeida [:jonalmeida]]

Triage: We verified this is still a reproducible bug.

To clarify the STR above, it seems that these are the actions happening:

1. Download 001.jpg to the default download path /Downloads/001.jpg.
2. Move /Downloads/001.jpg to /NewFolder/001.jpg.
3. Download another file with the same name 001.jpg.
4. Observe that /NewFolder/001.jpg is overwritten instead of a new file in /Downloads/001.jpg.

Assigning to self so we don't lose this bug report as we are currently setting up our bug management solution in Jira.

Comment 2

[Nicholas Poon [:Nick]]

I tried reproducing a different bug and got some unexpected behaviour that I believe may be related to this bug (also bug1812789, bug1825477, bug1852871):

Steps to Reproduce

1. Download the same file at least 2 times. I did it 3 times. You can use this site: http://xcal1.vodafone.co.uk/
2. Let one of the downloads finish to completion and pause the remaining ones.
3. Check the downloads folder to see that there is 1 copy of the downloaded file.
4. Cancel one of the other paused downloads and notice that the downloaded file in downloads is now gone. Note that there were instances where I had to hit cancel on all of the remaining paused downloads for this unexpected behaviour to be observed.

Expected Behaviour

The downloaded file is still in the downloads folder untouched.

Actual Behaviour

The downloaded file is deleted from the downloads folder. Please see the attached video for more details.

Device Name

Samsung A35

Android Version

Android 14

Comment 3

[Nicholas Poon [:Nick]]

Attachment: Screen_recording_20240610_155036.mp4

Comment 4

[Titouan Thibaud [:titouan]]

I can still reproduce this bug on Fenix 128, on a Pixel 7, Android 14.

STR

• Open this file on Fenix : https://pdfobject.com/pdf/sample.pdf
• Download it (clicking the Download button on the top toolbar)
• Open Files by Google app
• In the Files explorer, navigate to Downloads, create a new folder named, for example, "Bug", and move the sample.pdf file previously downloaded into this Bug folder.
• Open file informations (using the Three-Dots button on the right of the file), notice the "Last modified" time.
• Switch back to Fenix. Download the file again
• Switch back to the file Explorer. Open file information again, on the sample.pdf downloaded in the first step of the STR. Notice that the "Last modified" time has changed and is "now", meaning it has been overrided by the second download
• Navigate back to the Download folder. Notice that there's no sample.pdf file there.

Comment 5

[Chris Peterson [:cpeterson]]

This bug should be severity S2 because it causes data loss. A Reddit user reported seeing this bug yesterday. Saving a file will overwrite any existing file with the same name regardless of folder location.

https://www.reddit.com/r/firefox/comments/1hg28or/downloading_anything_on_ff_mobile_will_save_over/

Comment 6

[Jeff Boek [:boek]]

Hey Cathy, just noticed Chris elevated this to an S2. Just wanted to put it on your radar.

Comment 7

[Cathy Lu [:calu]]

One note is that with shouldUseScopedStorage() set to false, this bug is not an issue. Seems to be related to scoped access of download files.

Additionally, this bug can be reproduced when moving the downloaded file with Google Files, but not with Android’s file app. This indicates that while the Android file app updates MediaStore when a file is moved, Google Files may not. This could be an issue with Google Files but I'm not seeing any existing bugs filed in their issue tracker.

I tried adding an additional check here for the MediaStore to check for the file using the function below. That would at least rename the file to download(1).pdf instead of overriding the file in a different folder.

while (fileExistsInMediaStore(potentialFile) || potentialFile.exists() || fileNameExistsInCurrentDownloads(potentialFile.name, download, downloadJobs)) {
     potentialFile = File(path, "$fileBaseName(${copyVersionNumber++})$fileExtension")
}

fun isFileInDownloads(contentResolver: ContentResolver, fileName: String): Boolean {
    val projection = arrayOf(
        MediaStore.Files.FileColumns.DISPLAY_NAME
    )

    val selection = "${MediaStore.Files.FileColumns.DISPLAY_NAME} = ?"
    val selectionArgs = arrayOf(fileName)

    val uri = MediaStore.Downloads.EXTERNAL_CONTENT_URI

    contentResolver.query(uri, projection, selection, selectionArgs, null).use { cursor ->
        if (cursor != null && cursor.moveToFirst()) {
            // File exists
            Log.d("FileCheck", "File $fileName exists in Downloads folder.")
            return true
        }
    }
    // File does not exist
    Log.d("FileCheck", "File $fileName does not exist in Downloads folder.")
    return false
}

Comment 8

[Iorga Gabriel]

Attachment: Bug 1812788 - Downloading a file with the same name should not overwrite the old file.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/63c0c8b7bc9c
Downloading a file with the same name should not overwrite the old file. r=android-reviewers,calu

Comment 10

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/63c0c8b7bc9c