Formatting disks causes re-scan

[hackerb9]

Hi, I've just noticed a small bug in the otherwise quite excellent ADTpro client. When a disk is formatted using ADTpro, the next action (receiving or formatting another disk) is always slowed down by a re-scan of volumes. This can be tedious when receiving many disks since ADTpro doesn't seem to be able to write to disks that haven't been pre-formatted. (If I don't format first, I get a bunch of X's representing disk errors when writing.)

Just thought I'd let you know.

--b9

[david__schmidt]

Hi, I've just noticed a small bug in the otherwise quite excellent ADTpro client. When a disk is formatted using ADTpro, the next action (receiving or formatting another disk) is always slowed down by a re-scan of volumes. This can be tedious when receiving many disks since ADTpro doesn't seem to be able to write to disks that haven't been pre-formatted. (If I don't format first, I get a bunch of X's representing disk errors when writing.)

Hi - thanks for the kind words.

Now, the volume screen does refresh after a format happens. The set of volumes is "cached," and that cache is invalidated when you format something, because the volume name changes. If you hit "R" to rescan right after you format, you'll not only see the new name of your disk, but you'll also fly right by when receiving. Maybe you could have a formatting "session" where you format a batch of disks at once - that way you'll always have a fresh one to stuff in the drive when you are ready to receive.

You should have seen it before... it used to refresh the volume list EVERY time it needed to show the volume screen! The "fix" was to build a cache, and only invalidate it when a format happened.

[hackerb9]

The set of volumes is "cached," and that cache is invalidated when you format something, because the volume name changes.

But wouldn't ADTpro know what the volume name changed to since it's the one that formatted the disk? So, instead of invalidating the cache, it could just update it so that it knew that S6D1 is "/blank". Or am I missing something? (I usually am.)

--b9

[david__schmidt]

The set of volumes is "cached," and that cache is invalidated when you format something, because the volume name changes.

But wouldn't ADTpro know what the volume name changed to since it's the one that formatted the disk?

Quite right. With some effort > 0, I could figure out which volume got formatted and fix it in place. It's just easier to go back out and say, "fix everything." One single call to code that already exists. Purely a laziness thing on my part. Well, that, and there's not a lot of bytes left in the Uthernet version to play with for enhancements. So everything that goes in needs to be accompanied by effort to streamline and remove some other bloat. (Not hard to do, since I am a very bloaty assembler programmer.)

This is a worthwhile improvement to make, for sure. I know it doesn't help, but... "you should have seen it before! The way it is now is so much better that it was!"

(Edit, a day or two later...)
Ok, I got off my lazy duff and fixed it. I'd like to credit you in the release notes - let me know if you'd like to be credited by something different than your handle.

[hackerb9]

Thanks for fixing it! No need to credit me; you did all the work.