jedimatt42

@9640News, this was a conscious decision I made, as a native text file represented as a variable length records would have to be packed into sectors to know how many sectors it takes. This would slow down cataloging for a cosmetic reason. Instead, I believe I stated this somewhere... Maybe just the wiki... But for native_text_dirs, the line count (or record count from a TI perspective) is used instead of the sector count when cataloging. So, it isn't arbitrary, and you are right it could be improved.

I appreciate the patients exhibited. Update 3.16 - May 6th 2023 - Really only direct-output to a native text file if the FDR being written is for a DV80 file - less logging when manipulating native text files ( was showing all records of the file in the tipi.log ) where BAS. is the value of NATIVE_TEXT_DIRS configuration. - tested copying a 5 sector DV80 to my TIPI.BAS. dir, verified checksums, verified reading lines, verified equivalent from linux - tested copying TIPICFG PROGRAM image into TIPI.BAS. and verified checksums, verified identical from linux (TIFILES blobs) - tested copying the DV80 back to TIPI. with different name to verify native text dirs was not in play, verified checksums, verified equivalent from linux ( TIFILES blobs, names different in header ) - tested copying PROGRAM image from native text dir enabled location to non-native-text-dir location. verified checksum, verified identical from linux ( TIFILES blob, same name ) @9640News Maybe this'll work for you. Note to others: I haven't seen any indication that this ever caused trouble unless the NATIVE_TEXT_DIRS was in play.

Ok, I tested with a program that I forgot would reset my NATIVE_TEXT_DIRS... so my previous tests were invalid and led me to fix an adjacent issue. I am able to reproduce the same log pattern you provided now...

I have a 16 bit checksum command inside ForceCommand.

Now that I read the comp-sci definitions, I guess it wasn't really an off by one, but a failure to round up. Originally, (earlier this week), I had code that was always rounding up to the next block size, even if there was no usage in that last block. I think it is now properly conditional.

Update 3.15 - May 6th 2023 ( round two / cause all good pies are quickly consumed. ) - Fix direct-input limit comparisons, again. Corrects the issue I can observe in ForceCommand with copying a PROGAM image into a directory marked as NATIVE_TEXT_DIRS... ( or anywhere for that matter )

Ok, oddly enouugh, this is what that off-by-one error I recently fixed in direct-input was about.

Oh, I tested SAVE to a NATIVE_TEXT_DIRS entry, but not copy... there is something wrong for sure.. The goal is only DISPLAY VARIABLE 80 files should get written as native text files on direct-output.

Update 3.14 - May 6th 2023 - Fix broken PROTECT bit after recent native file handling changes ( you cannot protect a native file, but any TIFILES file should support it ) - Fix broken JSON file handling with URI drive aliases. The ".?" modifier needs to stay with the device name you are using.. URI1.?J.request.json, or PI.?J.HTTPS://something.crazy.hostedby.com/request.json, it should not be in the value of the URI alias mapping. - Make restore more tolerant of files being renamed, nolonger crash the webui if they don't have the timestamp and perfect name... they still have to be named ____.tar.gz - Add some archive validation before extraction when the restore button is hit. - Add restore completion status to the web-ui

If you download the new backup now from 3.x it should set the response headers correctly to instruct the browser to leave it be.

Ok, another fragile decision I made. it expects the file name to have a more specific format in another place ( probably cause I expected the os file timestamp to be unreliable when copied from machine to machine ) Try renaming it to have the time stamp in the name, here is a good backup file name: tipi-backup-2023-04-01T114801-0700.tar.gz

@InsaneMultitasker your expectations around JSON are fine. But I broke something in the detection of the ?J flag when I extended handling of the NATIVE_TEXT_DIRS... One difference in how you are using this though... I would expect the ?J to be used with the device name... so URI1.?J.stuff and not placing ?J in the beginning of the URI1 value. So, right now, the ?J is having no effect, and you are getting the old read-only non-json behavior that you would have seen before I implemented ?J... I have a fix, after more testing, will release in the morning.

I should be able to fix it so that whatever you upload from this page is considered a backup, regardless of what you named it.

Update 3.13 - May 5th, 2023 - Fix Beery's report of NATIVE_TEXT_DIRS applying to siblings that start with the same letters as an entry in the NATIVE_TEXT_DIRS list.

Ok, I see what I did wrong... with the implied subdirs logic. I'll work up a fix.

ok, normally the backups show up in a list, and have a checkbox next to them you can select one, and then press restore. But since your upload was renamed first, you found another bug in my backup system... It only looks for backups that match this glob pattern: /home/tipi/tipi-backup*.tar.gz ( I suspect the upload succeeded ) so, you can ssh into the PI, and then rename /home/tipi/tipibk.tar.gz to /home/tipi/tipi-backup-one.tar.gz then refresh the page in the web-ui and it should list the backup. then you should be able to check the box next to it, and then press 'Restore Backup' ( Sorry this has been a hassle for you )

There was a little hint above the list of files, that shows 'Creating archive...' and then it'll refresh once a second, if the status is complete the 'Creating archive...' will go away... If it does not show the 'Creating archive' then it should be safe to download the backup file. You can verify the downloaded file. It'll be called a .tar.gz, but your browser has probably uncompressed it ( another bug I fixed in 3.x ) so it is at that point just a .tar with a bad name. You can check the validity with a tar friendly tool like 7zip, or tar. In 3.3? I think, I fixed the download headers so browsers should stop un-gzipping the backups on download. And I fixed the restore to tolerate that a thing named .tar.gz might be just a tar, so that you can restore a good backup from 2.x to 3.x.

There is a bug in the web-ui for the 2.x line, that shows the link to download the backup before it is done creating the backup archive... It should have had a label saying it was still processing, but the UX wasn't good... I have improved this in 3.x, but that doesn't help you much. If you still have the 2.x SD image you can try to download the backup again. If you don't then the backup archive you have is likely a truncated tar file. My restore code can be found here, https://github.com/jedimatt42/tipi/blob/af30fd0cd42a29d0053baf0394014f411fd8533a/setup/restore.sh#L33 Basically the tar is extracted into the /home/tipi directory with everything set to be owned by the tipi user. If you only have a partial tar file, you might be able to extract some of it by: cat backup.tar | tar -xvf - -C /home/tipi --owner=tipi I would expect the last file listed as it extracts to be corrupt. It is hard to predict how much will be lost.

Update 3.12 - May 3rd, 2023 More support for native files. Native files, is the term I use for files on the linux filesystem that are not encased in a TIFILES container ( have no header that represents the spinny-disk FDR ) TIPI has for a while, recognized some file extensions to be text, and so treated them like D/V 80 files, with some limitations. If a native file didn't have a known text file type extension, then it would treat it like a D/F 128 file, per the ancient tradition. Now direct-input is supported for native D/V 80 files, and D/F 128 files. direct-output is supported for native D/V 80 files. The current state of things is oriented toward being able to copy these implied file types from TIPI storage to other 4A media like your ramdisks and such. If you have a directory specified in the PI.CONFIG NATIVE_TEXT_DIRS setting, then you should be able to copy native text files in and out of TIPI as though they are D/V 80 files. I also fixed rename for native files as well.

Update 3.11 - May 1st, 2023 - Fix bounds checking for direct-input. This should error at the correct point if the direct-input request attempts to exceed the bounds of the TIFILES file.

so, what's fun is that a 5 block TIFILES file should be ( you said this already I think... ) 128 + (5 * 256) = 1408 bytes. The t: 1664 in the message above is the calculated total size of the file.. I have no idea what bug took me through a maze to calculate it as: ((((len(bytes)-128)/256)+1)*256)+128... when it should have just been len(bytes), no calculation, just measurement. Nothing like a good old +1 looking you in the eye and saying, "You're nearly 50 kid, and you still write off by one errors..." Needs a little more testing though, before I push out a patch. Note: on the 4A, DM2K and ForceCommand and other direct-input access based software, programs are respecting the FDR sector count, so we are not seeing this big manifest. It is a bug in TIPI, but it hasn't been corrupting your TIFILES.

@InsaneMultitasker & @9640News I thought that was a year in the past. I guess I should have followed up to make sure it was passing your test cases back then. I'll be asking to make sure we close the loop this time. I thought block 0, is the metadata block for direct-input, then blocks 1-5 are the 5 actual 256 byte blocks used in the file. so, failing on read of block 6 seems appropriate. I'll start by clarifying the logging, making sure the metadata read is distinctly indicated from the file data. But that aside, I must have still been logically off by one somewhere... counting relative to the TIFILES size instead of the other limit, maybe. The file size in the TIPI logging from your example does look like it is 1, 256 byte block too large. I'll have to look into it. I don't have any 4A software written that ignores the metadata read in block 0, and tries to read beyond the boundary. So I guess I'll have to write a test case. I can probably just temporarily break something in ForceCommand to read until error instead of read until the expected count.

Running TI-invaders from the FinalGROM99 menu should not hang with TIPI connected while the PI is off. Running Tutankham might, but not because of TIPI. Running the TIPI halt from ForceCommand and then issuing an FG99 command to switch cartridges might hang depending on if you have the clock bar running. Running original TI Extended BASIC will hang if the PI is off. This has been the case since the beginning of TIPI. As XB tries to access disk immediately. In the future please provide more specific detail in requests or in this case a statement of observation.

FG-99 stuff is ridiculously vague. Try again.

This page might be interesting, if you have seen it before: http://www.stuartconner.me.uk/ti/ti.htm#bank_switching