Total Commander

And the problems with Android 11 keep coming...

Most recent example: as it happens I own a comprehensive formulary which can be accessed on computers as a web-structure by normal browsers or offline-web-viewers and which I like to carry with me on my smartphone.

The web-structure looks like:
../MYFORMULARY
toppage.html
..../data
....../S1levelDIRs
......../S2levelDIRs
........../S3levelDIRs

On the phone this structure is (and should be) located on my external SD-card "HHHH-HHHH" like:
file:///storage/HHHH-HHHH/DOC/...../MYFORMULARY/toppage.html

But when I try to open that local web with standard browsers (Opera ,Chrome, Samsung-browser) all I can see is that (meaningless) top-level-page. If I now try to navigate to - say - "Index" all I will get is an error message:
"This site can't be reached"
Now, the interesting part is the "url" given that the browser has failed to access. It actually is:
content://com.ghisler.files/storage/HHHH-HHHH/DOC/...../MYFORMULARY/DATA/S1DIR/index.html (where those subdirs indeed are NOT located) instead of
file:///storage/HHHH-HHHH/DOC/...../MYFORMULARY/DATA/S1DIR/index.html (where they actually ARE located.)

As I've already learned this is due to that notorious And11-"feature" that directories of other programs cannot be directly accessed any more. But still - TC-And can usually access those by mapping them to somewhere else, yet seemingly subdirs thereof at that "other location" cannot be accessed by the calling (browser-)programs any more.

Next thing I tried was to find dedicated offline-HTML-browser-/viewer-programs for Android. There are some - but then again not too many. Now comes the "sadly-funny" part. They all fall into two categories. They either (like the browsers) CAN SEE the external SD-Card BUT (like the browsers) fail to navigate the sub-structure with an "access denied"-error message - OR - they can successfully navigate the sub-structure (there are 2 of them). But then (exactly those 2) CANNOT SEE and access the external SD-Card, only internal storage (/emulated/0/...)
Only workaround so far: I've had to copy the whole (large) formulary-structure to
file:///storage/emulated/0/Android/data/com.opera.browser/files/Download/MYFORMULARY/toppage.html
where Opera has unrestricted access to and create a speed-dial-/bookmark-entry to that location and then Opera can use the whole formulary structure as it should.

Now I can hardly imagine that this is the way it should be under And11. This Opera-subdir is - from a data-structurally logical viewpoint - certainly not an appropriate location for that formulary to reside. Also it uses up a lot of internal memory there.

So has anybody experience with how to handle that And11 data-access-blunder and how to make that formulary work normally from the proper external-SD-card/DOC/SCI/Math-location? Any help would be appreciated.

Most newer apps do not accept file: URLs any more, that's why TC sends content: URLs now. The downside is that it only gives the app access to that URL, you cannot just edit the URL and access other data any more.

You can try to define an internal association for .html and set it to open the app with the file: URL instead of the content: URL. However, it will not work with all apps.

ghisler(Author) wrote: 2022-06-13, 08:43 UTCYou can try to define an internal association for .html and set it to open the app with the file: URL instead of the content: URL. However, it will not work with all apps.

I'm afraid I do not quite get it. In TCAnd I have already set an association for "html" that directs to open such file extensions with my default browser Opera.

Until now I wasn't even aware of those subtle differences between file: and content: - and perhaps I didn't explain the situation correctly. I never tried to directly open any "file: url". All I have is that local web-structure in my "Formulary-Dir" with sub-Dirs, located in /DOC/... on my external SD-card. And within this "Formulary-Dir" is that top-level "formulary.html"-file. Since html-files on my device are associated with Opera clicking that top-level "formulary.html"-file will open it in Opera-browser as expected.

The problem is that Opera from there obviously cannot "see" the linked web-structure physically located in sub-Dirs under this top-level-"Formulary-Dir" containing the front-end-html-file.

And instead of directly accessing the physical web-structure located in 3 levels of sub-Dirs below - Opera now seemingly tries to open some virtual location instead - yet in vain - given as content://com.ghisler.files/storage/HHHH-HHHH/DOC/... by the resulting Opera-error-message.

So I as a user never explicitly tried to open any "file:..." or "content:...."-location myself, Opera does that when in fact simply (correct) links within that top-level-html-page are clicked to branch deeper into that Formulary-web.

What I meant is that you go to main menu - Configure - Internal associations, and define a new one linking .html to Opera. Then uncheck "Parameters: content://url" to ensure that Total Commander sends the name as a file: URL.

Got it. And tried it out immediately. This way I get:

"Access to the file was denied"

and the malfunctioning url is given as:
file:///storage/HHHH-HHHH/DOC/...../MYFORMULARY/formulary.html

So this way even the access to the top-level html-file is denied right away because of "Access denied".

But thanks for the effort anyway. What I still don't understand: I've got my system rooted meanwhile. So is there no external way to administer which app has access-rights to which location or turn that damn "access-compartmentalization"-blunder off altogether, in particular for the external SD-Card?

No, rooting does not help here at all. Rooting only gives the app the right to run a (hidden) shell via su command. This shell can then run shell commands like rm (remove file) etc. with root rights. It does not grant more access rights to the file functions used by the apps because these still run with their own user rights. An app explicitly needs to call root functions to make use of them.

As it seems, Opera isn't supporting access to file: URLs any more, so my suggestion doesn't help.

Many thanks for the clarifications about root. As for Opera no longer supporting file: URLs - well at least that I can rule out. As already mentioned my current workaround has been to copy the whole large "Formulary"-structure to the internal memory-path for Opera-downloads
storage/emulated/0/Android/data/com.opera.browser/files/Download/MYFORMULARY/
from where Opera CAN successfully navigate the whole structure via calling by a bookmark/speed-dial entry as
file:///storage/emulated/0/Android/data/com.opera.browser/files/Download/MYFORMULARY/formulary-toppage.html
So a lacking capability of Opera (no longer?) accessing file: URLs cannot be the culprit here as it DOES open file: URLs - at least within its own storage-access-realm located in internal memory.

However - rather by accident - I've meanwhile found a solution for the problem described above, well, kind of, as I still do not understand how and why that works. I've kept wondering about that "mapping"-solution/workaround of accessing other-programs-storage-realm in general via either "file:" or via "content:" and decided to look into how other file-managers would handle that situation.

One IMHO quite capable Android file-manager next to TCAnd would be "x-plore" (sorry for mentioning the competition here) and so I gave it a try. When navigating to the external-SD-card location of "Formulary" and specifying to "open with" the top-level "formulary.html" via either Opera or Samsung-browser I got about the same results. "Access denied" with equally reporting "content:"-locations that couldn't be accessed, only them being located in a different local "mapping"-area owned by x-plore instead of TCAnd.

So closing down the failing browsers again I happened to click on the html-file directly in x-plore - more by accident than out of curiosity - and expected an "open-with"-dialog to pop up. But - nope!

In some true Heureka-moment the Formulary opened up, already perfectly scaled for the mobile phone and in bright colors, and moreover fully accessible/navigable as I hardly dared to believe.

Only explanation so far: x-plore must have some kind of built-in, full-fledged html-viewer/browser (nowhere mentioned in its properties-listing) which therefore can utilize the same full file-/data-access as the main file-manager can!

As I said, problem solved, sort of, amazingly enough!

It probably shows html in the Android WebView control. Total Commander uses the same control for the help. However, it doesn't currently have any file viewers, only a text editor built in.

Well, if it's relatively that easy and only the filename has to be passed on correctly to some built-in Android service - maybe that would be a nice expansion for future TCAnd versions. No pressure intended here but perhaps you might want to have a look at x-plore (by "lonely cat games") yourself and how it handles things. I think it is more media- and game-oriented than TCAnd but quite capable when it comes to viewers or media-players. And it is always a good idea to keep an eye on the competition.

That would only let you view html files and a few image types, nothing else...

I would say that if that really comes almost for free - then anything is better than nothing. For instance being able to use my formulary means quite a lot to me and others may have different offline-web-content the want to take with them and use offline. Furthermore that "mapping"-workaround to pass over file-access to other 3rd-party-software doesn't seem to work so well.

In that context I have a question remaining: If that "file:" or "content:" "mapping"-workaround would/does function as intended - would that be meant to include only the current directory with the file being passed over to the associated software - or should then the whole sub-tree-structure from this parent-Dir on be mapped and then be accessible to the associated software as well (as would be needed in the case of my formulary-web-substructure)? Because those browser-error-messages strongly suggest to me as the culprit of the malfunction that only the top-level-"formulary.html" is mapped to this content-ghisler-dummy-location whereas the whole formulary-web-structure below which that top-level-"formulary.html" in consequence seeks to access simply isn't there. I'm quite certain that the cause for the browsers being unable to access the web-sub-structure containing the detail-pages is as simple as that. They cannot be accessed because they have never been copied to the dummy-location but the browser would be looking for them (url=content:) at exactly that (non-existent) dummy-location.