Web based file manager

Once again encountered the limits of 32 bit Linux, manely 2GB files.  For an upload, it seems the connection is broken & the browser resends the file when it hits the limit.  Java had 64 bit file sizes from the beginning but 32 bit C was never upgraded.  You still have to provide good old -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 flags on the 32 bit raspberry pi.  Helas %ld for printf is no more.  You now have to use %lld to print 64 bit ints.

Also, long as a function argument didn't work on the 32 bit pi.  You have to use int64_t everywhere to get reliable results.

There was another corner case in decode_url where it wasn't supposed to convert + to "   ".  According to https://docs.oracle.com/javase/8/docs/api/java/net/URLDecoder.html  The plus sign "+" is converted into a space character "   " .

But this turned out to break URL decoding.

The quest for a JRE for raspberry pi 4 began.  Chances are all your raspberry pi's are running a deleted version of raspian.  The packages are all stored on

 http://raspbian.raspberrypi.org/raspbian/

& they blow away all but the current year's version.  They're not intended to be set & forget gadgets anymore.  They're pushing engagement revenue by requiring constant updates.

The only Java option for armv7l is an Oracle download.  They require a 2 factor account signup.

https://www.oracle.com/java/technologies/javase/javase7-archive-oracledownloads.html

The JDK burns 158MB.  It contains the JRE which is only 97MB, but you have to compile webphone on the raspberry pi with the matching JDK version.  It would entail burning a lot of money on new SD cards for all the raspberry pi's or dealing with very little recording time.  

The alternative is porting or having AI port webphone to C++, which would reduce it to a few kb.  It would be quite a waste of several days of porting from android, but it might have been a necessary evil, either way.  There's always been a dichotomy between 1 group of developers which prefers minimal overhead & 1 group which prefers maximal overhead.  The GNU STL has gotten good enough that lions are satisfied with using some of it but not stream operators.

---------------------------------------------------------------------------------------------------------------------------------------------------

Ended up doing it the old fashioned way, seeing it as faster than iteratively developing prompts.  Problems were found in the Java version.  The C++ version handled some UTF-8 sections better than the Java version & vice versa.  The Java & C++ versions could run side by side for testing.  

Filename formats which existed on the PC but not the phone presented new challenges for both versions.  Firefox has problems with some UTF-8 codes in the A HREF.  It would really require some kind of hash function to represent filenames.  Fortunately, it's manely envisioned to just access sound files in a closed environment, rather than the odd unicode filenames downloaded from gootube.

root@piano:/root% l webphone
-rwxr-xr-x 1 root root 55044 Jan 13 07:08 webphone

root@heroine:/amazon/root/WebPhone% du -c *.class
4       DirEntry.class
4       Stuff.class
8       WebServer.class
4       WebServer$SortByDate.class
4       WebServer$SortByName.class
4       WebServer$SortBySize.class
28      WebServer$WebServerThread.class
56      total

The 32 bit C++ executable was a hair smaller than the java executable.  

After 5 days of manual porting, it was finally able to run in a sound recorder with only 4GB free. 

The mane problem is the lack of ifdef in Java.  The mane WebServer.java class has 34 java includes & 5 android includes, but no easy way to swap out the android includes.  This depends on Stuff.java which is android heavy.  This was leaning towards a new platform class with wrappers for all the android bits or maybe making Stuff.java platform specific.  WebServer.java is such a mess, replicating it in its entirety would not be ideal.  Http is quite a mess, being a text protocol that mixes binary data with natural language, carriage returns, linefeeds, many different encodings of the same characters.

Having said that, WebServer.java is actually partially replicated in Ultramap https://github.com/heroineworshiper/ultramap.  The ultramap version is much simpler since it doesn't have full file management.

android.text.Html.fromHtml would be quite difficult to replicate in Java SE.  It was quite a struggle to translate between the many html character codes, but there could be a reduced functionality.  If only the test cases for that function were still around.

With most filesystem based devices, lions are just using NFS.  Only the raspberry pi zeros absolutely need a browser file manager.  Wifi isn't up to NFS, but those devices just aren't seeing any use.  They amount to 2 sound recorders.  Maybe they would see more use if they had a browser file manager, but they also need a way of announcing their IP addresses.  It typically involves getting in on a serial console & running ifconfig, in which case you might as well use scp.  Webphone works on a phone because phones can show their IP address & getting a console is a pain.  What might work is a good old browser bookmark, but a PC browser isn't the only client for webphone.

Webphone would allow a phone browser to manage & download files on all the embedded devices instead of just the sound recorders.  That could be a win.

The 1st step might be abstracting the android dependencies in the android version & testing it in android.

------------------------------------------------------------------------------------------------------------------------

It seems android.text.Html.fromHtml just converts an html string from the upload textbox:

What ＊is＊ the wavefunction？.mp4

Into a string for java.io.File where the \&\#65290\;  is converted to charAt() value 65290

When it goes the other way, it uses its own encodeHtml function to convert the charAt values to &#; strings.  This function came from grok.

Helas, if A HREF points to a $#; encoded string, the browser doesn't send a GET request.  Neither can the browser handle % unicode encodings in the A HREF.  It only converts spaces to %20.  Fortunately, there was never a desire to download a funky filename using webphone.  The funky filenames play properly in the android programs.

---------------------------------------------------------------------------------------------------

Many grok prompts later, the standalone version was working.

The PC's filesystem could be accessed on the phone.  Pretty clumsy on a phone browser.  It defaults to a ridiculously small font & large textbox size for the editor even though it's fine on the PC browser.

Big news with the sorting direction arrows & a button to select all the checkboxes.  Lions only discovered HTML had standard character codes for arrows in the last few years.  Those were a long time coming.

Years ago, remote file management was manely based on FTP.  Support for that grew & grew until we had basically transparent access to remote files.  All that went away in the late 90's & got replaced by loose ssh commands.  The security hole of having FTP on a large network was the mane reason, but very few of us are on public networks anymore.

The big risk nowadays seems to be IPv6.  Those addresses are once again as public as IPv4 was 30 years ago.

The easy solution is to make servers reject IPv6 connections.  The only method that works in android is

socket.getInetAddress() instanceof Inet4Address

The java.net.preferIPv4Stack setting doesn't work.

The next step would be certificate based authentication, but for a program with no users, it's not necessary.  There's actually a box in Firefox for setting a client certificate.  Then it would need HTTPS support, which would entail creating yet another batch of certificates for the server, a big step up from the current Server class.

The way webphone is written, using it on a raspberry pi would manely involve installing a JVM, making a new class to handle android log statements & instantiating the same classes outside android.  It's still more convenient than FTP, since it doesn't need a client program.