Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > Requests > Undelete/unformat on disk images command-line tool
2021-11-28 11:44
Krill

Registered: Apr 2002
Posts: 2980
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? =)
2021-11-28 12:28
iAN CooG

Registered: May 2002
Posts: 3194
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)
2021-11-28 15:16
chatGPZ

Registered: Dec 2001
Posts: 11386
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 :)
2021-12-02 09:21
Krill

Registered: Apr 2002
Posts: 2980
Quoting Groepaz
the process is really trivial though
Yes, i was aware of that. =)
But...
Quoting iAN CooG
Alt-f3 CheckImage function is the best tool for restoring d64 images I know
What makes it better than other such tools, includuding D64scan?
2021-12-28 11:05
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?
2021-12-28 11:35
Krill

Registered: Apr 2002
Posts: 2980
Quoting Claus_2015
I 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.
2021-12-28 18:00
chatGPZ

Registered: Dec 2001
Posts: 11386
claus almost exactly described what d64scan does =)
2021-12-30 15:38
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 :-).
2021-12-30 16:20
chatGPZ

Registered: Dec 2001
Posts: 11386
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)
2021-12-30 16:29
Krill

Registered: Apr 2002
Posts: 2980
Not so sure about the levels. 1 does more than 0, 2 does more than 1, etc., but 4 does less than... 2? =)
2021-12-30 17:12
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 :-)?
2021-12-30 17:19
JackAsser

Registered: Jun 2002
Posts: 2014
What about hidden t/s chains that actually occupy the dir entry blocks you’re about to write? Care must be taken here.
2021-12-30 17:21
Krill

Registered: Apr 2002
Posts: 2980
Quoting Claus_2015
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?
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. =)
2021-12-30 17:22
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.
2021-12-30 17:48
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?
2021-12-30 17:56
Krill

Registered: Apr 2002
Posts: 2980
Quoting Claus_2015
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?
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. =)
2021-12-30 19:47
Claus_2015

Registered: Oct 2012
Posts: 53
Ah, that totally makes sense indeed!
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
csabanw
Twoflower/ΤRIΛD
Jangler/Artline Desi..
Chrx/Design/Chaos
Brataccas/HF
Genius/Xenon
Guests online: 114
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Organizers
1 Burglar  (9.9)
2 Sixx  (9.8)
3 hedning  (9.7)
4 Irata  (9.7)
5 Tim  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.067 sec.