| |
Krill
Registered: Apr 2002
Posts: 2839 |
Undelete/unformat on disk images command-line tool
Claus and i are planning to add an undelete/unformat option to cc1541.
This would find files (or fragments of files) in disk images that aren't listed in the directory, then re-add them (possibly with a synthetic name) and mark their blocks as used.
In order to avoid re-inventing the wheel...
Does such a tool exist already? Does it work well? Could it do anything better? Is it open-source? Has it been thrown at the entire CSDb corpus? =) |
|
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
I know
D64scan V0.3 (rather good) and 64Copy V4.46 Beta (DOS only as it's 16 bit DOS program, unmaintained and closed source. Alt-f3 CheckImage function is the best tool for restoring d64 images I know) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11113 |
d64scan is based on a rather messy hax0red d64 lib (the one from magervalp) which is why i never bothered to release the source.
the process is really trivial though, simply follow the file chain from every sector, create a new file from that. you want an option to omit 1-block files. maintain a list of already used sectors to avoid cyclic links. you dont want to do it in place on the d64, create a new one, so you can actually extract all file chains. and you might pick existing (deleted) names from the directory when they point to the start of such chain. should be ready in an evening :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Groepazthe process is really trivial though Yes, i was aware of that. =)
But...
Quoting iAN CooGAlt-f3 CheckImage function is the best tool for restoring d64 images I know What makes it better than other such tools, includuding D64scan? |
| |
Claus_2015
Registered: Oct 2012
Posts: 53 |
So I spent some thoughts on this (seems the one evening was already used up doing that :-)). What I intend to do is a several step approach to take the different probabilities into account what could have happened:
1. Go through the existing and linked directory blocks and search for scratched files.
2. Go through all sectors on the directory track and search for scratched files, to catch unlinked directory blocks.
3. Finally, go through all unallocated sectors on the disk and search for chains of at least two and add new directory entries for those.
I would always terminate sector chains (no matter by which step they were found) as soon as they collide with anything (including themselves).
At the moment I do not see a reason to not do this inplace on the input image (maybe with the exception of running into the 144 file limit, which would suck anyway). Or am I missing anything? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Claus_2015I would always terminate sector chains (no matter by which step they were found) as soon as they collide with anything (including themselves). Better would be not to touch the sectors themselves at all, but just to recreate BAM and directory.
Terminating a cycle would raise the question where to terminate, and also things like two chains merging into one might be intended.
And what to do with blocks that don't make much sense to the DOS, like with Transwarp or Bitfire/Spindle/Sparkle files, without any valid T/S links? :)
Better add all files and pseudo-files to the directory, and mark weirdnesses via tags in the synthetic names. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11113 |
claus almost exactly described what d64scan does =) |
| |
Claus_2015
Registered: Oct 2012
Posts: 53 |
Ok, it's cc1541 so we might want to provide more control than other tools. My suggestion is to have 4 levels of restore to chose from:
level 0: Fix dir entries for files with valid t/s chains.
level 1: Also add wild sector chains with valid t/s chains.
level 2: Also fix dir entries with invalid t/s chains (i.e. terminate the t/s chain).
level 3: Also add and fix wild invalid t/s chains (i.e. terminate the t/s chain).
level 4: Only restore all dir entries without touching any t/s links.
Wild means no reference from any scratched dir entry. Level 4 would be the advanced Krill level, while the other levels would cater the mere mortals :-). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11113 |
What about a mode that also restores single block files... put their "loadaddress" into the filename so its easy to see which could be legit files (perhaps extra mode to only restore those that have $0801) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Not so sure about the levels. 1 does more than 0, 2 does more than 1, etc., but 4 does less than... 2? =) |
| |
Claus_2015
Registered: Oct 2012
Posts: 53 |
For single block files: how would you differentiate them from trash? By a track link of 0? Seems this might create many trash files, or?
Levels: true, I also thought about this. Level 4 somehow does not fit into the row. Maybe I call them modes, then it doesn't have to :-)? |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
What about hidden t/s chains that actually occupy the dir entry blocks you’re about to write? Care must be taken here. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Claus_2015For single block files: how would you differentiate them from trash? By a track link of 0? Seems this might create many trash files, or? If the block doesn't have a valid T/S link (and isn't linked to), the DOS wouldn't load it anyways, so there's little value in having a directory entry for it.
If the first byte (track link) is 0, the block may be considered invalid if the payload bytes after the last one (as denoted by the second byte in the block) are not 0.
There should be some kind of log to list invalid blocks, however. =) |
| |
Claus_2015
Registered: Oct 2012
Posts: 53 |
Conflicts with the directory will be taken care of: first, all chains that shall be restored are marked in the BAM, then directory entries are created and sectors allocated for that as needed, taking the new BAM into account. |
| |
Claus_2015
Registered: Oct 2012
Posts: 53 |
Krill: sorry, I don't get it. You say that single block files (which have a track link of 0 in their only block) should be ignored, if the sector link byte is not 0? Wouldn't it normally not be 0, if it was an actual file? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Claus_2015Krill: sorry, I don't get it. You say that single block files (which have a track link of 0 in their only block) should be ignored, if the sector link byte is not 0? Wouldn't it normally not be 0, if it was an actual file? No no, i mean that regular single-block files have a "T/S link" of (0, index-of-last-byte) and are filled up with zeroes.
Anything beyond the last byte shall be 0, so if there are non-0 bytes beyond the payload, something is weird. =) |
| |
Claus_2015
Registered: Oct 2012
Posts: 53 |
Ah, that totally makes sense indeed! |
