Navigating files/folders through other apps produces double listings or shows no content at all. #17051

Activity

1. RobertZenz

   added

   bug

   0. Needs triage

   on May 14, 2026
2. xundeenergie commented on May 24, 2026

   

   xundeenergie

   on May 24, 2026

   Last edited by xundeenergie

   More actions

   I have the ssme problrm on all my devices with graphene-OS.

   When i view folders containing images, the images are shows only once in the folder.
   Then i open an image, the app tries to open the image... and stuck. I swipe to the next image, and the first is shown. I swipe back, and it is shown again.
   It happens to almost all images.
   Viewing an image shows it twice, while swiping through the images.

   When i try to attach an image to an upload-website and i use the filebrowser sn choose "nextcloud" app, all folders and images are shown twice in this browser

   

   But this happens NOT on all folders!
   As you can see here

   

   Sometimes, when i move images on the server to a new location, they are shown only once.
   Newly uploaded are shown always twice.

   I thought it started with changing to nextcloud aio on the server, but i can verify it with my bare metal installation too.

   The behaviour of loading (not loading the first try, swiping to the next and see the first, seiping back, see it a second time) let me think, that the app loafs a preview an shows ist, and the load the preview again and shows it a second time.

   This only happenswith the nextcloud app (android). Memories shows images only once.
   It happens also with nextcloud-dev app on android!
3. xundeenergie commented on May 25, 2026

   

   xundeenergie

   on May 25, 2026

   Last edited by xundeenergie

   More actions

   I think it's a caching problem eith slow connection, that the app shows images snd folder twice.

   I added my old nextcloud again to the app and viewed some photos there.

   Some images are loaded instantly snd they are shown only once.
   Then i had an image, ehich took 3 seconds to be loaded... and it is shown twice.
   The next image was loaded fast, it is shown only once.

   The folder itself was loaded very fast eith sll its preview images.

   I opened another folder, which took 10 seconds and more and shows nothing. An empty folder.
   Step one folder up, and again down.
   Now it also took several seconds, then the content was shown and thumnails are loaded.
   Now i open sn image and swipe through the next image... each and every image in this folder now is shown twice.

   Went back to the first folder, each image is shoen only once, exept the one, which took longer to be loaded. This is again shown twice.

   The nextcloud app notifies in android "an error occured on downloading" several times. I think for each image and folder, which took longer and is shown on the next try twice. But the error-notifications don't say on ehich element the error occured.
4. danielw01 commented on Jun 13, 2026

   

   danielw01

   on Jun 13, 2026

   More actions

   have the same issue when browsing nextcloud content from grapheneos built in file browser

   nc_bug.log

   👍React with 👍1Reacted by Peter Pablo
5. Kompanjero commented on Sep 27, 2026

   

   Kompanjero

   on Sep 27, 2026

   More actions

   I am experiencing very similar symptoms with Nextcloud Android 35.0.0 on all three of these devices:

   • Lenovo Yoga Tab 13 (YT-K606F), Android 13, build YT-K606F_S510234_231224_ROW
   • Lenovo TB-J616F, Android 12, build TB-J616F_S240253_241016_ROW
   • BL6000Pro, Android 11

   The exact Nextcloud server version is currently unknown.

   Folders appear multiple times when accessing Nextcloud through Android's Storage Access Framework (SAF). The normal Nextcloud app displays them correctly. On the Yoga, one folder entry works while another entry with the same name appears empty. Triple entries have also been observed on the TB-J616F.

   Controlled reproduction on the Yoga

   1. Open the Android file picker from Collabora.
   2. Select the Nextcloud account.
   3. Open the working folder entry.
   4. Go back to the parent directory.
   5. Open the duplicate entry, which appears empty.

   Additional finding from ADB logcat

   Two different document IDs with the same account prefix resolve to the same remote folder path. The folder name is anonymized below as /Example/:

   • 13:09:31.704: queryChildDocuments() for document ID ending in /214834. The subsequent reload resolves to /Example/. This is the working entry.
   • 13:09:35.147: navigation back to the root, document ID ending in /214827.
   • 13:09:41.589: queryChildDocuments() for document ID ending in /214843. The subsequent reload resolves to the same /Example/ path. This entry appears empty.

   Both entries trigger PROPFIND requests for the same WebDAV path.

   Even after opening the empty entry, the log reports HTTP 207 (success) and saves the folder with 9 children and 0 files to remove. Child queries and folder refreshes then repeat several times.

   Resetting DocumentsUI did not resolve the issue. Direct inspection of the app database was not possible because the installed package is not debuggable.

   This may be related to the issue reported here, but we have not established the root cause. In particular, duplicate local records or incorrect parent/child associations remain hypotheses, not confirmed findings.

   Would a sanitized log excerpt covering both document IDs and their refresh operations help investigate this?
6. NotMilk commented on Oct 6, 2026

   

   NotMilk

   on Oct 6, 2026

   Last edited by NotMilk

   More actions

   This is happening to me, Samsung S24 Ultra - deleting cache, and data solves for a few minutes if I am lucky.

   

   If there is additional data I can provide, LMK. Looks like there are already a lot of contributors pointint this one out.

   👍React with 👍2Reacted by theo-ger and xundeenergie
7. PeterPablo commented on Nov 9, 2026

   

   PeterPablo

   on Nov 9, 2026

   Last edited by PeterPablo

   More actions

   One datapoint that may narrow this — two SAF consumers against the same Nextcloud root, same device, minutes apart:

   Environment: HONOR 200, Android 16 / MagicOS 10 (10.0.0.167) · Nextcloud 35.0.2 (the app reports the same version string) · Material Files 1.7.5 (40) · Twig 1.17.0.

   • Twig, browsing the Nextcloud account from / as external storage: folders list normally, no duplicates, contents open.
   • Material Files, same root, added via Speicher hinzufügen → Externer Speicher → Nextcloud → „Diesen Ordner verwenden": the root arrives as / and every folder is listed twice. Opening either copy fails with
     java.nio.fileSystemException: /tmp: java.lang.InterruptedException
     — no further detail in Material Files' error dialog.

   What does work: selecting a subfolder in the picker instead (here tmp) and adding that. It then browses normally, documents open in the editor, and — for what it is worth — a save from that path does reach Nextcloud (new size, new version).

   So in our case the tree is fine and one consumer reads it correctly, while the other gets doubled entries and an exception on open. That reads like a query/listing pattern the provider answers wrongly rather than a broken tree — maybe the duplicated queryChildDocuments result is what the second consumer then trips over. Happy to run a debug build or hand over logs if that helps; the exception above is reproducible on demand.

   ---

   #AI-ASSISTED — comment drafted with AI assistance; every value above was read off the device or our server; the two results come from separate sessions on the same day.

   ❤️React with ❤️1Reacted by xundeenergie
8. PeterPablo commented on Nov 9, 2026

   

   PeterPablo

   on Nov 9, 2026

   More actions

   A correction to my own datapoint above (Twig "no duplicates"), because I have since measured it properly and it was wrong — or rather, it was measuring a different source:

   Twig's own WebDAV mount never doubles; the SAF document tree does. Same phone, same hour, both mounts of the same account: a WebDAV mount of the same Nextcloud account (webdav://cloud.example.org/remote.php/dav/files/<user>/) lists every folder once, while Dokumentenbaum (SAF) → Nextcloud lists each top-level folder twice (identical name and identical mtime) — exactly like Material Files.

   That comparison also localises the defect, which may save someone a bisect: Twig maps the provider cursor 1:1. Its listing is a single query —

   DocumentsContract.buildChildDocumentsUriUsingTree(dirUri, DocumentsContract.getDocumentId(dirUri))
   resolver.query(childrenUri, PROJECTION, null, null, null)

   — and one output row per cursor row, with no merge and no second source. So a duplicated folder on screen means the cursor contained it twice, i.e. the provider handed out two rows for one directory entry.

   Where that can come from, from reading stable-35.0.2: queryChildDocuments walks storageManager.getFolderContent(parentFolder.getFile(), false), which ends in the Room DAO's

   @Query("SELECT * FROM filelist WHERE parent = :parentId ORDER BY …")
   fun getFolderContent(parentId: Long): List<FileEntity>

   A plain select with no join — it can only return a directory twice if filelist holds two rows with the same parent and filename. That fits the "clear app data and it is fine for a while" reports as well: a rebuilt database has one row each.

   I cannot read the app's database on a release build (no run-as), so I have not proven the duplicate rows — it is a prediction with a specific next test: count rows for one folder in a debuggable build. Happy to file that separately rather than guess here.

   #AI-ASSISTED

   ❤️React with ❤️1Reacted by xundeenergie
9. PeterPablo commented on Nov 9, 2026

   

   PeterPablo

   on Nov 9, 2026

   More actions

   Root cause, from the source at stable-35.0.2 — it is the provider handing out two rows for one entry, and the chain is three facts:

   1. filelist has no unique index. The Room schema (app/schemas/com.nextcloud.client.database.NextcloudDatabase/106.json) declares _id INTEGER PRIMARY KEY AUTOINCREMENT and zero indices. Nothing in the database forbids two rows for the same file.

   2. FileContentProvider.upsertSingleFile cannot ever resolve a conflict. It starts with db.insert(FILE_TABLE_NAME, CONFLICT_IGNORE, values) and only falls back to UPDATE … WHERE path=? AND file_owner=? if that insert fails. The values come from createContentValuesBase, which does not put _id — so with no constraint to violate the insert always succeeds, and the update branch is unreachable from saveFile. For these writes the function is insert-only, whatever its name says.

   3. The only thing preventing a twin is an inexact pre-check. FileDataStorageManager.saveFile guards with fileExists(path) → getFileByEncryptedRemotePath(path, accountName) — an exact string match, filtered by account name. The same class's getFileByRemotePath explicitly tolerates a missing trailing slash (path, then path + "/"). Two writers that disagree about /tmp vs /tmp/, or about the account name, both pass the guard and both insert.

   The read side has no safety net either: SELECT * FROM filelist WHERE parent = :parentId — no owner filter and no DISTINCT. A consumer that maps the cursor 1:1 (which is what the twig app I tested does) therefore shows the folder twice, while the same content is fine everywhere the rows are keyed by path.

   What a fix would look like, in that order: (a) make upsertSingleFile an explicit update-or-insert by (path, file_owner) instead of relying on a conflict that cannot happen; (b) a migration that deduplicates the table and then adds a unique index on (path, file_owner), so the invariant lives in the database rather than in every caller's memory; (c) filter getFolderContent by owner for good measure.

   What I have not proven: which writer produces the twins on a given device, and whether the app's own list is genuinely clean — there is a distinctBy { remotePath } in OCShareToOCFileConverter, but the plain list path has none, so "the app shows it correctly" may be an observation rather than a difference in code. A debuggable build with two SELECT count(*) … WHERE parent=? AND filename=? would settle both.

   #AI-ASSISTED

   ❤️React with ❤️1Reacted by xundeenergie
10. PeterPablo

    added a commit that references this issue on Nov 9, 2026

    fix: one row per file — unique (path, file_owner) index on filelist

    ...

    This issue will close once commit 1284892 is merged into the 'master' branch.

    1284892
11. PeterPablo commented on Nov 9, 2026

    

    PeterPablo

    on Nov 9, 2026

    More actions

    Proposing a fix for this: #18001 — one row per file: unique (path, file_owner) index on filelist.

    It does not add another guard on the read path; it makes the invariant hold in the database:

    • migration 106 → 107 collapses the duplicates that already exist (the oldest _id per path/file_owner wins, rows without a path are left alone) and then creates UNIQUE INDEX idx_filelist_path_owner ON filelist (path, file_owner) — declared on FileEntity as well, because Room builds a fresh database from the entity and the migration only reaches installs that already exist;
    • upsertSingleFile falls back to the stored row when the insert is refused by that index, instead of returning a URI ending in -1.

    That is the part that matters for the reports in this thread: no code-side fix removes duplicates that are already on a device — clearing app data was the only cure. With the migration they are gone on the first start after the update.

    Verified with a migration test plus the existing provider tests on an Android 16 emulator, and on a device against a second build installed beside the current app; details in the PR.

    #AI-ASSISTED

    👍React with 👍1Reacted by xundeenergie
12. xundeenergie commented on Nov 11, 2026

    

    xundeenergie

    on Nov 11, 2026

    More actions

    Is this possibly the reason, why directory-listings are deadly slow in many cases?
13. Kompanjero commented on Nov 12, 2026

    

    Kompanjero

    on Nov 12, 2026

    More actions

    That coul be possible. I use an App called Dazeimanager+(File Manager Plus) It uses the web.dav path to access Nextcloud and ist works 10times faster and mor efficiently than the nextcloud App.
14. xundeenergie commented on Nov 12, 2026

    

    xundeenergie

    on Nov 12, 2026

    More actions

    I use cx-datei-explorer, which also uses webdav. And it is also very fast and shows files and dirs only once.