Broken directory

I cannot get into a directory – when I double-click it, I get:
Message from Filer: Error when reading ADFS::HardDisc4.$.Projects.rofl – Broken Directory
Is there anything I can do about this? (I’m running in RPCEmu)

Discknight should do the job for you, it’s a disk checker/repairer which will read & fix Filecore-formatted disks (and others), and works under RPCEmu. You can get it here: http://www.armclub.org.uk/products/discknight/

£10 though… Not sure the data in that directory is worth that much. Are there any free tools?

There is a free version of DiscKnight, which will at least tell you whether it can understand the problem.

The data in that directory may not be worth £10, but my concern is whether deleting the directory will also remove the fault(s). Anyone else have an opinion?

DiscKnight has been the only tool maintained for a few years now. There may be a free tool for earlier-format discs; I don’t know. I suspect most people forgot how to use the free tool some years ago.

Excuse stupidity on my part – RPCEmu? Isn’t that HostFS?

As for the Broken directory, it may be a simple hiccup in writing the directory (the check values don’t match) or it could be symptomatic of bigger problems.

I don’t think you can just delete the damaged directory – RISC OS would need to delete the files in the directory and to do that….

The OP’s error message included “Error when reading ADFS::HardDisc4.$.Projects.rofl” which indicates his installation of RPCEmu is using a filecore-formatted disk as well as HostFS, and that the problem is there rather than the latter. Certainly a broken directory can indicate more widespread disk problems: does pressing F12 and typing *checkmap reveal more than one problem? If so I suggest the tenner could be money well spent: a corrupted disk map can mess up Messenger and produce unpredictable random errors in other programs. The broken directory /cannot/ simply be deleted, IME: as it can’t be read, it can’t be deleted.

DiscKnight check-only free version reports only the directory I am interested as problematic:

Checking directory structure
.................................................................................................
* Directory $.Projects.rofl checksum corrupt (is &DB, should be &23)

* Directory $.Projects.rofl master sequence number mismatch (start &24, end &23)
......................................................

---------------------------------------------
    Disc is bad, 2 faults found
    Run a repair (-f and -u flags) to fix
---------------------------------------------

I find broken directories a pain – they happen (I’ve had a few!), like other things which happen spontaneously! You can’t delete them, but you can usually rename them to something like zbrokendirectory (z to put them out of the way at the bottom of the filer window) and replace them, perhaps from your back-up?

When you remake your media, you can omit them from the new version.

I paid the full UKP10 for DiscKnight, well worth it, but have dealt with broken directories as above.

Good luck,

John

Well, what I did in the end is this:
I remembered that there was only really one file in the broken folder with significant changes since my last backup.
I used the free read-only version of Commander (http://www.vigay.com/software/commander.html) to find most of the sectors occupied by the file (by searching for a string I know it contained – all the sectors were together – I do not know whether that is an ADFS feature or just luck), and then wrote a little BASIC program to dump those sectors to files, which I stitched together with Zap, along with the missing bits from backup, getting 99% of the way to the latest contents of the file. The remaining 1% was restored from memory.
Finally, I saved off everything to HostFS, exited RPCEmu, replaced hd4.hdf with a new one, relaunched RPCEmu, copied stuff back from HostFS, and all is now well!
Interestingly, there were a few files whose names were incompatible with Windows (due to containing ‘?’ or ‘>’), and could therefore not be copied to HostFS. I had to rename those, and rename them back afterwards.

I used the free read-only version of Commander (http://www.vigay.com/software/commander.html) to find most of the sectors occupied by the file

If you’re comfortable with a sector viewer, you might be able to repair the Broken Directory. I know that the version you have is read-only. It will allow you to read the directory structure and, if you spot something wrong, to create a little program to read-fix-write the relevant sector (back up your disc image first, just in case!).

Sergio explained a long time ago:

broken directory: this error is issued when RISC OS finds a directory that has some ‘strange’ data in it (no directory identifier, wrong checksum, etc.). The only way to cure this is to remove the directory from its parent but unfortunately this is impossible using standard commands (wipe, delete, remove). Broken directories usually lead to inconsistent maps because all the files contained in them disappear from the directory structure but not from the map (see above).

[ http://wss.co.uk/pinknoise/Docs/Arc/Filecore/DiscMap.html ]

So, if you’re up to it and don’t want to buy DiskKnight, find the directory structure on disc, crack open the PRMs (if you have them, PDF versions otherwise – volume 2) and compare what is there with what the documentation thinks is supposed to be there. Check the checksum.
Be wary of the entire disc structure if the directory is truly broken (as in overwritten with something else).

Sergio continues:

On the other hand, a ‘Broken Directory’ can be the evident sign that something actually has been corrupted on the disc, so you can find that some other files are damaged. In fact, RISC OS can easily notice the wrong directory header/checksum but it cannot really understand if a text file has been corrupted!

“all the sectors were together – I do not know whether that is an ADFS feature or just luck”

AIUI Filecore will normally save files contiguously, non contiguous files can occur if a file is extended and will occur if no contiguous unused area is available on saving. Filecore seems to manage to have contiguous files more often other file systems. I suspect this be due to RISC OS and its programs often only accessing programs and files to load and save i.e. not update this bit and that bit.