| |
Krill
Registered: Apr 2002
Posts: 2825 |
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? =) |
|
... 6 posts hidden. Click here to view all posts....
|
| |
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: 11100 |
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: 2825 |
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: 1987 |
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: 2825 |
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: 2825 |
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! |
| Previous - 1 | 2 - Next |
