Discussion in 'backup, imaging & disk mgmt' started by Isso, Jan 18, 2013.
Thanks from me too manolito, very kind of you.
Version 2.439 should be called BETA, NOT Final, NOT even RC1.
The Mount and UnMount feature does NOT work.
There is NO bare metal restore.
This is NOT an imaging program as advertised.
Back to Isso's v1 for me. I was a fool to purchase this before thoroughly testing. Never again.
As it relates to TM, what does Mount mean I see the button, but have no idea.
It means you can load the image file into a virtual drive, and you can view/copy specific files inside of image without the need to restore the whole image.
As oliverjia mentioned you can "mount" the image as a virtual drive but there is very little need to do so since all files in the snap are available via the TM browser. I seem to recall that this was discussed way back when and it was noted at that time that in some circumstances it might be preferable to mount the snap. I cannot recall what those circumstances might be however I do recall thinking at the time that the mount availability would only come in handy very rarely.
It would be real nice if the old versions of AX64 were available from the developers for those who decide to stick with V1. I suppose a license holder could ask support for a copy but download ability without having to ask would be preferable.
Hi AX64 crew,
Just as an internet commerce security notice, I was at the checkout page on the ax64 website with my order and noticed the web address was simply ax64.com/checkout/, with no https
I added the https prefix, and it does reload with the secure protocol.
Shouldn't it automatically switch to https, for secure checkout and transmitting credit card data?
One advantage I do find with mounting a snapshot is that I can view it in my dual pane file manager just like any other drive.
You can accomplish much the same by using "restore down" on both the AX/TM browser and your file manager.
May be, but I much prefer to use a dual pane file browser for my file operations, I find it a lot easier then trying to work in two seperate windows. I use xplorer2 and find it a lot better then windows file manager, there is a free version if any one would like to try it.
An interesting thing I discovered while re-playing around with v18.104.22.168 (last BETA). If I was off playing "externally" with the protected volume... not really changing anything but clearly causing what v1 calls an "external" modification, as expected, when I returned to the LIVE system and ran a snapshot... AXTM v1 told me of the "external system modification" and started the snapshot with a FULL scan of the protected volume rather than it's normal quick look snap.
BUT... if I canceled that snapshot early in the process (right after it starts), then restart it, AXTM doesn't detect an "external modification" and does the normal quick snap operation, now trusting its TRACKING FILE.
I know not what this means and will not hazard a guess as to what is happening if there really was an EXTERNAL MODIFICATION to the protected volume that wasn't recorded in the TRACKING FILE... I would have to test to know what's really going on. I also don't know if the same thing would happen under v2 (will also require a test).
I guess what I'm saying is be very careful under these conditions until we know more about the situation. I will do additional testing when I get some more time. I would hate to think that a real external modification would make it through to the system without being detected, akin to the BOOT time defrag of Perfect Disk.
I use XYplorer and find that if i want to copy a file from the AX browser I cannot paste it into XY, I have to open Win Explorer and do it there. Do you have the same problem with x2?
That is a bit disturbing to say the least. I look forward to the results of your further testing.
Good catch Froggy..frogs catch flies. Staying tuned.
No, I have just copied a file from AX browser window to a drive opened in xplorer2 window with no problems.
if that is what it is OHH BOY... meanwhile i back using reflect... i CANT put my system endanger testing and playing with TM/AX64 .
I think I may have noticed that happen in the past but did not take much notice of it, might explain why some snapshots fail to restore?
This has been CONFIRMED in v22.214.171.124 (most likely in all v1 versions) using the following very basic test...
BOOT into an Active@BootDisc WinPE (or any other WinPE for that matter).
Copy a folder of music (400+mB) from an unprotected HDD to the protected SSD.
ReBOOT into LIVE Windows and check if music is on protected volume... it is, as expected.
Start AXTM v126.96.36.199 and execute snapshot. As expected, discovers "External volume modification" and starts slow re-scan of the volume.
CANCEL the above snapshot at appx. 2.4%.
Restart the snapshot. This time no detection of "External volume modification... snapshot flies through process, takes about 30-sec.
Using ATXM Browser, look through above snapshot and discover NO COPIED MUSIC.
At this point, the system Tracking File and the actual system are not in sync and AXTM will not know that until the next time it's forced to re-scan the protected volume due to the above anomaly. At that time, it should get back in sync following the re-scan and the next snapshot will include all that's been missing since the test above. The problem with this... all the snaps from the test to the re-scan will be in error and not contain the necessary files for restoration.
I'll check v2 soon...
Could explain why my mate had so many problems with v1, when ever the message "External volume modification" came up he would cancel the snapshot and then restart the snapshot, he said it was quicker that way.
Now THAT'S funny ... not really.
If whatever caused the "external modification" (almost any external non-Windows LIVE process that even looks at that volume) did not actually change anything on the protected volume, all should be fine... but that's NOT how snapshotting should occur.
Shortly I'll be testing v2... and to be honest, I think I'll probably find the same anomaly. We'll chat later...
I noticed this with Ver1 if I boot to my secondary HD. Not being a tech person I never thought about what it might mean. Just figured that TM got confused. Haven't booted to the 2nd HD with ver2 yet.
This has been CONFIRMED in v188.8.131.529 in an even stranger way then v1...
I ran the same test as above with the following unusual observations...
On the snapshot following the cancelled snapshot, it raced through the snap like in v1. The snap itself was small as in v1, only 35mB, BUT... when I browsed the snap, the copied files were listed in the snapshot, that was not the case in v1. This really suprised me as the snap should have been much bigger (copied data was 400+mB). In the Browser window, I looked at the newly copied folder's PROPERTIES... it said it contained only 25mB of data... this clearly is wrong. Any other time I've looked at newly copied data, the sizes of the new snap data were as expected.
At this point I have no idea what happened with v2, but I'm sure the snap is in error since the newly copied data was over 400mB (unCompressible) and the snap itself was only 35mB.
I would caution everyone at the moment about using that CANCEL feature (v1 or v2) following an external modification. At least v1 tells you that it has detected that mod, v2 doesn't do that anymore.
Suggestion for the Devs:
This is definitely a problem with file structure synchronization... assumptions are being made that shouldn't be. You need to implement a DIRTY BIT of some sort that's set immediately upon detecting that external modification, and that bit should not be cleared until you've definitely re-scanned that file structure SUCCESSFULLY to completion. Otherwise these snapshots after that condition just may be a crapshoot at best.
Dagrev, while booting to the 2nd HDD, if the OS there even looks at the protected HDD, TM should be able to detect that and do its re-scan to re-synchronize its TRACKING FILE. Trouble begins if that re-synchronization is cancelled in any way. That's what the CANCEL function seems to do... but it shouldn't. The CANCEL should be valid for any snapshot, especially if you don't wanna wait the time for it to occur... but the next snapshot should re-perform the cancelled function, the re-synchronization if it was necessary to begin with.
Turns out that the 35mB in that questionable snap was only part of the files that were added outside of the protected Windows, the others never showed up. Compared to the v1 test, this was very inconsistent.
For sure the snapshot following the CANCEL does NOT HAVE all the files added during the test. Beware...
Have you notified the devs of this?
Separate names with a comma.