An open community 
of Macintosh users,
for Macintosh users.

FineTunedMac Dashboard widget now available! Download Here

Previous Thread
Next Thread
Print Thread
Page 3 of 3 1 2 3
Re: Using DU to Clone Lion to a APM firewire drive
macnerd10 #18840 10/31/11 11:44 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
This is what the creator of SuperDuper replied about cloning:

It's always "most reliable" to copy a totally inactive system from a 3rd drive. But it's sufficient, in most cases, to run from the drive you're copying from.
__________________
--Dave Nanian


Alex
3.1 GHz 13" MacBook Pro 2015, 8 GB RAM, OS 10.11.2, Office 2011, TimeWarner Cable
2.8 GHz Xeon Mac Pro 2010, 16 GB RAM, OS 10.11.2, Office 2011, LAN
Re: Using DU to Clone Lion to a APM firewire drive
macnerd10 #18847 11/01/11 05:38 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Originally Posted By: macnerd10
I think it happens because it must be the only copy the updater can find. Again, does not seem to be a mistake. grin

Well if you're gonna be that way about it (grin), ganbustein said "The external backup drive is unmounted and turned off during all software updates, to guard against updaters grabbing the wrong disk," which is precisely what the App Store did to him.

Last edited by artie505; 11/01/11 05:43 AM. Reason: Remove extraneousity

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Using DU to Clone Lion to a APM firewire drive
artie505 #18848 11/01/11 05:54 AM
Joined: Aug 2009
Offline

Joined: Aug 2009
Why did the App store grab the wrong disk? Was the updater also on the main disk? If not, seems like it did it right. Anyway, the update process is not always fully automatic; the disk for an update is usually chosen manually, unless it is a direct download from software update (and maybe from the App store).

Last edited by macnerd10; 11/01/11 05:59 AM.

Alex
3.1 GHz 13" MacBook Pro 2015, 8 GB RAM, OS 10.11.2, Office 2011, TimeWarner Cable
2.8 GHz Xeon Mac Pro 2010, 16 GB RAM, OS 10.11.2, Office 2011, LAN
Re: Using DU to Clone Lion to a APM firewire drive
macnerd10 #18849 11/01/11 06:15 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Originally Posted By: macnerd10
Why did the App store grab the wrong disk? Was the updater also on the main disk? If not, seems like it did it right. Anyway, the update process is not always fully automatic; the disk for an update is usually chosen manually, unless it is a direct download from software update (and maybe from the App store).

I've shunned the App Store so far, but my understanding is that it doesn't allow you to maintain an archive; it searches every volume it can find and updates anything it finds that is subject to an update.

Remember, ganbustein said "It did update the copy of "Install Mac OS X Lion.app" that I had squirreled away on a different volume where I thought it would be safe."

Edit: The App Store performed as directed, if not necessarily expected; it "grabbed the wrong disk" only in the sense that it affected a disk that ganbustein did not want touched.

Last edited by artie505; 11/01/11 06:18 AM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Using DU to Clone Lion to a APM firewire drive
artie505 #18850 11/01/11 12:10 PM
Joined: Aug 2009
Likes: 16
Moderator
Online
Moderator

Joined: Aug 2009
Likes: 16
Originally Posted By: artie505
I've shunned the App Store so far, but my understanding is that it doesn't allow you to maintain an archive; it searches every volume it can find and updates anything it finds that is subject to an update.

I use the App Store extensively and your understanding has little or no basis in facts.
  • It only installs apps into the application folder of the boot drive and these are essentially drag and drop installs.
  • It only updates apps in the /Applications folder of the boot drive. Here again the update is t all intents and purposes a drag and drop install that overwrites the previous version, unless the previous version has been moved to a different location.
  • There is no automatic update per. se., the user has to open the App Store application, click on updates, if there are updates either select All or the specific app(s) to be updated, and enter the Apple account password. From that point on the update is automatic.
When you say it does not allow you to maintain an archive it does not do so automatically, rather it requires some responsibility on the part of the user. There are "archives" of previous versions in the Time Machine backup and there is nothing to prevent the user from "archiving" a copy of the app before installing an update.


If we knew what it was we were doing, it wouldn't be called research, would it?

— Albert Einstein
Re: Using DU to Clone Lion to a APM firewire drive
macnerd10 #18852 11/01/11 04:07 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
Originally Posted By: macnerd10
You are right. However, the installer offers to first update the booted disk (green arrow) by default. One can only manually choose the other disk(s). Just updated Microsoft autoupdate and it did not even ask me where to go: updated the booted disk as well. Therefore, my impression that the installers do not install something "by mistake" and try the booted disk first still stands.

I'm saying: Some installers sometimes do the wrong thing.
You're saying: No, no. Sometimes the installer does the right thing.

I can't know, until I run one, what any particular installer is going to do. The safe course of action is to assume the worst, and take defensive measures.

Which, come to think about it, is what this thread is about. Sometimes, backing up a running system works. Sometimes it doesn't. I don't want my backups to work only sometimes.

Re: Using DU to Clone Lion to a APM firewire drive
ganbustein #18853 11/01/11 04:24 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
I guess the first part of your post is about one thing, the second one is about the other. I tried to be conservative but since you seem to misunderstand my position, I will make it more strict. I don't know of any instances when the installer did the wrong thing. If you do, please tell us so that we would be more cautious in dealing with updates.


Alex
3.1 GHz 13" MacBook Pro 2015, 8 GB RAM, OS 10.11.2, Office 2011, TimeWarner Cable
2.8 GHz Xeon Mac Pro 2010, 16 GB RAM, OS 10.11.2, Office 2011, LAN
Re: Using DU to Clone Lion to a APM firewire drive
macnerd10 #18877 11/03/11 12:08 AM
Joined: Aug 2009
Offline

Joined: Aug 2009
I've given examples where installers do the wrong thing.

I think the heart of your problem is revealed when you refer to "the installer". There are many installers, for many products, from many vendors. Some vendors are more conscientious than others, some are less so.

Apple is among the more conscientious vendors, but as I've pointed out even the App Store will sometimes be overly aggressive about trying to update files that are not on the boot volume. Since I want my backup volume to reflect what was on disk before the update, that's unsatisfactory. Never mind why it sometimes does that; the point is, it sometimes does do that.

Even if you focus on just Apple's Installer.app, you have to keep in mind that even that app doesn't always behave the same. Any vendor can use the PackageMaker.app (typically installed as part of Xcode, in <xcode_directory>/Applications/Utilities) to create an installer package. An installer package can be thought of as a "document" for Installer.app. During its creation, the vendor can customize the installation process in many ways. (Examples: there are checkboxes for whether the payload can be installed on only the boot volume, whether the user has to agree to a EULA before installation, whether an admin password is required, whether a prior version has to be present, etc., and options for minimimum OS, hardware requirements, which components to install by default, where they are installed by default and whether the user can customize the installation location, and many others.)

In case the pre-defined options are insufficient, the package can also include scripts to be run pre-flight, pre-install, and post-install. The most common use for install scripts is to do things that cannot be described as "install these files/folders", but in fact those scripts can do pretty much anything. For example, they can change permissions on existing items (Remember when all of a sudden "group:everyone deny delete" ACLs suddenly appeared on major folders?), they can change visibility (Like, making /Users/*/Library invisible.), they can add users and groups (the Xcode installer creates the _developer group), edit package receipts in an attempt to make Repair Permissions spout fewer spurious messages (I sure wish they'd eventually get that right), verify package signatures, delete incompatible software, edit your shell startup scripts, and on and on.

The sheer flexibility built into PackageMaker.app means that, even for packages installed by Installer.app, there is no single behavior that describes what "the installer" must always do. It does whatever that particular package tells it to do.

And Installer.app is far from the only installer out there. The VISE installer is rarer than it used to be, but still crops up from time to time, and vendors are free to use others or roll their own. As I recall, many of the "software bundles" use their own installer. Adobe Flash Player uses its own custom installer. (Other Adobe products may, too, but that's the only one I have installed.)


You want me to "tell [us] so that we would be more cautious in dealing with updates", but I've already given you something very simple that is completely safe for updates and installs: just unmount your backup volume after you finish backing up to it.

You should be doing that anyway. Your backup volume only needs to be mounted while you're backing up to it or restoring from it. At all other times, prudence dictates that it should be unmounted, for its own protection. It's not just installers and updaters that may grab it at inappropriate times: "open with..." will suggest applications on the backup, and some applications try to update files on their volume. Once you run an application from the backup volume, LaunchServices thinks that's the preferred copy. Spotlight will find items on all mounted volumes, so documents you find via Spotlight may save changes in a place where they'll be lost the next time you back up. Merely touching an alias on the backup may cause the alias to auto-update.

In short, you don't want to leave your backup mounted anyway. Why postpone the unmount? (I also turn it off, so it won't remount automatically on the next restart.)


Re: Using DU to Clone Lion to a APM firewire drive
ganbustein #18881 11/03/11 12:38 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Thanks...much appreciated! smile


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Using DU to Clone Lion to a APM firewire drive
ganbustein #18882 11/03/11 01:37 AM
Joined: Aug 2009
Offline

Joined: Aug 2009
Thanks! A good advice. Will follow immediately.


Alex
3.1 GHz 13" MacBook Pro 2015, 8 GB RAM, OS 10.11.2, Office 2011, TimeWarner Cable
2.8 GHz Xeon Mac Pro 2010, 16 GB RAM, OS 10.11.2, Office 2011, LAN
Re: Using DU to Clone Lion to a APM firewire drive
macnerd10 #19089 11/11/11 09:16 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
I use ditto to clone boot media to other drives. you can also just install to something it's "happy" with, and then ccc it over to say, APS.

I have tried to dig into the installer and find and override the stupid architecture and partition table types, without success.


I work for the Department of Redundancy Department
Page 3 of 3 1 2 3

Moderated by  alternaut, dkmarsh, joemikeb 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 7.4.33 Page Time: 0.498s Queries: 37 (0.018s) Memory: 0.6396 MB (Peak: 0.7554 MB) Data Comp: Zlib Server Time: 2024-03-28 14:58:15 UTC
Valid HTML 5 and Valid CSS