Weird event

I had something weird happen on my ARMX6 yesterday. I was working on some BASIC programs, which run from a directory called Programs, which in turn contains a sub-directory called Libraries. I was editing a file in the library in StrongED, and testing a program which called the library file. The program issues a set of CDIR and COPY commands to create and populate a directory tree elsewhere on the disc. After one error, I changed something in the library file I was editing, and pressed F3 to save. StrongED came back “Not Found”. I discovered that the Programs directory was now empty – no files, no subdirectories.

Nothing I was testing ever issues RENAME, DELETE or WIPE commands.

I saved the library file elsewhere.

I then ran DiscKnight, first in CHECK mode (disc is good), then repair (disc is good, nothing found).

I’ve since recovered from backup, but the question is whether there would have been a way to recover the missing files. I don’t know whether they were renamed, deleted, or the directory file maybe overwritten resulting in it being seen as empty, or a hardware fault did something.

Does DiscKnight find files etc no longer in a directory? Does it do this with files removed by a delete command? Is there anything which can do this?

As I said, I’ve now recovered from the problem, but I’m thinking about the possibility of this happening again.

I don’t know whether they were renamed, deleted, or the directory file maybe overwritten

Did you look in the directory tree your program was in the midst of creating?

I have memories of StrongEd being unexpectedly sensitive to the current value of CSD, but on searching the forums I could only find this incident which Fred was unable to reproduce.

Does DiscKnight find files etc no longer in a directory?

My understanding of Filecore format is that once you’ve deleted a file, it’s gone.

If the disc was reported as clean, there isn’t an issue with files going missing due to corruption. DiscKnight would have reported something is wrong, and the repair process is quite good at restoring anything that was in or below a corrupted directory, although sometimes the filenames and types can be lost.

As to what has happened, the most common causes would be:-

1. A rogue *Wipe command (or script using *Delete) has deleted the tree
2. You’ve accidentally *move’d the tree somewhere
3. You’ve dragged and dropped it somewhere with shift held down

For the latter two, try searching the entire disc for a known filename.

DiscKnight has a feature to /recover/ deleted files, but it’s only as a desperate last measure in the absence of backup. It just turns every block of free space on the drive in to a file in $.Lost+Found, and then its up to you to look at the contents of those file and pick out anything parts that look like a valid file and save it elsewhere. When you’ve finished delete all Lost+Found to get the free space back.

I’ve since recovered from backup, but the question is whether there would have been a way to recover the missing files. I don’t know whether they were renamed, deleted, or the directory file maybe overwritten resulting in it being seen as empty, or a hardware fault did something.

For some protection¹ against accidental or mistaken deletions I would recommend the use of Transient
v2.10b includes the TrapDelete module, which traps delete FilerAction in a fashion that allows you to restore whole directories or application directories exactly as they were before deletion.
If you really want to delete then you will need to hold down shift at the same time as the deletion, otherwise the “deleted” item is in a holding directory until it expires (user configurable expiry time etc)

¹ There is no perfect solution on any platform.

For the latter two, try searching the entire disc for a known filename.

I did thatm and several times for different files. What struck me as odd was that the directory wasn’t deleted, but all of its contents were. That makes an accidental drag elsewhere very unlikely.

There is a rename in the test program, but it renames a single file, and is only run once. No wildcard involved there. I’ll have a look at Transient – it would have told me if there had been a delete action at least.