QB Quirks
7 messages in this thread
During a recent experience to repartition my hard drive, I've worked with
QB (v 5.0.3) a bit and am a bit disappointed with some aspects of the
program. I'm probably not the first person to go into this, but here are
the "quirks" I found, that I'd like to see fixed:
When multitasking QB with ProWrite, I saved a text file from PW that was
to be archived (after QB built the catalog but before it went to back up
the file). When QB reached the modified file, the backup hung. I could
only restart the entire backup (1 disk from the end of the 25-disk
backup!). I'd like to see the program at least not lock up, and
preferably multitask better by prompting me to update the catalog or skip
the file.
You could try to get around the above problem by telling users not to
multitask, but that's not the best solution, IMHO. The following
describes strange behavior with selective restores, which are confusing
and, when a backup program acts strangely, cause concern over the
integrity of the backup (even if there is no connection, any "buggy"
appearance makes one uneasy about the backup).
Selective restores sometimes don't request volumes that are needed right
away and sometimes ask for ones that aren't needed at all. Using two
drives to restore, I started the restore with volume 1 in df0: to load the
catalog (df1: is empty). Leaving volume 1 in the drive, I PROCEED with
the restore and while the program waits for me to click on START it shows
the messages "DF0: Ready" and "DF1: Insert #23". Okay, I insert #23 in
df1: and click START. The program puts up a requester to insert #22 in
df0. Why didn't QB request #22 before I hit START?
Then later it would say "Insert #24" even though the program was jumping
to a later disk in the catalog and didn't really need #24. Why didn't the
program message request the correct volume that would be required? That's
a question about usability, not a request for a technical explanation.
I'm sure there are logical reasons that QB is programmed to do things this
way and am not asking for an explanation of why it happens. Please fix
these aspects of QB.
Let me get this straight, you were trying to back up a file that was open?
I'm not sure that this will work. Depends on how PW opens files. Probably
locks them though. I'll bet that QB doesn't gracefully handle this.
I never could see the purpose in multi-tasking while the backup happens,
but then I have had a tape drive since I got my first "53 disks required"
message from QB. 1 drive + some tapes is less expensive, and more
convenient than 200+ HD disks for backing up my hard drives.
Brian — Cruising on AutoPilot…..
Brian,
I don't know how QB is opening files, but don't quite understand the
connection with the bug I've reported. What I described was changing the
file after QB built the catalog but long before it was actually archived.
QB shouldn't do anything with the file until it goes to archive. When
saving the file from ProWrite, there was no lock on the file, no error
reported when the file was saved. It seems to me that whether QB is
modified to handle this situation or not, it should at least not crash.
I'd like to expand my drive capacity soon, but currently live through the
floppy backups for such a small setup. Better to use 25 disks than not
have a backup!
I was wondering if ProWrite had locked the file. IF ProWrite _HAD_, it
would easily explain why QB was "hanging up." If PW was locking the file
while it had the file open, and Quarterback continually tried to open the
file because it was a "locked" file, QB would appear to hang up.
It could also be that QB expects the file to be in it's original position
when it tries to back the file up. When you save a file in _any_ decent
word processor, it 1) renames the old file, 2) creates a new file with the
changed information, and 3) optionally deletes the old file. This makes
the file move, and the old "chain" of file blocks invalid. This could be
confusing QB.
Off topic: If you're having to feed the thing floppies, how could you get
any work done to begin with? The continuous interupptions would drive me
nuts. You're the first person I've heard of who does work while backing up
his Hard drive to floppies.
Brian — Cruising on AutoPilot…..
I understand your reasoning on the possible confusion with the file.
As to the question of working during a backup, if you have a
multitasking machine, I don't see what's so unusual about wanting to
do more than one thing on that machine. Particularly if you're
backing up one partition while working on another (which is what I
usually do), there should clearly be no problem. It's just in this
case I goofed, but was still surprised the result was the program
locking up.
Regardless of the reason, the program should be more idiot-proofed than it
is. Can we agree on that? A well-designed program should never rely
solely on a statement like "NEVER DO X" in the documentation, and then
assume the user will never do X and crash if the user does.
By the way, is anyone from CCS/New Horizons reading any of this?
John,
Yup, I am reading this. I will have to try and duplicate you particular
situation. What should have happened is the file should have been truncated and
the remainder of the backup should have proceeded normally.
Randy Brooks
Central Coast Software
A division of New Horizons Software, Inc.
FWIW, Randy, I complained about the same problem here in AmigaVend several
months ago. All I was told is "We'll look into it." Never did hear
anything more…