+OLD CS1 Posted December 23, 2021 Share Posted December 23, 2021 It could be the SD card. It could be the SCSI card. It could be something hardware, but I am looking at software (the easy stuff) first. I am running an WHT-SCSI with an SD2SCSI. It has been rock-solid for a few years. Then... I have a file in the root of my SCS2 that I cannot open or delete. DM2K says it is write protected, I get an error #7. I get I/O ERROR 07 when I try to open it in BASIC. It is a DV/80 file. I know what error "07" is, but it does not make sense. Now, this happened coincidentally to random lock-ups and I/O errors when accessing SCS2. I do not recall the instability before the file was created. So, either the instabilities cropped up and caused this file, or the file has caused the instabilities, assuming the problem is software and not hardware. So, going forward with this assumption, how can I deleted a non-deleteable DV80 file in the root of my SCSI drive?? Quote Link to comment Share on other sites More sharing options...
Ed in SoDak Posted December 23, 2021 Share Posted December 23, 2021 Save over it with a known working file? I managed to save a file with a fracked-up name to my Mac desktop that had a space as a first character or a period or something illegal. Caused the desktop to fail to appear and reload/fail ad infinitum. Had to boot from a different drive, move all but the bad file to a new folder which I then renamed "Desktop" and replaced the old folder containing the botched file. I discovered the bad one by trial and error where to stop copying, for as soon as it might show in the directory window, it would blank and refresh the same way as the desktop had. Weird! You may end up having to do something similar; copy off everything else, then reformat. Maybe sector editing, if you're savvy about that on a SCSI drive, to rename or remove it from the directory tree. Quote Link to comment Share on other sites More sharing options...
+dhe Posted December 23, 2021 Share Posted December 23, 2021 I'm guessing this is on a TI and not a Geneve? I asked Tim about the chkdsk in MDOS and he said don't rely on it to much. So that lead me to wonder who we did with error on large drives? Maybe pull the SD Card and look at it with TI image tool? Wish'en we had a tool that would go back and read each sector and try to write it back like spinrite from old days. And a chkdsk or fsck that would check the structural integrity. Does anyone know if there is a sector editor that will work on all platforms on the TI or Geneve? And lastly, it sucks, but you could have four partition and multiple devices, it might pay to copy off everything you can get from the problematic partition to another partition or device and reformat it. I think I would also for a second opinion take it to tiimage tool and see if you can get a back up that way or not. 1 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted December 23, 2021 Author Share Posted December 23, 2021 I understand the filesystem enough to perform surgery with a hex editor if need be. I figure it is an unprintable character causing problems. Have run into that on many occasions on other systems. 1 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted December 23, 2021 Author Share Posted December 23, 2021 To that end, is there a hex editor for the 99 which can do this? 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted December 23, 2021 Share Posted December 23, 2021 7 hours ago, dhe said: Does anyone know if there is a sector editor that will work on all platforms on the TI or Geneve? There is SECTORONE by Randy Moore that works on the Geneve. One has to be careful about sector editing to delete files, especially on a hard drive. It would be easiest to just remove the file from the listing of files. What can become a problem is trying to recover the sectors as since it is a bad file, those same sectors it "thinks" are used by the file, could have actually been marked as used by another file or files. Thus, recovering marked sectors as used could lead to subsequent corruptions of other file(s). Simplest thing, backup everything on your SCSI to a TIPI folder, reformat the SCSI drive, and copy back since you have a SCSI2SD. If with a Geneve, you can map to another empty scsi drive using the SCSMAP command, copy files to it, reformat the bad drive, then copy the files back. Copying SCSI to SCSI on the Geneve will keep the time/dates intact while copying to the TIPI drive will result in all files having the current time/date as they are copied over. Beery 1 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted December 23, 2021 Author Share Posted December 23, 2021 25 minutes ago, 9640News said: Simplest thing, backup everything on your SCSI to a TIPI folder "Simple" if you have such a device. I have options for doing this, and there is nothing on the drive that I cannot rebuild some how. But I also like to live dangerously. 3 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted December 23, 2021 Share Posted December 23, 2021 3 hours ago, OLD CS1 said: But I also like to live dangerously. Santa would consider this file for his 'naughty' list. Is this a Geneve- or TI-based setup? The error you encounter is most often caused by an incorrect pointer or incomplete cluster set in the File Descriptor Record (FDR). It can also be generated by an error that occurs during the saving of the File Descriptor Index Record (FDIR) - are the files in alphabetical order? If not, this is a telltale sign. For corrective actions are you able to create a raw sector-based image of the TI partition ? If so, you may be able to use TI Image Tool ( @mizapf 's tool) to inspect the file structure. This has come in handy for me, especially to identify overlapping files before attempting to perform a DSR-based delete or a manual repair/edit. If you'd like me to take a crack at recovery, PM me. I enjoy digging into these sorts of corrupted drives, in part because it often sheds light on the DSR operations and potential, future ways to protect the data. 1 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted December 23, 2021 Author Share Posted December 23, 2021 33 minutes ago, InsaneMultitasker said: Santa would consider this file for his 'naughty' list. Is this a Geneve- or TI-based setup? C'mon, guys... 33 minutes ago, InsaneMultitasker said: The error you encounter is most often caused by an incorrect pointer or incomplete cluster set in the File Descriptor Record (FDR). It can also be generated by an error that occurs during the saving of the File Descriptor Index Record (FDIR) - are the files in alphabetical order? If not, this is a telltale sign. Ah, good point. No, this file is named (visibly) "TXT" but is near the top of the directory and definitely not in order. 44 minutes ago, InsaneMultitasker said: For corrective actions are you able to create a raw sector-based image of the TI partition ? If so, you may be able to use TI Image Tool ( @mizapf 's tool) to inspect the file structure. This has come in handy for me, especially to identify overlapping files before attempting to perform a DSR-based delete or a manual repair/edit. If that will work versus a hex editor, I can create a raw image of the SD card and do the same. Just means I have tear the system apart to do it. 46 minutes ago, InsaneMultitasker said: If you'd like me to take a crack at recovery, PM me. I enjoy digging into these sorts of corrupted drives, in part because it often sheds light on the DSR operations and potential, future ways to protect the data. Thanks. I can send you a copy of the image to play with if I cannot get it working. 1 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted December 23, 2021 Share Posted December 23, 2021 36 minutes ago, OLD CS1 said: Ah, good point. No, this file is named (visibly) "TXT" but is near the top of the directory and definitely not in order. The simplest and usually the safest method is to fix the alphabetized FDIR (index record) by removing the pointer to the 'bad' file, and if necessary, adjusting the file count to match the total pointers in the FDIR. If the file is located in the root, the FDIR is at sector 0x0040 and the file count is in sector 0x0000. If the file is in a subdirectory, the process is similar in that you would locate the subdirectory descriptor record (DDR) and associated FDIR, editing the index and file count accordingly. Adjusting the bitmap is usually not required; if the DSR reserved the sectors during the IO operation, we just consider them 'lost' for good at this point. It's not worth the effort to recover them. We could resort the index however, if the clusters are incorrect or wrong, one or more files may overlap at a later date. 36 minutes ago, OLD CS1 said: If that will work versus a hex editor, I can create a raw image of the SD card and do the same. Just means I have tear the system apart to do it. I don't recall if Sector One v1.40 (40 column, for the TI) works with the SCSI card though in theory, it should be possible use the program to edit the SCSI drives if you use "WDSx" since the level 2 opcodes are the same and WDS is in the SCSI EPROM as a valid device. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted December 24, 2021 Author Share Posted December 24, 2021 1 hour ago, InsaneMultitasker said: I don't recall if Sector One v1.40 (40 column, for the TI) works with the SCSI card though in theory, it should be possible use the program to edit the SCSI drives if you use "WDSx" since the level 2 opcodes are the same and WDS is in the SCSI EPROM as a valid device. Where would I find that? Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted December 24, 2021 Share Posted December 24, 2021 15 minutes ago, OLD CS1 said: Where would I find that? It was on WHT last time I looked. I can't get to my TI system at the moment, however, I think that the first filename (on my system) is "SECTOR140" which either denotes version 1.40 or version 1, 40 columns. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted December 24, 2021 Author Share Posted December 24, 2021 35 minutes ago, InsaneMultitasker said: It was on WHT last time I looked. I can't get to my TI system at the moment, however, I think that the first filename (on my system) is "SECTOR140" which either denotes version 1.40 or version 1, 40 columns. I found the GROM cartridge converted by @Tursi, thank you. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted December 24, 2021 Author Share Posted December 24, 2021 When I switched Sector One to WDS, it tries to hit WDS1 and hangs up. So, the easy way is not going to work. Maybe Sunday I will have time to pull the drive (SD card) out. Quote Link to comment Share on other sites More sharing options...
+dhe Posted December 24, 2021 Share Posted December 24, 2021 Maybe we could setup a buggered HD image for MAME. And then write up a little how to fix each type of issue doc - something like Don Grono's - Hidden Power of the Disk Fixer? Quote Link to comment Share on other sites More sharing options...
Ed in SoDak Posted December 24, 2021 Share Posted December 24, 2021 Might Disk Review from Funlweb have SCSI capability? I can't test for that. It does have sector editing. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted December 27, 2021 Share Posted December 27, 2021 On 12/23/2021 at 8:35 PM, OLD CS1 said: When I switched Sector One to WDS, it tries to hit WDS1 and hangs up. So, the easy way is not going to work. Maybe Sunday I will have time to pull the drive (SD card) out. I was using DU2K to validate my Horizon Ramdisk DSR setup -- I had forgotten that Fred's DU2K contains a sector editor that works with DSK, SCS, WDS, and IDE. (Confirmed: Sector One locks my system if I run it with a SCSI card in place of the HFDC. Very strange, I've added this to my research bucket) 3 Quote Link to comment Share on other sites More sharing options...
+dhe Posted December 27, 2021 Share Posted December 27, 2021 To use DU2K (for sector editing) on a Geneve, does one need to use ROMPAGE and/or EXEC? Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted December 28, 2021 Share Posted December 28, 2021 On 12/27/2021 at 12:13 PM, dhe said: To use DU2K (for sector editing) on a Geneve, does one need to use ROMPAGE and/or EXEC? DU2K was my first program that does a check if ROMPAGE has been done. If not, it is doing it for you. 3 1 Quote Link to comment Share on other sites More sharing options...
+dhe Posted January 2, 2022 Share Posted January 2, 2022 On 12/23/2021 at 9:35 PM, OLD CS1 said: When I switched Sector One to WDS, it tries to hit WDS1 and hangs up. So, the easy way is not going to work. Maybe Sunday I will have time to pull the drive (SD card) out. For those playing at home, was that Sunday the 26th or Sunday the 2nd? Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted January 2, 2022 Author Share Posted January 2, 2022 11 minutes ago, dhe said: For those playing at home, was that Sunday the 26th or Sunday the 2nd? Should have been either, but I got busy and getting into the PEB is more time investment than I have available. 1 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted January 3, 2022 Author Share Posted January 3, 2022 On 12/23/2021 at 6:58 PM, InsaneMultitasker said: If the file is located in the root, the FDIR is at sector 0x0040 and the file count is in sector 0x0000. The VIB points to 0040, but 0040 holds information for a file which is actually in a sub-directory, with no previous or following FDIR pointers. Head hurts too much to wtf right now. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted January 3, 2022 Author Share Posted January 3, 2022 I take it back. Sector >0040 holds what appears to be a FDIR. I need to follow the links from there. What I was looking at previously was >0040 x @>10 (>F0, for 16 sectors per AU,) thus sector >0400. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted January 3, 2022 Author Share Posted January 3, 2022 With a clearer head I figured it out. The first two bytes of the FDIR at sector >40 holds >01 >89. No sector matched. I did a search of the drive for the ASCII "TXT" and, lo, found it at sector >1890. THAT is >0189 x >10 (16 sectors per AU.) Indeed, this file is first and should not be. I have not yet checked out the file descriptor as I am heading to bed. Assuming it is intact, I wonder if just setting the name in the FDR will fix the issue. Commodore drives have the Validate command which checks the block availability map against blocks actually in use by files. Do we have such a TI native tool? 1 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted January 3, 2022 Author Share Posted January 3, 2022 1 hour ago, OLD CS1 said: I have not yet checked out the file descriptor as I am heading to bed. Assuming it is intact, I wonder if just setting the name in the FDR will fix the issue. Before dozing off, I took the plunge and set the file to an appropriate name for its location. The file is now accessible, in that it can be read and appears to contain the data it was meant to contain. I figure at this point deleting it should be fine, though I would still like to validate the sector bitmap. That will have to wait until tomorrow. We had a heavy cold front move through the area, and while the storms are gone we are under strong winds forecast until mid-morning. Power is flickering and I would rather not put the UPS to a test. 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.