Pinned files fail to open sometimes

[harshadjs]

I share some files between orgzly and orgro on the same device. I have those files pinned, some times when I try to open the pinned file in orgro I get following error

However, the exact same file when opened via file open button on bottom right, it opens alright.

I tried killing orgzly but I still see the error.

[amake]

It sounds like the permissions you're granted via the OS file picker can't survive whatever manipulations Orgzly is doing to the file.

As far as I know there's nothing Orgro can do about that.

[amake]

As always I hate to just pass along something an LLM told me, but this looks quite accurate to me:

Diagnosis

This is almost certainly caused by Orgzly replacing the SAF document that Orgro pinned.

Orgro pins the persistent file identifier returned by file_picker_writable, and on Android that identifier is just the literal content://... document URI. See Orgro storing the identifier in util.dart, reopening pins in remembered_files.dart, and file_picker_writable returning "identifier" to fileUri.toString() in FilePickerWritableImpl.kt.

When a pinned file is reopened, Orgro passes that saved URI back to readFileWithIdentifier, which reparses the URI and calls the Android content resolver. See file_picker.dart and FilePickerWritableImpl.kt.

The problem is in Orgzly’s SAF-backed DocumentRepo.storeBook: it finds the existing file, deletes it, then creates a new file with the same name. That new file gets a new document URI/document ID. See DocumentRepo.java.

So the old Orgro pin points at a deleted document. Opening via Orgro’s file-open button works because the system picker returns the current replacement document URI. Killing Orgzly would not help because the original document has already been replaced.

Likely Fix

Best fix is on the Orgzly side: DocumentRepo.storeBook should write/truncate the existing DocumentFile in place instead of deleting and recreating it, using openOutputStream(existingFile.getUri(), "wt") or equivalent. That preserves external apps’ persisted document grants.

A defensive Orgro fallback is possible only if Orgro also has parent directory access: on failed pinned-file open, re-resolve by saved name under the parent directory. But with only a single-file SAF grant, Orgro cannot discover the replacement URI by itself.

[ofansifkapital]

I am also observing the OP's issue. And it is quite annoying. In my experience, this happens even when I don't use orgzly app to modify the files I open in Orgro. Orgro, seemingly randomly, although I suspect after I make changes to files on my laptop-side (I use syncthing to edit files on laptop and then read on the Orgro), Orgro seems to fail its permission to open them!

Maybe the correct fix is to support storage scopes, properly, in Orgro, so that the app doesn't get confused whenever the files are edited/modified, and doesn't lose its "permission" to open them?

[amake]

seemingly randomly, although I suspect

It would help to have a specific set of steps to reproduce so we can actually diagnose the issue.

Maybe the correct fix is to support storage scopes, properly, in Orgro

Storage scopes is not obviously the "proper" solution. You are asking Orgro to require much stronger disk access than it actually needs for the majority of use cases, and many people rightfully find that undesirable. In the Orgzly case, Orgzly is deleting the file for which you gave permission; that's simply not something Orgro can do anything about.

[ofansifkapital]

set of steps to reproduce so we can actually diagnose the issue.

I don't have an exact steps to reproduce, but I experience this issue very frequently, recently. I suspect the steps are like this:

1. edit an org file on laptop
2. that file is already being synced to the android device via syncthing
3. that file was already able to be opened inside orgro
4. after the change/modification gets synced to the android side, orgro seems to fail opening it again

This is what I suspect right now.

You are asking Orgro to require much stronger disk access than it actually needs for the majority of use cases

In my opinion, many people read org files that are interlinked with each other. This means, most people do not read singular files in isolation, but open an org file, read it, click on an org link that opens anohter org file. This interlinked file system can justify giving a whole directory to the access of Orgro via storage scopes.

[amake]

I don't have an exact steps to reproduce

Please post when you do.

many people read org files that are interlinked with each other

This is adequately covered by the existing directory access features, and is not related to the issue initially described by this ticket.

[ofansifkapital]

Please post when you do.

@amake here is:

1. the file is read_it_later.org
2. this file is present both on my laptop and on my android device (where I use orgro)
3. on orgro this file is pinned to the top of the list, under "Pinned files"
4. these two instances of the same file are synced between laptop and android via syncthing

Start:

1. open read_it_later.org on orgro
2. orgro gives error, something about ACTION_OPEN_DOCUMENT, and displays pid=4742 and uid=10188
3. After this, I tap on the folder icon on Orgro UI, select the same file from the file picker, and open it
4. Orgro opens the file without an isse
5. Change the read_it_later.org file on laptop
6. Let the change be synced to the android
7. Tap on the same file on the Pinned files section on orgro UI
8. Orgro gives the same error as the above, but this time with a different pid value (the uid value stays the same)

This bug is very annoying and takes away all the speed of me reaching my org files via Orgro on android.

On my phone, pixel 6a, I am using GrapheneOS latest stable release.

[confusedalex]

it finds the existing file, deletes it, then creates a new file with the same name. That new file gets a new document URI/document ID.

This is true and is also the way syncthing handles updates. Using the directory-picker and opening the file via it's relative path was a dirty fix I've found for my app.

[ofansifkapital]

@amake any solutions to the issue? it is really a bad UX that I have to constantly "re-find" the files by having to entering their full path in orgro app, after each time the file contents get changed by the syncthing app (or any other desktop to mobile syncing mechanism).

[amake]

Any solution on Orgro's side that I'm aware of requires rearchitecting the way files are managed and accessed. I'm not planning on doing that any time soon.

[ofansifkapital]

Understood. How do you deal with this UX hurdle yourself? Don't you have org files you edit on computer that you sync to your mobile device for reading in orgro?

[amake]

Don't you have org files you edit on computer that you sync to your mobile device for reading in orgro?

Mostly I don't use the same files on both computer and mobile, but when I do I am using iCloud Drive which doesn't have this problem: editing on the computer does not invalidate the grant that Orgro receives from the OS on mobile (although replacing the file does).

[amake]

OK, I lied, there was something I could do without rearchitecting everything.

In v2.4.2 when opening a "recent file" fails, Orgro will attempt to locate the file by name within one of the directories that Orgro has access to. It will replace the "recent file" with the first matching file it finds. If it can't find anything, it will present a dialog asking you to do one of the following:

• Grant access to the parent directory
• Locate the file itself
• Remove the "recent file" entry

This will be available for testing soon:

• iOS
• Android