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 Maria Sophia <mariasophia@comprehension.com> - 2026-07-08 10:32 -0400
            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 Maria Sophia <mariasophia@comprehension.com> - 2026-07-08 11:14 -0400
                      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 Chris <ithinkiam@gmail.com> - 2026-07-08 17:51 +0000
                    Re: How to copy & read a huge zipped book with thousands of html & jpeg files "Carlos E. R." <robin_listas@es.invalid> - 2026-07-08 21:49 +0200
                      Re: How to copy & read a huge zipped book with thousands of html & jpeg files Chris <ithinkiam@gmail.com> - 2026-07-09 07:05 +0000
                Re: How to copy & read a huge zipped book with thousands of html & jpeg files Chris <ithinkiam@gmail.com> - 2026-07-08 17:44 +0000
                  Re: How to copy & read a huge zipped book with thousands of html & jpeg files Dave Royal <dave@dave123royal.com> - 2026-07-09 06:09 +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: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 3 of 3 — ← Prev page 1 2 [3]

#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 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web