Jump to content
OLD CS1

Random IO errors and undelete-able file on SCS2

Recommended Posts

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??

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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

 

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Haha 3

Share this post


Link to post
Share on other sites

 

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.  ;) 

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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)

  • Like 3

Share this post


Link to post
Share on other sites
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.

 

  • Like 3
  • Thanks 1

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

  • Thanks 1

Share this post


Link to post
Share on other sites
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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...