View Full Version : Verify Ignores Location and Goes to Internal HD
May 22nd, 2012, 07:24 PM
I copied an archive to my USB drive. To ensure the copy was good I decided to Verify it with Paragon Home 10. I went into the verify tool and selected file view and browsed to the archive. When the verification starts the archive being verified is the original on the internal HD as indicated by the path, not the USB HD! The USB light is not flashing while the disk light on the computer is. I also turned off the external and the verify continued.
Same in HDM11.
I'm losing faith in this program.
May 23rd, 2012, 08:03 AM
Isn't that "somewhat" normal since it uses the drive ID and you copied it to another drive ID?
May 23rd, 2012, 09:31 AM
I wouldn't say so. After all the archive is just a file or files. The Verfiy section after file selection (I'm in File View) shows the selected archive as being something like: L:\folder\myarchive where L: is the USB drive but when the verify runs it then displays N:\folder2\myarchive where N is the drive letter of the original internal drive.
I wouldn't care about the N:... being display but that is also what is being verified, not what I selected.
I tried deleting the archive from the database but that didn't help. However, your comment about the drive ID is interesting since I was wondering why it knew to go back to N, the location of the original.
May 23rd, 2012, 12:32 PM
I can't remember exactly what the issue was but it seems as though using the same drive ID all the time for archives had some benefits.
May 23rd, 2012, 12:51 PM
Given what seems to be happening if I change the drive letter to the internal drive to something else and then change the drive letter of the usb drive to the old internal letter it might work.
I booted up the recovery CD and it worked probably because it doesn't care about any database info and the drive letters are different anyway.
May 23rd, 2012, 01:12 PM
Yes, changing the USB's drive letter to what was the internal drive's letter worked. It is happily verifying the USB drive archive.
I guess this may be one of those "how do you work" things. I always make a manual image whenever I feel the need to of my OS and this is stored on a second internal HD for convenience and speed. For extra security every now and then I copy an image to an external HD and to ensure the copy was good, I ran a verify. This worked fine with Acronis but there seems to be a problem doing this with Paragon. If I hadn't paid some attention to what was happening I would have blissfully assumed the desired archive had been verified (as I probably did several times before).
I could just copy the image to a different device with free Teracopy which will run a CRC verify pass after the files are copied.
Thanks for your info, wptski.
After restoring the original drive letters, I changed on the USB drive the filename of the .PBF file (actually 2 of them, 1 for MBR and other for C partition) by adding a character to the numbers prior to the .PBF file extension. It then went to the USB drive for the verify probably because it couldn't see any file with that name on the internal drive. Adding the character doesn't upset the program finding the series of split files .001, .002 ... etc since the name of the next file in the chain is likely embedded in each file when created.
May 23rd, 2012, 02:12 PM
I think copying images is not a good practice. It is better to create another image in the external disk.
May 23rd, 2012, 02:41 PM
I don't see why it shouldn't be just fine given that they are just files albeit rather large ones. However, there is the database issue and personally I detest the database for backups. I'm from the old school and I would just as soon deal at the file level particularly for something that I see as a utility to be used when there is a problem.
Having said that, I agree that the program has been setup and tested from the perspective of creating the archive on the device rather than copying. But if I can specify a location in File View then it should go to that location or say "sorry, can't do that".
vBulletin® Copyright ©2000-2013, Jelsoft Enterprises Ltd.
Copyright ©2002 - 2013, Wilders Security Forums