You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
I added the following code after the line that does the SHELL to
copy the file to the Zip drive:
Code:
ON ERROR RESUME NEXT
BeginTestDrive:
NN$ = DIR$(Zip$ + ":\*.*", 16)
IF ERR THEN GOTO BeginTestDrive
ON ERROR GOTO ErrorHandler
SHELL "lfnsort N " + Zip$ + ":\ /S", 0
I got them both,
Older software could have a problem with external devices.
Smartdrive did not write the fat while windows wasd closing down.
completely lost the contents this way.
I did remove the disk using right mouse options. (shortcut to zip)
The newer software i use, zip51, and internal drive does not have these problems.
It's ~4x faster.
The caching is enabled if you boot windows while having placed a disk already.
(At least with external ones)
Remove disk before booting.
We've been installing internal ZIP drives in our customers' systems for years (ever since they've been available).
Never used the external units, though. At this point we have hundreds of systems out there, all of which back-up
to ZIP daily, sometimes twice a day. We've never received a report of this "click of death" you're talking about.
The only problems we've ever experienced with ZIP drives were a few D.O.A. units, but any unit that worked once
installed has kept working without fail... ZERO failures to date.
Have you experienced the "click of death" with internals? Are they Iomega brand drives, or could they be the units
produced by Panasonic? Just curious, because our experience is so radically different than what I'm reading here.
More zip horrors! Someone in my office borrowed the power supply
from my portable zip drive, so I had to borrow one from someone else.
Same model, same Iomega supplied power supply, but the drive wouldn't
work correctly, more then an hour wasted screwing around trying to
find out what was wrong. Finally, I borrowed yet another one &
it worked! The point is, if those guyes can't make a machine that
is insensitive to minor variations in the power supplies, then the
thing is a failure waiting to happen. I'm with Lance, CDR.
I spoke about the "Click Of Death" to another associate today, and he mentioned that when he experienced a COD, it effectively "erased" the zip disk, so important backup data was lost when inserted into the faulty drive! Argh!!! It also rendered at least one other disk completely unusable, even in another drive.
One very common mistake I see when folks purchase backup units (like a ZIP drive, or whatever), is that they almost always only purchase just one unit! If that unit breaks down, in say 2 years (when the unit is long obsolete), what are they going to read the backup media with?
At least with CDR/CDRW, you can always find a CDR drive somewhere, purely because they are installed with most PC's out of the box.
Tape drives offer another set of problems: compatibility. Usually this is due to tapepath (mis)alignment which can render a tape unusable except on the drive that created it.
This is less of a problem with, say, DAT (which uses an autotracking scheme), but low RF signal level on the tape can still cause problems. Tapes that are used and reused often in unclean or worn machines can encounter tape-edgs damage that will show up as a problem the minute you actually need to restore a critical file.
I have also suffered the Click of Death. The only backup
medium I use is DLT and CDR for little stuff. My experience
with Portable medium like the Zip and the old Sparc drive has
been very bad.
Clay says he is already using the [synchronous] SHELL statement, so I would hazard a guess that his "problem" is finding a way to detect when the delayed write (caching) has completed.
Any ideas anyone? (other than writing a "flag" file after the SHELL "XCOPY..." and waiting until that file appears - I would not expect this to be a reliable method since the file-system may indicate the file exists, even before the delayed write has committed all of the data to the disk).
Disclaimer: I've never used a Zip drive to I'm not even sure if caching works with them. Stories of the ZIP drive "click of death" are all too frequent for me to consider using such a medium. For example, one of my customers uses one for a nightly backup, and they have been through 3 or 4 units in the past 2 years.
I built a small program that works automatically
(with Windows Scheduler) to backup the folders
or files that you need to save. I use it to backup
every night (about 850 megs) to an Orb drive.
email me at:[email protected] and I'll send it to you
(or anyone else, for that matter)
How can I detect if a local drive is no longer busy (i.e., writing data)?
Specifically, I'm talking about my USB Zip drive. I've written a
program that backs up the kids' personal folders in one big swoop
(right now, their combined byte size of data is appr. 69MB). The reason
I need to know if the drive is no longer busy is so I can run a
directory/files sorter on the ZIp diskette after backing up those MANY
files. I use xcopy32 to copy the direcotry/file structure in one
pass with a SHELL statement. Unfortunately, as soon as the SHELL
statement has completed, the sorting program TRIES to run. I *could*
but a SLEEP statement after the SHELL, BUT, that'd be pretty sloppy
programming <grin>.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Leave a comment: