Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mobile.android > #154332 > unrolled thread

How to copy & read a huge zipped book with thousands of html & jpeg files

Back to article view | Back to comp.mobile.android

Contents

  How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-04 18:40 -0400
    Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-04 21:17 -0400
      Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-04 21:48 -0400
        Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-04 22:51 -0400
          Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-04 23:57 -0400
            Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-04 23:13 -0600
              Re: How to copy & read a huge zipped book with thousands of html & jpeg files Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-08 10:10 +0100
            Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-05 13:29 +0200
              Re: How to copy & read a huge zipped book with thousands of html & jpeg files Dave Royal <dave@dave123royal.com> - 2026-07-05 14:48 +0100
                Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 10:06 -0600
                Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-05 19:10 +0200
                  Re: How to copy & read a huge zipped book with thousands of html & jpeg files Computer Nerd Kev <not@telling.you.invalid> - 2026-07-05 17:37 +0000
                    Re: How to copy & read a huge zipped book with thousands of html & jpeg files Alan <nuh-uh@nope.com> - 2026-07-07 11:11 -0700
                  Re: How to copy & read a huge zipped book with thousands of html & jpeg files Dave Royal <dave@dave123royal.com> - 2026-07-05 21:00 +0100
                    Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-05 22:50 +0200
                      Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 23:06 -0600
                        Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-06 12:05 +0200
                          Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-06 12:24 +0200
                            Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-06 10:28 -0600
                              Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-06 19:50 +0200
                          Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-06 09:36 -0600
                            Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-06 19:56 +0200
                      Re: How to copy & read a huge zipped book with thousands of html & jpeg files Dave Royal <dave@dave123royal.com> - 2026-07-06 07:58 +0100
                        Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-06 12:12 +0200
                    Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 15:12 -0600
              Re: How to copy & read a huge zipped book with thousands of html & jpeg files Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-08 10:39 +0100
            Re: How to copy & read a huge zipped book with thousands of html & jpeg files Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-08 10:37 +0100
          Re: How to copy & read a huge zipped book with thousands of html & jpeg files Arno Welzel <usenet@arnowelzel.de> - 2026-07-06 17:53 +0200
            Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-06 10:47 -0600
            Re: How to copy & read a huge zipped book with thousands of html & jpeg files Nuno Silva <nunojsilva@invalid.invalid> - 2026-07-08 10:57 +0100
        Re: How to copy & read a huge zipped book with thousands of html & jpeg files Andy Burns <usenet@andyburns.uk> - 2026-07-05 08:35 +0100
          Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 10:38 -0600
            Re: How to copy & read a huge zipped book with thousands of html & jpeg files Andy Burns <usenet@andyburns.uk> - 2026-07-05 18:22 +0100
              Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 12:16 -0600
            Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-05 19:41 +0200
              Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 12:54 -0600
                Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-05 23:11 +0200
                  Re: How to copy & read a huge zipped book with thousands of html & jpeg files Maria Sophia <mariasophia@comprehension.com> - 2026-07-05 15:23 -0600
    Re: How to copy & read a huge zipped book with thousands of html & jpeg files Arno Welzel <usenet@arnowelzel.de> - 2026-07-06 17:48 +0200

Page 2 of 2 — ← Prev page 1 [2]

#154359

Carlos E. R. wrote:
>> I fed my 500MB zip file into Calibre and told it to convert it to an EPUB,
>> which took a few hours on my 2009 Windows 10 PC, but it worked beautifully.
> 
> Wow. My laptop took a few seconds, but it was just a 2.5 MiB zip.

My desktop is from 2009. It's still working well, but this stressed it. :)

>> The resulting EPUB file was 400MB so it took a while for Calibre to load it
>> the first time (due to all the caching that Calibre does on first loading).
> 
> I have never seen an epub that big. In my case, the book that I tested 
> with can be purchased in epub format. Possibly the epub is available on 
> the emule network or such (for testing, of course).

My experience had been the same as yours. EPUBs are generally quite small.
This one has tens of thousands of separate images yet very little text.

>> When I looked at the file inside of Thorium, I got an appreciation for why
>> HTML is an excellent medium, as there were tens of thousands of connected
>> pages and images, where an EPUB can handle it, but it's slow as all hell.
>> 
>> Since the EPUB itself was 400MB, I didn't even bother copying to Android.
>> If it's slow on Windows, it's likely gonna be even slower on Android.
>> 
>> The HTML is, by way of contrast, is virtually instant when clicking about.
>> 
>> When I tried to convert the EPUB to a PDF, Calibre failed (with what seemed
>> like memory errors) after about an hour or two, so I gave up on the PDF.
> 
> I don't like PDF for books, because it doesn't flow the text. It is 
> fixed size. You need a display that matches the design size and 
> resolution (or better).

I agree that PDF isn't all that great for books in that, for me, my eyes
aren't so great and a PDF makes you sit and stare at it to read it.

I prefer to convert the (text) PDF to audio using cross platform balabolka
freeware which then turns any (text) PDF into an audio book.

It's not as good as a human reader for some books, e.g., when I converted
Einstein's 1916 (updated in 1922) book on relativity, calculations are
messed up when spoken by balabolka's conversion utilities.

But now I'm one of the few non-physicists who understand gravity as a
result, since I was in a compression/decompression chamber for a month.

As an aside, almost nobody understands gravity. One in a million I'd bet.
And even as I understand it to that level, there's still much I don't know.

>> Looking into my c:\app\editor\epub directory, these seem to be most common
>> cross platform EPUB readers, where I've sorted by large file handling.
>>   thorium
>>    most stable & fastest for huge image-heavy epubs like textbooks
>>   calibre
>>    most powerful for conversion & repair of image-heavy epubs
>>   redium desktop
>>    sibling of thorium but less polished than thorium
>>   okular
>>    KDE document viewer with medium-level EPUB support via plugins
>>   hamster
>>    best for small epubs
>>   lucidor
>>    best for very small epubs
>>   fbreader
>>    suitable for smaller epubs
>>   adobe digital editions
>>    not suitable as the epub engine is old and fragile
>>   sumatra pdf
>>    fast for small epubs
>> 
>> In summary, for certain kinds of references (such as highly cross-linked
>> highly imaged technical manuals and textbooks), a zip HTML is likely ideal.
> 
> Seeing that calibre imports the html directory as a zip file, it is 
> possible that there is software out there that directly renders readable 
> those ZIP files. Or even hardware.

I agree that Calibre had no problem importing the single 500MB zip file.
It just took a long time, but Calibre didn't even blink on the contents.

It's just that my circa 2009 PC runs slowly when it's time to crunch it.

I've learned there's a good reason highly cross-linked documents filled
with images and almost no text are supplied in a zip file HTML format.

It's amazing how fast HTML is compared to the EPUB, although the epub has
the distinct advantage of a fantastic search mechanism that shocked me.

With EPUB, when you search, you get every instance but every line of every
instance (much like you'd get with a (text) PDF, so that was really nice.

So if you need to search a huge 500MB HTML document containing tens of
thousands of files, converting it to a 400MB EPUB allows that fantastic
search, but if you need to actually navigate it, an HTML server wins out.
-- 
Converting 400MB EPUBs on a 2009 desktop as HTML loads faster than time.

[toc] | [prev] | [next] | [standalone]

#154365

On 2026-07-06 17:36, Maria Sophia wrote:
> Carlos E. R. wrote:
>>> I fed my 500MB zip file into Calibre and told it to convert it to an EPUB,
>>> which took a few hours on my 2009 Windows 10 PC, but it worked beautifully.
>>
>> Wow. My laptop took a few seconds, but it was just a 2.5 MiB zip.
> 
> My desktop is from 2009. It's still working well, but this stressed it. :)
> 
>>> The resulting EPUB file was 400MB so it took a while for Calibre to load it
>>> the first time (due to all the caching that Calibre does on first loading).
>>
>> I have never seen an epub that big. In my case, the book that I tested
>> with can be purchased in epub format. Possibly the epub is available on
>> the emule network or such (for testing, of course).
> 
> My experience had been the same as yours. EPUBs are generally quite small.
> This one has tens of thousands of separate images yet very little text.
> 
>>> When I looked at the file inside of Thorium, I got an appreciation for why
>>> HTML is an excellent medium, as there were tens of thousands of connected
>>> pages and images, where an EPUB can handle it, but it's slow as all hell.
>>>
>>> Since the EPUB itself was 400MB, I didn't even bother copying to Android.
>>> If it's slow on Windows, it's likely gonna be even slower on Android.
>>>
>>> The HTML is, by way of contrast, is virtually instant when clicking about.
>>>
>>> When I tried to convert the EPUB to a PDF, Calibre failed (with what seemed
>>> like memory errors) after about an hour or two, so I gave up on the PDF.
>>
>> I don't like PDF for books, because it doesn't flow the text. It is
>> fixed size. You need a display that matches the design size and
>> resolution (or better).
> 
> I agree that PDF isn't all that great for books in that, for me, my eyes
> aren't so great and a PDF makes you sit and stare at it to read it.

Maybe it would be easier to read in an ebook device, using epaper which 
doesn't shine.

> 
> I prefer to convert the (text) PDF to audio using cross platform balabolka
> freeware which then turns any (text) PDF into an audio book.
> 
> It's not as good as a human reader for some books, e.g., when I converted
> Einstein's 1916 (updated in 1922) book on relativity, calculations are
> messed up when spoken by balabolka's conversion utilities.
> 
> But now I'm one of the few non-physicists who understand gravity as a
> result, since I was in a compression/decompression chamber for a month.
> 
> As an aside, almost nobody understands gravity. One in a million I'd bet.
> And even as I understand it to that level, there's still much I don't know.
> 
>>> Looking into my c:\app\editor\epub directory, these seem to be most common
>>> cross platform EPUB readers, where I've sorted by large file handling.
>>>    thorium
>>>     most stable & fastest for huge image-heavy epubs like textbooks
>>>    calibre
>>>     most powerful for conversion & repair of image-heavy epubs
>>>    redium desktop
>>>     sibling of thorium but less polished than thorium
>>>    okular
>>>     KDE document viewer with medium-level EPUB support via plugins
>>>    hamster
>>>     best for small epubs
>>>    lucidor
>>>     best for very small epubs
>>>    fbreader
>>>     suitable for smaller epubs
>>>    adobe digital editions
>>>     not suitable as the epub engine is old and fragile
>>>    sumatra pdf
>>>     fast for small epubs
>>>
>>> In summary, for certain kinds of references (such as highly cross-linked
>>> highly imaged technical manuals and textbooks), a zip HTML is likely ideal.
>>
>> Seeing that calibre imports the html directory as a zip file, it is
>> possible that there is software out there that directly renders readable
>> those ZIP files. Or even hardware.
> 
> I agree that Calibre had no problem importing the single 500MB zip file.
> It just took a long time, but Calibre didn't even blink on the contents.
> 
> It's just that my circa 2009 PC runs slowly when it's time to crunch it.
> 
> I've learned there's a good reason highly cross-linked documents filled
> with images and almost no text are supplied in a zip file HTML format.
> 
> It's amazing how fast HTML is compared to the EPUB, although the epub has
> the distinct advantage of a fantastic search mechanism that shocked me.
> 
> With EPUB, when you search, you get every instance but every line of every
> instance (much like you'd get with a (text) PDF, so that was really nice.

Yes, my kobo reader does search easily, I noticed.

> 
> So if you need to search a huge 500MB HTML document containing tens of
> thousands of files, converting it to a 400MB EPUB allows that fantastic
> search, but if you need to actually navigate it, an HTML server wins out.


-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154355

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

> On 2026-07-05 22:00, Dave Royal wrote:
>> In the days when software was released on CD such html documentation was common. But any browser could read local http files then.
>> 
> Yes, I know. But calling that "book" confused me.
> 
I wouldn't call it a book either. The rust manual, to which had a
 bookmark (!) on this tablet, was the first example I thought of.
 It was just fortuitous that it had 'book' in the url. I see this
 in the source:
  <!-- Book generated using mdBook -->
> 
> Epub is also liquid. 
> 
I had forgotten. A few years back I converted a 'tunebook' - a mix of musical scores and text - into mobi format for display on a kindle. You want the score to occupy the whole page width, as big as possible. I wasn't sure how mobi resized the images, hence my comment in https://mudcat.org/thread.cfm?threadid=171470#4147314 
"I wonder if the mobi has converted the compressed SVGs to some
 other image format, each at several sizes for different
 Kindles?"
-- 
Remove numerics from my email address.

[toc] | [prev] | [next] | [standalone]

#154357

On 2026-07-06 08:58, Dave Royal wrote:
> "Carlos E. R." <robin_listas@es.invalid> Wrote in message:
> 
>> On 2026-07-05 22:00, Dave Royal wrote:
>>> In the days when software was released on CD such html documentation was common. But any browser could read local http files then.
>>>
>> Yes, I know. But calling that "book" confused me.
>>
> I wouldn't call it a book either. The rust manual, to which had a
>   bookmark (!) on this tablet, was the first example I thought of.
>   It was just fortuitous that it had 'book' in the url. I see this
>   in the source:
>    <!-- Book generated using mdBook -->
>>
>> Epub is also liquid.
>>
> I had forgotten. A few years back I converted a 'tunebook' - a mix of musical scores and text - into mobi format for display on a kindle. You want the score to occupy the whole page width, as big as possible. I wasn't sure how mobi resized the images, hence my comment in https://mudcat.org/thread.cfm?threadid=171470#4147314
> "I wonder if the mobi has converted the compressed SVGs to some
>   other image format, each at several sizes for different
>   Kindles?"

The kindle doesn't use epub format. They are two competing markets with 
different software.

The images I have seen on epubs are bitmaps, so hardly "zoomable". I 
mean, if the image has more pixels than my ebook device, the image 
results hard to read or view.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154352

Dave Royal wrote:
>> No ZIP that I can see :-?
>> 
>> I would have to download using wget, and this tool modifies the links so 
>> that they are correct for your local installation.
> 
> The links are normally relative to the document root, so no need
>  to modify them.
> 
> In the days when software was released on CD such html documentation was common. But any browser could read local http files then.
> 
>> I wonder if Calibre can convert that to epub.
> 
> If so I suppose you'd have to specify the medium size - eg A4. An
>  html file is liquid - it fills any window or page size.

As Dave Royal noted to Carlos, all paths are relative to $DOCUMENT_ROOT.

Also, as Dave noted, EPUB is essentially a packaged, standardized container
built decades later on top of XHTML and CSS, long after HTML documentation
was already widespread in CD ROM supplied documentation and help systems.

Looking up Carlos' Calibre question, apparently Calibre can convert a
complex multi-file HTML book into a single EPUB/AZW3 file, as long as we
give it the entire directory (usually as a ZIP) if it is formatted well.
 1. Feed the ZIP to Calibre, 
 2. Convert to EPUB, 
 3. Output a single, portable book with all images and subfiles embedded.

Once Calibre converts the zip to an epub, it can be copied to Android.	
-- 
Usenet allows good friends around the world to discuss their experiences.

[toc] | [prev] | [next] | [standalone]

#154370

On 2026-07-05, Carlos E. R. wrote:

> On 2026-07-05 05:57, Maria Sophia wrote:
>> Maria Sophia wrote:
>>> I finally forced Android 16 to behave like a real operating system again.
>>> I carved out a sane workflow inside an OS that keeps trying to turn into
>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.
>>
>> SUMMARY (Linux users added because it was Linux to the rescue this time!)
>>
>> Windows and Linux can easily open HTML books stored in custom top-level
>> hierarchies, even if the books contain tens of thousands of pages & jpegs.
>>
>> Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
>> top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.
>
> I don't know what are "books" in this context.
>
> If you mean electronic books, for me they are epubs, and I handle them
> with Calibre.
>
> https://www.gutenberg.org/ebooks/79019
>
> I see html format is available, but I see no reason to use it, unless
> as an intermediary to transform to something else.

(Wasn't epub a Zip archive of a HTML book?)

(Ok, Wikipedia says XHTML?)

-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#154369

On 2026-07-05, Maria Sophia wrote:

> Maria Sophia wrote:
>> I finally forced Android 16 to behave like a real operating system again. 
>> I carved out a sane workflow inside an OS that keeps trying to turn into 
>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.
>
> SUMMARY (Linux users added because it was Linux to the rescue this time!)
>
> Windows and Linux can easily open HTML books stored in custom top-level
> hierarchies, even if the books contain tens of thousands of pages & jpegs.
>
> Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
> top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.
>
> All Android web browsers use WebView, which is restricted by Scoped Storage 
> and the Storage Access Framework (SAF). When you try to open index.html, 
> Android does not give the browser the real filesystem path.
>
> Instead it rewrites the path into a SAF URI like:
>   content://com.android.externalstorage.documents/document/primary%3A0000%2Fbooks%2Fbook1%2Findex.html
>
> SAF URIs are not real filesystem paths.
> Because of this, all relative links inside the book1 break.
>
> For example:
>   pages/2.html
>   images/foo.png
>   css/style.css
>
> These links get rewritten into invalid SAF document URIs such as:
>   content://com.android.externalstorage.documents/document/pages/2.html
>
> Browsers cannot resolve these, so they fail with errors like
>   ERR_ACCESS_DENIED and ERR_FILE_NOT_FOUND.
>
> Android WebView only allows file:// access in a few public folders 
> (Download, Documents, DCIM, Pictures) but Linux users often use custom 
> folders like /usr/local so that they can back up everything they care about 
> easily, and so that they're not polluted by the Android system.
>
> Custom folders like /0000 are blocked.
>
> Unzipping the book1 works fine, but opening index.html directly from
> the top-level /0000 fails in every browser tested.
>
> Solution:
> Use Termux to bypass SAF entirely. Termux uses real POSIX filesystem
> access. After granting Termux full file permissions in Android Settings,
> you can run a local HTTP server that serves the book1 using real paths.
>
> Steps:
> 1. Install Termux from GitHub or F-Droid.
> 2. Grant Termux "All files access" in Android Settings.
> 3. In Termux, install Python:
>     pkg install python
> 4. Navigate to the book1 directory:
>     cd /storage/emulated/0/0000/books/book1
> 5. Start a local HTTP server:
>     python3 -m http.server 8000
> 6. Open any browser and go to:
>     http://localhost:8000
>
> Because the book1 is now served over HTTP, the browser treats it as a
> normal website. All relative links, images, CSS, and subpages work
> correctly. This bypasses SAF and restores normal filesystem behavior.
>
> Result:
> The entire HTML book named book1 displays perfectly on Android while 
> remaining in the user's own custom directory (/0000) so that it can 
> be copied over during backups along with the rest of the users' data.
>
> AFAIK, this method works reliably on all modern Android versions. 

BTW, I didn't try with anything complex, but a quick test with two HTML
files, a link between them, and one of them using an inline image worked
for file:///storage/[dirname]/path/to/html in Emacs' eww, under Android
15. As in, both documents loaded, the same-directory inline image
loaded, and the same-directory relative link worked too.

Might not be useful at all, or may only be useful for simpler content of
some sort, but given that I tested, I thought I'd add this datapoint.

Might be useful for myself in the future, too.

-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#154361

Maria Sophia, 2026-07-05 04:51:

> Maria Sophia wrote:
>> Apparently, Android only allows browsers to read:
>>  /storage/emulated/0/Download/
>>  /storage/emulated/0/Documents/
>>  /storage/emulated/0/DCIM/
>>  /storage/emulated/0/Pictures/
> 
> This is frustrating as Android seems to be getting more & more like iOS
> as it appears that Android's WebView (used by all browsers) cannot open:
>  file:///storage/emulated/0/0000/...	 

This was never possible. Apps can NEVER access the filesystem outside
their own sandbox. Also before Android 5 this was a special API call
only possible, if the app has the permission for it. And nowadays, the
SAF is the preferred way to access files for security reasons.

> So I need to find an app that still use direct POSIX filesystem access (and 
> ignores SAF entirely), or, I can install a local HTTP server in Termux.

You can't find such an app, since this is not possible.

> 3. In Termux, install python.
>    $ pkg install python
>     
> 4. In Termux, start the server
>    $ python3 -m http.server 8000
>     Serving HTTP on :: pot 8000 (http://[::]:8000) ...
> 
> 5. Open any browser and type the following into the url address field 
>    http://localhost:8000
> 
> 6. Using the Privacy Browser, that brought up the top-level web page.
>    Then, I tapped on the first link... ... ... Voila!
>    The manual page2 showed up perfectly this time. 
> 
> Whew!
> Success at last!

Yes, because python3 is *not* an "app", it is just a program.

apps are *not* programs which just start and do something. They are
packages providing handlers for "actions" like "intentions" and in some
cases also provide services like "handle incoming TCP connection" or "do
something once an hour" etc.. - but you must not confuse "app" with
"program".

And no, this was never different in Android - even the very first
Android versions worked like this.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#154363

Arno Welzel wrote:
> Maria Sophia, 2026-07-05 04:51:
> 
>> Maria Sophia wrote:
>>> Apparently, Android only allows browsers to read:
>>>  /storage/emulated/0/Download/
>>>  /storage/emulated/0/Documents/
>>>  /storage/emulated/0/DCIM/
>>>  /storage/emulated/0/Pictures/
>> 
>> This is frustrating as Android seems to be getting more & more like iOS
>> as it appears that Android's WebView (used by all browsers) cannot open:
>>  file:///storage/emulated/0/0000/...	 
> 
> This was never possible. Apps can NEVER access the filesystem outside
> their own sandbox. Also before Android 5 this was a special API call
> only possible, if the app has the permission for it. And nowadays, the
> SAF is the preferred way to access files for security reasons.
> 
>> So I need to find an app that still use direct POSIX filesystem access (and 
>> ignores SAF entirely), or, I can install a local HTTP server in Termux.
> 
> You can't find such an app, since this is not possible.
> 
>> 3. In Termux, install python.
>>    $ pkg install python
>>     
>> 4. In Termux, start the server
>>    $ python3 -m http.server 8000
>>     Serving HTTP on :: pot 8000 (http://[::]:8000) ...
>> 
>> 5. Open any browser and type the following into the url address field 
>>    http://localhost:8000
>> 
>> 6. Using the Privacy Browser, that brought up the top-level web page.
>>    Then, I tapped on the first link... ... ... Voila!
>>    The manual page2 showed up perfectly this time. 
>> 
>> Whew!
>> Success at last!
> 
> Yes, because python3 is *not* an "app", it is just a program.
> 
> apps are *not* programs which just start and do something. They are
> packages providing handlers for "actions" like "intentions" and in some
> cases also provide services like "handle incoming TCP connection" or "do
> something once an hour" etc.. - but you must not confuse "app" with
> "program".
> 
> And no, this was never different in Android - even the very first
> Android versions worked like this.

Hi Arno,

Thanks for weighing in as I had never even thought about this problem
before, and, in fact, while I knew about SAF, I didn't understand it.

As we found out later in the thread, the problem isn't Android sandboxing.
It's WebView rewriting file:// paths inside of custom folders into SAF
content:// URIs, which breaks relative links. Termux works because it
bypasses WebView. So it's not an access problem. It's a POSIX problem.

Looking up all your information, you're correct that apps cannot freely
(without permission) access arbitrary paths like /storage/emulated/0/0000
(which are outside the public folders) which has always been the case.

And you're correct SAF is now the preferred method for user-selected files.
And you are right that Termux + python3 works because it's not a WebView.
 a. Termux runs native binaries, not WebView
 b. The local HTTP server bypasses SAF entirely

But prior to Android 10, browsers could open local directories using
file:///storage/emulated/0/... paths directly if they had permission. 

But Android 10+ changed this behavior but Apps can still access shared
storage if they have the permission to do so, such as
 a. READ_EXTERNAL_STORAGE
 b. WRITE_EXTERNAL_STORAGE
 c. or user-granted SAF access

This is why file managers, browsers, media players, and editors can read
/storage/emulated/0/....

What changed is how they access it.

As for finding an app that ignores SAF, clearly Termux ignores SAF.
Termux has direct POSIX access with no SAF and no WebView restrictions.

Other apps also bypass SAF:
 a. MiXplorer
 c. X-plore
 d. Cx File Explorer
 e. VLC
 f. Kodi
 g. RetroArch
In fact, any app using native code instead of WebView bypasses SAF.

If you get a chance, read the rest of this thread, where it turns out that
the real problem was simply that SAF screws up relative links in my file.

It turned out, much later, that it's not that apps can't access the
filesystem, but that Android WebView rewrites file paths that are in custom
folders into SAF content URIs, which was breaking the HTMLZ relative links.

[toc] | [prev] | [next] | [standalone]

#154371

On 2026-07-06, Arno Welzel wrote:

> Maria Sophia, 2026-07-05 04:51:
>
>> Maria Sophia wrote:
>>> Apparently, Android only allows browsers to read:
>>>  /storage/emulated/0/Download/
>>>  /storage/emulated/0/Documents/
>>>  /storage/emulated/0/DCIM/
>>>  /storage/emulated/0/Pictures/
>> 
>> This is frustrating as Android seems to be getting more & more like iOS
>> as it appears that Android's WebView (used by all browsers) cannot open:
>>  file:///storage/emulated/0/0000/...	 
>
> This was never possible. Apps can NEVER access the filesystem outside
> their own sandbox.

This does not imply that. It was possible because the sandboxing did not
prevent that access, or at least didn't have barriers as big as Android
has now.

In older Android versions, at least non-rooted, applications still
cannot access the whole filesystem (e.g. data from other applications),
but *can* access internal and external storage as exposed under /storage/.

> Also before Android 5 this was a special API call
> only possible, if the app has the permission for it. And nowadays, the
> SAF is the preferred way to access files for security reasons.

I'd say it breaks too many things to be useful overall. But where it
works, well, then maybe it's useful there.

>> So I need to find an app that still use direct POSIX filesystem access (and 
>> ignores SAF entirely), or, I can install a local HTTP server in Termux.
>
> You can't find such an app, since this is not possible.

[ /me glances at Emacs on Android doing exactly that ]

>> 3. In Termux, install python.
>>    $ pkg install python
>>     
>> 4. In Termux, start the server
>>    $ python3 -m http.server 8000
>>     Serving HTTP on :: pot 8000 (http://[::]:8000) ...
>> 
>> 5. Open any browser and type the following into the url address field 
>>    http://localhost:8000
>> 
>> 6. Using the Privacy Browser, that brought up the top-level web page.
>>    Then, I tapped on the first link... ... ... Voila!
>>    The manual page2 showed up perfectly this time. 
>> 
>> Whew!
>> Success at last!
>
> Yes, because python3 is *not* an "app", it is just a program.
>
> apps are *not* programs which just start and do something. They are
> packages providing handlers for "actions" like "intentions" and in some
> cases also provide services like "handle incoming TCP connection" or "do
> something once an hour" etc.. - but you must not confuse "app" with
> "program".

That may be true, but is that distinction relevant here? Does this play
any role in the access permissions?

> And no, this was never different in Android - even the very first
> Android versions worked like this.

Then Samsung must have heavily modified the older Android system I've
used, because there are several differences making access more
difficult in Android 15.

-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#154338

Maria Sophia wrote:

> the relative link
>   pages/2.html
> Becomes
>   content://com.android.externalstorage.documents/document/pages/2.html
> which is not a real path. It's a virtual document reference.

I remember that issue (we were replicating hundreds of safety documents 
down to a fire engine, but then android didn't like opening shortcuts as 
file:// URLs

The answer in our case was to install a web server and open them as
http://localhost URLs

[toc] | [prev] | [next] | [standalone]

#154342

Andy Burns wrote:
>> Maria Sophia wrote:
>>>  Data =
>>> content://com.android.externalstorage.documents/document/pages/2.html
>>> Yikes. What's happening? This isn't a real file-system path at all.
>>> It's an SAF document URI.
>> 
>> The index.html is written using normal standard relative links such as
>>  pages/2.html
>>  images/foo.png
>>  css/style.css
>> 
>> These only work if the browser knows the real directory.
>> But the fashuganeh Android SAF apparently hides the directory.
>> 
>> Therefore, SAF URIs cannot be used for relative links inside HTML files.
>> So when the HTML says:  <a href="pages/2.html">
>> Android tries to resolve it relative to the SAF URI, not the filesystem.
>> 
>> Worse, when I tap an HTML file in ZArchiver, it passes the file using
>>  content://ru.zdevs.zarchiver.external/...	
>> Which is ZArchiver's own SAF wrapper, not a real path.
>> 
>> When I paste the full URI into Privacy Browser, I get the error
>>  Webpage not available. 
>>  The webpage at file:///storage/emulated/0/0000/book/name/index.html
>>  could not be loaded because: net::ERR_ACCESS_DENIED
>> 
>> The normal HTML manual expects a real filesystem:	   
>>  /storage/emulated/0/0000/book/name/index.html
>>  /storage/emulated/0/0000/book/name/pages/2.html
>> But Android 16 rewrites everything into SAF URIs:
>>  content://com.android.externalstorage.documents/document/primary%3A0000%2Fbook%2Fname%2Findex.html	 
>> 
>> This means the relative link
>>  pages/2.html
>> Becomes 
>>  content://com.android.externalstorage.documents/document/pages/2.html
>> which is not a real path. It's a virtual document reference.
>> 
>> So why did file:///storage/emulated/0/0000/book/name/index.html fail?
>> Android 10+ treats any custom top-level folder as restricted.
>> 
>> Apparently, Android only allows browsers to read:
>>  /storage/emulated/0/Download/
>>  /storage/emulated/0/Documents/
>>  /storage/emulated/0/DCIM/
>>  /storage/emulated/0/Pictures/	 
>> 
>> Apparently, Occam's Razor says the simplest explanation that fits the facts  
>> is that Android 16 blocks browsers from reading custom top-level folders.
> 
> I remember that issue (we were replicating hundreds of safety documents 
> down to a fire engine, but then android didn't like opening shortcuts as 
> file:// URLs
> 
> The answer in our case was to install a web server and open them as
> http://localhost URLs

Hi Andy,

THANK YOU for confirming the diagnosis and agreeing with the workaround.

Having always dealt with huge HTML references on the desktop, I was wholly
unprepared for the shock that Android 10+ is no longer POSIX compliant.

In terms of WebView, Android 10+ is apparently only POXIX compliant in
  a. /storage/emulated/0/Download/
  b. /storage/emulated/0/Documents/
  c. /storage/emulated/0/DCIM/
  d. /storage/emulated/0/Pictures/

I "could" have solved the problem by putting the repair manual in one of 
those directories, but they're thoroughly polluted much like similar 
directories are on Windows, so my linux-learned rule is to use /usr/local 
instead (e.g., on Windows it's c:\data & on Android it's /0000 or /0001).

Android 10+ was trying to force me away from putting everything I care 
about into a single top-level folder on each sdcard (/0000 or /0001).

But that makes backup and recovery more complicated since then I would have 
to remember where Android forced me to put stuff, and worse, I'd have to 
maintain those Android hierarchies in a clean way when you know that any 
directory that is considered "public" on Windows or Android is polluted 
beyond belief. So we'd be maintaining and cleaning those folders forever.

I like POSIX.
Hence, I hate SAF.

Reassuringly, your experience stated above matches exactly what I ran into. 

The underlying problem seems to be that Android 10+ no longer exposes real 
POSIX filesystem paths to WebView-based browsers outside of the four 
"public" SAF-sanctioned directories (Download, Documents, DCIM, Pictures)/

As of Android 10+, apparently anywhere other than those four highly 
polluted folders is treated as a restricted namespace to WebView clients.

When an HTML file is opened from a custom top-level directory such as:
 /storage/emulated/0/0000/book/name/index.html
Android does NOT hand the browser the actual POSIX path. Instead, it 
rewrites the path into a Storage Access Framework (SAF) content URI.

content://com.android.externalstorage.documents/document/primary%3A0000%2Fbook%2Fname%2Findex.html
But this is not a real directory. It is a virtual document handle. 

What you & I both found out was that because the browser never receives the
true filesystem location, all relative links inside the manual break. 

A link like:
 pages/2.html
gets resolved relative to the SAF URI, producing:
 content://com.android.externalstorage.documents/document/pages/2.html
which does not correspond to any real file on disk. 

As a result, our first indication of the problem is that WebView then
throws ERR_ACCESS_DENIED or ERR_FILE_NOT_FOUND because it cannot traverse
the directory tree. The browser is effectively sandboxed inside a synthetic
document namespace with no ability to follow POSIX-style relative paths.

This is why unzipping the manual worked fine, but opening index.html fails
in every browser tested. Yet, it worked perfectly on Windows (& Linux).

So I knew there was nothing wrong with the document's contents, per se.

The HTML book expects a normal Unix-style directory hierarchy, so I was
confused until it dawned upon me belatedly that Android's new SAF layer
hides that hierarchy behind virtual URIs (much as iOS does to everything).

While I started off trying to find an ancient browser that would respect
POSIX paths, it turned out that both our solutions seem to be apropos.

I'm embarrassed to say that it took me over an hour or two to figure out
that the solution was to bypass WebView's file:// restrictions entirely by
serving the manual over HTTP. 

Had I known what you already knew, it wouldn't have taken me a couple of
hours to figure out what hte problem was and what a likely solution is.

That's one of the beauties of Usenet, by the way, in that now everyone
reading this will save the couple of hours it took for me to understand the
problem and to implement a solution. 
(BTW, I'm curious how long it took your team to figure this one out too!)

With the solution your team and I came up with, HTTP requests do not go
through SAF, so the browser can finally see the real directory structure.

I had no idea what the best server would be, so my implementation was to 
grant Termux full filesystem access, and then start a local web server:
 $ pkg install python
 $ cd /storage/emulated/0/0000/book/name
 $ python3 -m http.server 8000

This sets the $DOCUMENT_ROOT, so that on any web browser, I opened:
 <http://localhost:8000>

At that point everything worked perfectly. All relative links, images, CSS,
and subpages loaded exactly as intended because the browser was now talking
to a real POSIX-backed directory via HTTP instead of a SAF virtual document
tree.

In short, the summary for everyone else to benefit from, that you and I
learned the hard way, is that Android 10+ broke POSIX direct file:// access
for custom top-level directories, but, a workaround is a localhost HTTP
server restores normal Unix semantics. Linux to the rescue, once again.

Thanks again for confirming the approach I ended up with last night.
Had I waited a day, I would have solved it today with your kind advice!

May I ask how long it took you and your team to arrive at that conclusion
and more importantly, what server mechanism you employed, if it's a free ad
free easily available web server, because the Termux method has issues too.
-- 
Usenet allows kind intelligent good-hearted people to help each other out.

[toc] | [prev] | [next] | [standalone]

#154344

Maria Sophia wrote:

> May I ask how long it took you and your team to arrive at that conclusion
> and more importantly, what server mechanism you employed, if it's a free ad
> free easily available web server, because the Termux method has issues too.

Spent a few hours trying to create working content:// URLs, but when 
that didn't work out, used AWebServer, an android build of apache httpd 
with a minimal GUI ...

<https://play.google.com/store/apps/details?id=com.sylkat.apache>

In the end we paid the developer to produce a custom build that
1) auto started the web server
and 2) let us set our own document root

It looks like the latest version has included ftp, mySQL and myPHPadmin

[toc] | [prev] | [next] | [standalone]

#154347

Andy Burns wrote:
> Maria Sophia wrote:
> 
>> May I ask how long it took you and your team to arrive at that conclusion
>> and more importantly, what server mechanism you employed, if it's a free ad
>> free easily available web server, because the Termux method has issues too.
> 
> Spent a few hours trying to create working content:// URLs, but when 
> that didn't work out, used AWebServer, an android build of apache httpd 
> with a minimal GUI ...
> 
> <https://play.google.com/store/apps/details?id=com.sylkat.apache>
> 
> In the end we paid the developer to produce a custom build that
> 1) auto started the web server
> and 2) let us set our own document root
> 
> It looks like the latest version has included ftp, mySQL and myPHPadmin

Hi Andy,\

Thank you for your kind and detailed reply, as Usenet is to not only ask
questions, but to also help everyone lurking not make our same mistakes.

When Android dropped POSIX, Linux again saved the day with localhost HTTP!

It was a painful time-consuming lesson for me, but mainly because I had
trusted that Android was Linux-like when it came to the basic POSIX paths.

Your answer will help save others countless hours of debugging time.
And your answer helps me determine if I should invest in testing it out.

I like what the content of says about how it can help all of us carry on
our mobile devices custom HTML content containing relative filespec paths.
 <https://play.google.com/store/apps/details?id=com.sylkat.apache>
  AWebServer: Apache,PHP,SQL,SSH
  You can explore the files with any SO or browser through wireless.
  AWebServer is an easy and friendly solution to publish your own web in  
  your Android device with PHP and all the features that Apache brings.
  MariaDb the old Mysql sql server is also included and the MyPhpAdmin  
  application has been installed and ready to work with.
  Has integrated a FTP server to upload the contents and is compatible with  
  The Web Server is ready to use and has these features:
  +Apache 2, +Php 7, +MariaDb, +MyPhpAdmin, +Indexes Options, +Ftp server,
  +Logs viewer, +Text Editor.
  This app is based on the famous and stable Apache 2 server, known by its  
  stability in Android devices. Any question or feature request, 
  please send a mail to the developer kryzoxy@gmail.com

It seems your description of how your team solved the non-POSIX problem
aligns pretty much with what I observed. Unfortunately for those of us who
want to use POSIX-compliant paths in documentation, Android 10+
fundamentally changed how applications are allowed to access shared
storage. Anything that is not one of the four SAF-approved public
collections (Download, Documents, DCIM, Pictures) is no longer exposed to
WebView as a real POSIX path. 

Instead, WebView receives a synthetic SAF content URI such as:
content://com.android.externalstorage.documents/document/primary%3A0000%2Fbook%2Fname%2Findex.html
But this is not a directory. It is a virtual document handle. 

We learned the hard what that, because WebView never receives the actual
filesystem path, it cannot perform POSIX operations such as open(), stat(),
or opendir() on the underlying directory tree. As a result, any HTML manual
that relies on normal relative links (pages/2.html, images/foo.png,
css/style.css) immediately breaks. Every browser attempt to resolve these
links relative to the SAF URI inevitably produces invalid paths such as:
content://com.android.externalstorage.documents/document/pages/2.html
which, we found out the hard way, do not correspond to any file on disk. 

WebView then throws ERR_ACCESS_DENIED or ERR_FILE_NOT_FOUND which we have
to debug is only because the browser cannot traverse the non-POSIX
directory hierarchy. In effect, the browser appears to be sandboxed inside
a synthetic namespace with no ability to follow POSIX-style relative paths.

This hypothesis may explain why the manual opened perfectly on Windows (and
would have opened on Linux too), but failed on Android 16 in any browser. 

The HTML book expects a normal Unix directory structure, but Android 10+
hides that structure behind SAF, much like iOS hides their file specs too.

Since I only came up with the idea last night after a couple of hours of
debugging, it's helpful to note that your team's solution and mine converge
on the same principle, which is to bypass WebView's file:// restrictions
entirely by serving the manual over HTTP. 

The reason this works is that HTTP requests do not go through SAF, so the
browser finally sees the real directory tree. 

In your case, you used AWebServer (an Android build of Apache httpd). 
In my case, I used Termux with Python's built-in HTTP server:
 $ pkg install python
 Manually give Python storage access permissions as it doesn't ask.
 Then set the $DOCUMENT_ROOT by starting the server at the top level
 $ cd /storage/emulated/0/0000/book/name
 $ python3 -m http.server 8000

Then, in any privacy-based web browser, I simply set this bookmark:
 <http://localhost:8000>

At that point everything worked exactly as intended. All relative links,
images, CSS, and subpages loaded correctly because the browser was now
talking to a real POSIX-backed directory via HTTP instead of a SAF virtual
document tree.

Comparing the two approaches, your solution is far better'n mine is:
 a. You have a full Apache httpd stack
 b. Your solution has nice GUI controls
 c. Your solution can auto-start
 d. Your solution has a customizable document root
Hence, your solution works in production or institutional deployments.

Compared to mine, your solution is heavyweight but robust as all hell.
I can see why it's good for fire engines, kiosks & embedded deployments
And your solution supports additional services (FTP, MySQL, PHP) if needed

By way of stark contrast, the solution I came up with (Termux + Python):
 a. Is as lightweight as I could make it
 b. With almost zero configuration (other than the starting directory)
 c. Yet, like yours, it creates a pure POSIX environment
 d. Which is good for my Windows/Linux-style adb-scripted workflows

Unfortunately, my solution has none of the GUI, auto-start & service
management of your solution, but it has a minimal attack surface and it's
easy to script and automate if I wish, so it's OK for ad hoc servers.

The takeaway for the team to learn from our trials and tribulations is that 
both approaches solve the same underlying problem that Android 10+ broke
direct POSIX file:// access for custom top-level directories.

Luckily, our solution of localhost HTTP restores normal Unix semantics.

In summary, for those wishing to learn from our investment in testing,
Android browsers cannot directly open HTML manuals from custom directories
anymore because SAF hides the real filesystem. 

Luckily, a localhost HTTP server bypasses SAF to restore POSIX behavior.

Your team's experience confirms the diagnosis and validates the workaround.
I appreciate you sharing the details, especially the fact that you
eventually commissioned a custom build of AWebServer to auto-start and set
the document root. That is extremely useful information for anyone out
there who is deploying large HTML documentation sets in the field.

Thanks again for the insight. This thread will save others the hours we
both invested in rediscovering the same SAF limitations independently.
-- 
POSIX paths died on Android 10+, but localhost HTTP brings them back!

[toc] | [prev] | [next] | [standalone]

#154346

On 2026-07-05 18:38, Maria Sophia wrote:
> Andy Burns wrote:
>>> Maria Sophia wrote:

...

> Hi Andy,
> 
> THANK YOU for confirming the diagnosis and agreeing with the workaround.
> 
> Having always dealt with huge HTML references on the desktop, I was wholly
> unprepared for the shock that Android 10+ is no longer POSIX compliant.
> 
> In terms of WebView, Android 10+ is apparently only POXIX compliant in
>    a. /storage/emulated/0/Download/
>    b. /storage/emulated/0/Documents/
>    c. /storage/emulated/0/DCIM/
>    d. /storage/emulated/0/Pictures/
> 
> I "could" have solved the problem by putting the repair manual in one of
> those directories, but they're thoroughly polluted much like similar
> directories are on Windows, so my linux-learned rule is to use /usr/local
> instead (e.g., on Windows it's c:\data & on Android it's /0000 or /0001).


Why not /storage/emulated/0/Documents/Books ?

I have {external card}/Movies to store movies in my new tablet and it 
works fine with VLC. I also have {external card}/eBooks, but I need yet 
a reader (Calibre is not available that I can find).

I just installed "Librera" from F-droid. It doesn't see the books in 
that folder, even though it asked for permission to see all files. It sees:

/storage/emulated/0/Android
/storage/emulated/0/Download
/storage/emulated/0/Librera

However, if I browse to:

/storage/emulated/0/eBooks using cX file exprorer, and tap on a book, it 
offers me to upload to "Play Libros" (maybe Play Books?) or use "Librera 
FD", and the later works.

It seems that browsing and opening with CX, apps inherits the permission 
in runtime to open that file.



I don't like storing a multithousand file thing in a card that is 
possibly FAT or eFAT. Too many writes to the FAT area.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154348

Carlos E. R. wrote:
>> In terms of WebView, Android 10+ is apparently only POXIX compliant in
>>    a. /storage/emulated/0/Download/
>>    b. /storage/emulated/0/Documents/
>>    c. /storage/emulated/0/DCIM/
>>    d. /storage/emulated/0/Pictures/
>> 
>> I "could" have solved the problem by putting the repair manual in one of
>> those directories, but they're thoroughly polluted much like similar
>> directories are on Windows, so my linux-learned rule is to use /usr/local
>> instead (e.g., on Windows it's c:\data & on Android it's /0000 or /0001).
> 
> 
> Why not /storage/emulated/0/Documents/Books ?
> 
> I have {external card}/Movies to store movies in my new tablet and it 
> works fine with VLC. I also have {external card}/eBooks, but I need yet 
> a reader (Calibre is not available that I can find).
> 
> I just installed "Librera" from F-droid. It doesn't see the books in 
> that folder, even though it asked for permission to see all files. It sees:
> 
> /storage/emulated/0/Android
> /storage/emulated/0/Download
> /storage/emulated/0/Librera
> 
> However, if I browse to:
> /storage/emulated/0/eBooks using cX file exprorer, and tap on a book, it 
> offers me to upload to "Play Libros" (maybe Play Books?) or use "Librera 
> FD", and the later works.
> 
> It seems that browsing and opening with CX, apps inherits the permission 
> in runtime to open that file.
> I don't like storing a multithousand file thing in a card that is 
> possibly FAT or eFAT. Too many writes to the FAT area.

Hi Carlos,

Thanks for asking as I would agree 9999 out of 10K people would just do
whatever the mothership tells them to do, in terms of storing files.

Microsoft tells us to put everything in the polluted directories too.

Having cut my teeth in the 60s, 70's, 80's and 90's days of computers... 
 a. I put my menus in C:\data\menus (which is not polluted by installers).
 b. I put my temp files in C:\tmp (again, which isn't polluted by others).
 c. And I put my data in C:\data (which is not polluted by any programs).
    etc.
I never need to use search because I know where all my files reside.
And I can back up all that I care about by backing up one directory.

On Windows or Linux, programs like Calibre (which, I agree, is one of the
finest document conversion utilities on the planet), find all the files.

But, on Android 10+, the mothership decided to ditch POSIX paths in part.

Given all that, I understand why you suggested that I jut put my data in
/storage/emulated/0/Documents/Books, but the reason I do not use that (and
hopefully I never will) comes directly from my decades of Unix system
administration. On every Unix I have ever worked with, whether that's
SunOS, Solaris, Ultrix, DEC, VAX, AIX, HP-UX, IRIX, BSD, and even IBM
mainframe Unix subsystems, we always kept a strict separation between
 a. system-managed directories
 b. user-managed directories

In fact, as I see it, the entire point of usr/local was to give the
administrator a clean, unpolluted, non-system-owned hierarchy where nothing
is ever overwritten, reorganized, or repurposed by the OS. Like /opt, it is
one place where you can put your own tools, your own data, your own
archives, and know that the operating system will likely never touch it.

Much like anything in Window's public menu & data folders, Android's
"Documents", "Download", "DCIM", "Pictures", etc., are the exact opposite. 

They are system-owned, system-polluted, and system-repurposed. 

As a result of being public refuse garbage pails, they accumulate all sorts
of junk from apps, thumbnails, metadata, temporary files, cloud sync
artifacts and anything else the OS or apps decide to dump there. They are
not stable, not predictable and not safe for long-term archival storage.

To back up completely everything I care about on Android, is this simple:
 adb pull /storage/emulated/0/0000 C:\data\datedbackup\0000 (internal sd)
 adb pull /storage/XXXX-XXXX/0001 C:\data\datedbackup\0001 (external sd)

If I start putting files willy nilly all over Android, I'll be just like
the average hoi polloi proletariat who can't find anything on their
devices, and worse, who complain like hell when the system needs a backup.

I know you're well meaning, but in effect your suggestion is equivalent to
me as it would be for me to tell a Unix admin to store their personal tools
and archives inside /usr/bin or /var/tmp simply because "the OS can see
it." I know you're a Linux owner, but that's just not how I do things.

To back up completely everything I care about on Windows, is this simple:
 robocopy C:\data D:\data-backup /MIR /R:1 /W:1 /XJ

My directory philosophy is simple:
 I always create one top-level directory that is mine and only mine, 
 and I put everything I care about inside it (if at all possible).
 a. On Linux, that is /usr/local.
 b. On Windows, that is c:\data.
 c. On Android, that is /0000 (internal) and /0001 (external).

This gives me:
 a. a single hierarchy to back up
 b. a single hierarchy to restore
 c. a single hierarchy that never gets polluted
 d. a single hierarchy that never changes names or semantics
 e. a single hierarchy that is not touched by the OS
 f. a single hierarchy that behaves like a real Unix directory tree
Unfortunately, Android's SAF filespecs do not meet any of those criteria.

Your own example actually seems to aptly demonstrates the problem where
Librera cannot even see your eBooks directory unless you open files through
CX File Explorer. That is because SAF grants per-file access tokens, not
directory access. CX hands Librera a one-file token, so Librera can open
that single file but still cannot enumerate the directory. 

This is exactly the same SAF behavior that broke my HTML manuals.

Regarding your FAT/exFAT concern, you are absolutely correct that FAT-based
SD cards can suffer from excessive FAT table rewrites when storing large
directory trees. A directory containing tens of thousands of HTML pages and
JPEGs will hammer the FAT metadata area. Fortunately, my Android 16 tablet
has no SD card as it was a return to me of a gift I gave an iOS user to try
to convince them that their religion was wrong, so, my files in /0000 are
in ext4-backed internal storage with journaling & proper metadata handling. 

So I fit your concern as it's safe for large POSIX-style directory trees.

This brings us back to the core issue Andy and I both hit, which is that
Android 10+ no longer exposes real POSIX filesystem paths to WebView-based
browsers outside the SAF-approved yet highly polluted public collections. 

Anything else is rewritten into a synthetic SAF URI such as:
 content://com.android.externalstorage.documents/document/primary%3A0000%2Fbook%2Fname%2Findex.html
This is not a directory. It is a virtual document reference. 

Because WebView never receives the actual filesystem path, it cannot
perform POSIX operations such as open(), stat(), or opendir() on the
underlying tree. As a result, any HTML manual that relies on normal
relative links (pages/2.html, images/foo.png, css/style.css) immediately
breaks. Every browser that I tried last night tried to resolve those links
relative to the SAF URI, producing invalid paths like:
 content://com.android.externalstorage.documents/document/pages/2.html
which do not correspond to any real file on disk. WebView then throws
ERR_ACCESS_DENIED or ERR_FILE_NOT_FOUND because it cannot traverse the
directory hierarchy.

This explains why the manual opens perfectly on Linux and Windows, but
fails on Android. The HTML book expects a normal Unix directory structure,
but Android 10+ hides that structure behind SAF, much like iOS does.

Andy's team and I independently arrived at the same workaround, which was
to explicitly bypass WebView's file:// restrictions entirely by serving the
manual over HTTP since HTTP requests do not go through SAF, so the browser
finally sees the real directory tree.

Andy used AWebServer (Apache httpd for Android).
I used Termux + Python but accomplished, essentially, the same effect.

So the summary for everyone on Usenet is:

Android browsers cannot open HTML manuals from custom directories because
SAF hides the real filesystem. A localhost HTTP server bypasses SAF and
restores normal POSIX behavior.

And the summary for your kind and quite naturally normal question is:

I do not use Documents/Books for the same reason I do not use /usr/bin on
Linux, as it is not my directory, it is not clean, and it is not stable.

And, I appreciate your FAT/exFAT concern, which is valid for SD cards, but
my internal storage is ext4, so /0000 happens to be in internal storage. 

You are hitting the *same* problem Andy and I hit, which is that Librera
cannot see /storage/emulated/0/eBooks, but if CX File Explorer opens a
file, Librera can read that one file. These are all SAF behaviors, and not
Librera behaviors, not Calibre behaviors, nor EPUB behaviors.

So, to solve your problem, even though HTTP bypasses SAF completely, the
question of whether it solves your specific workflow depends on whether the
apps in your specific workflow can open HTTP URLs. Can they?
-- 
Unfortunately SAF blocks file:// but luckily, HTTP bypasses it completely.  

[toc] | [prev] | [next] | [standalone]

#154351

On 2026-07-05 20:54, Maria Sophia wrote:
> But, on Android 10+, the mothership decided to ditch POSIX paths in part.
> 
> Given all that, I understand why you suggested that I jut put my data in
> /storage/emulated/0/Documents/Books, but the reason I do not use that (and
> hopefully I never will) comes directly from my decades of Unix system
> administration. On every Unix I have ever worked with, whether that's
> SunOS, Solaris, Ultrix, DEC, VAX, AIX, HP-UX, IRIX, BSD, and even IBM
> mainframe Unix subsystems, we always kept a strict separation between
>   a. system-managed directories
>   b. user-managed directories

I have my ways in Linux, but when I use a different OS, like Android, I 
adapt to its ways. I don't try to enforce my older habits ;-)

I did a test, downloading that rust book to my tablet, into

/storage/emulated/0/Documents/rust/book

and then tried to point firefox to it. Did not work. Then I navigated to 
the "index" in CX, and tapped on it. It asked what to use, I said FFx, 
and it happily opened the "book".

It is pointing to 
http://127.0.0.1:26108/sdcard/0/storage/6130-3634/Documents/book/index.html

I guess CX created automatically a web server on the fly, which is a 
neat trick. Nice app.

-- 
Cheers,
        Carlos E.R.
        ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#154353

Carlos E. R. wrote:
> I have my ways in Linux, but when I use a different OS, like Android, I 
> adapt to its ways. I don't try to enforce my older habits ;-)
> 
> I did a test, downloading that rust book to my tablet, into
> 
> /storage/emulated/0/Documents/rust/book
> 
> and then tried to point firefox to it. Did not work. Then I navigated to 
> the "index" in CX, and tapped on it. It asked what to use, I said FFx, 
> and it happily opened the "book".
> 
> It is pointing to 
> http://127.0.0.1:26108/sdcard/0/storage/6130-3634/Documents/book/index.html
> 
> I guess CX created automatically a web server on the fly, which is a 
> neat trick. Nice app.

Hi Carlos,

Yes. I agree. We didn't add the Linux/Windows folks on the original four
articles in this series, but the fourth article mentioned your exact trick:

  > So I need to find an app that still use direct POSIX filesystem 
  > access (and ignores SAF entirely), or, I can install a local HTTP 
  > server in Termux.
  > Apparently, these file managers have their own internal HTML renderer
  > that bypasses WebView, so I might resort to testing these one by one.
  >  a. MiXplorer (best option)
  >  b. X-plore
  >  c. Older versions of Cx File Explorer 
  > But I think the most reliable will be to use Termux, which can access
  > /0000 directly because it uses POSIX APIs (not SAF) & then start a server.

Had the Python server not worked, I would have tried the method you used.

What I find useful and interesting and even enlightening, is that all three
of us (you, me and Andy) independently came up with the same HTML solution.

The only other solution than an HTML server that I can think of is to make
Calibre work to convert the huge multi-file zip into a single epub file.

Since Calibre can do almost anything, as it's one of the best programs on
this planet for converting anything to anything else, I'll test that out.
-- 
Every post to Usenet should strive to add value that wasn't there before.

[toc] | [prev] | [next] | [standalone]

#154360

Maria Sophia, 2026-07-05 00:40:

> New-to-me tablet that someone gave back that I had given them as a gift.
> 
> I was copying an already-unzippled set of 25,000 html and JPEG files for a
> book from Windows to an Android tablet but it was taking forever (hours) so
> I stopped it and copied only the 500MB zip file in just a minute or two,
> but now that it's on Android how do I best unzip it so it works as HTML.

Cx File Explorer can also extract ZIP files in Android:

<https://play.google.com/store/apps/details?id=com.cxinventor.file.explorer>

About viewing locally stored HTML files: usually some things are not
possible due to security restrictions, since the references in the file
need to be translated to Storage Access Framework requests which is not
that simple.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.mobile.android

csiph-web