[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::amiga_v1

Title:	AMIGA NOTES
Notice:	Join us in the NEW conference - HYDRA::AMIGA_V2
Moderator:	HYDRA::MOORE

Created:	Sat Apr 26 1986
Last Modified:	Wed Feb 05 1992
Last Successful Update:	Fri Jun 06 1997
Number of topics:	5378
Total number of notes:	38326

2006.0. "TurboBackup V1.0 Warning" by NAC::PLOUFF (Cider Season Has Begun) Thu Dec 15 1988 12:06

    Just a day or two ago, the program TurboBackup V1.0 came over Usenet
    comp.binaries.amiga.  I'd like to put out a caution to anyone who uses
    it. 
    
    The normal diskcopy command (from CLI) makes diskettes which differ,
    even though they have the same name.  (Is this "magic number" the
    creation date?)  This means that you can have both the original
    and copy in your drives, and AmigaDOS will tell them apart.
    
    TurboBackup makes _identical_ copies of diskettes.  AmigaDOS can't
    tell them apart, and the machine _will_ freeze or guru if two TB'ed
    disks are in the drives at the same time.  In my opinion, this is
    a big shortcoming.  I can imagine, say, making a copy with TB, changing
    some files on the copy, then wanting to make a partial update to
    the original disk.  Boom -- guru city.
    
    The document file does clearly state this, but it's down in the
    fine print.
    
    Conclusion:  If you make copies using TurboBackup, you can use either
    the original or the copy, but never use both at the same time.
    
    Wes

T.R	Title	User	Personal Name	Date	Lines
2006.1		ANT::SMCAFEE	Steve McAfee	`Thu Dec 15 1988 16:42`	12
	> a big shortcoming. I can imagine, say, making a copy with TB, changing > some files on the copy, then wanting to make a partial update to Wes, are you sure about that? I was under the impression that if you modify either the original or the copy they can then be used at the same time. I've been using Turbobackup V1.0 since mid-summer with no problems and it is quite fast. You could be right though. I don't distinctly remember ever putting the two disks back in after one has been modified. steve m
2006.2	It's odd.	STC::HEFFELFINGER		`Thu Dec 15 1988 22:42`	11
	I thought it mighty peculiar that the program asks you to remove one of the disks before you quit it. I never saw any gurus but I did get one mighty confused workbench when I had both disks mounted. I only used it once just to see if it works, so I don't have much else to report. Gary
2006.3	But... but...	ODIXIE::MCDONALD	Surly to bed, surly to rise...	`Fri Dec 16 1988 15:31`	6
	Couldn't you just rename one of the disks from <whatever> to <whatever>_bck? Seem's like I remember reading that AmigaDos identifies disks by creation date and disk name. A bit of trouble to do, perhaps, but if TurboBackup is faster, ...
2006.4	Rename the disks!	TLE::RMEYERS	Randy Meyers	`Fri Dec 16 1988 16:20`	10
	Re: .3 The Disk ID is set whenever the is is labeled (the disk's name is set). So, renaming one of the disks, even if you rename it to itself, will cause it to get a unique ID. However, simply changing the files on the disk does not effect the disk ID. The author of the utility may think that duplicating the disk ID is a feature. I consider it to be a nasty bug.
2006.5	What's the advantage if you must rename disks?	LEVERS::PLOUFF	Cider Season Has Begun	`Fri Dec 16 1988 16:44`	11
	re: .2 Seems to me that TB plus disk rename time is roughly equal to the time needed to use diskcopy. The only advantage I can see to TB as it's now configured is to duplicate disks that you will sell or give away, especially if you have more than 2 drives. Setting whatever it takes in the root block to make a disk identification unique might take, oh, an extra 3 seconds. Why the authors left this out is not at all obvious. And it's too bad, because otherwise TB looks like quite a nice program.
2006.6	The bug probably wasn't a design goal	TLE::RMEYERS	Randy Meyers	`Fri Dec 16 1988 18:20`	11
	Re: .5 > Setting whatever it takes in the root block to make a disk > identification unique might take, oh, an extra 3 seconds. Why the > authors left this out is not at all obvious. I suspect that they just didn't know how to solve the problem. After all, to copy a disk you just copy all of its tracks... I suspect that if someone told them to rename the new copy to itself would clear up this weirdness, they would do it.