Shirt Pocket Discussions

Shirt Pocket Discussions (https://www.shirt-pocket.com/forums/index.php)
-   General (https://www.shirt-pocket.com/forums/forumdisplay.php?f=6)
-   -   Burn to DVD? (https://www.shirt-pocket.com/forums/showthread.php?t=75)

dnanian 06-23-2004 10:54 PM

I'm going to quote less, like not, in this reply. Bear with me.

Copy newer/copy different will only *overwrite* files with those various values. They'll also add "new" files that have no comparable equivalent on the destination. Only files that already exist on the destination can be overwritten, of course: otherwise, they're not there to overwrite! Or, perhaps I Misunderstand.

These options are useful when you're trying to update a backup and retain obsolete files.

I don't know why those files would exist on the backup, but I'll take a look at the script and what we're doing here to see if I can see any reason why they'd be present.

The backup - user files script is just selection. The copy *mode* determines the action taken when the copies occur. So, yes, it would still erase the destination with Erase, then copy -- by definition. It would also remove all other directories with Smart Update.

Regarding another warning, I'm pretty much against a warning that doesn't really say much other than this-might-overflow-maybe. An overwrite warning is one thing -- it's safety more than anything else. A "don't do this if it won't fit" thing is sort of stating the obvious. I figure if we can't really tell you what the deal is, it's not of much use telling you what it isn't!

For the sparseimage, take a look at the FAQs here in the forums... in-place conversion is converting from a sparseimage to a DMG, which SD! does during the imaging process.

Hope that wasn't too confusing without the quoting!

sjk 07-10-2004 06:01 AM

Quick followup on this:
Quote:

Originally Posted by sjk
The main "Backup - all files" script excludes var/db/BootCache.playlist and var/db/volinfo.database, but those files exist on the destination volume. Not sure if the original backup or the SU copied 'em since I only noticed after the latter.

I ran SD with the "Backup - all files" script using the "Erase ..., then copy files from ..." option and confirmed the two files excluded by the script were copied to the destination (and not listed as ignored in the logfile). Files from the Include Directives scripts in the main script weren't copied (and listed as ignored in the logfile).

Also curious why the "Exclude system cache files.dset" script isn't used by the "Backup - all files" script.

dnanian 07-10-2004 08:46 AM

I believe that we didn't exclude cache files from a full backup because they continue to be legitimate after a restore (unlike a safety clone, where you're running from another volume).

sjk 07-10-2004 07:00 PM

Almost sounds like you're implying a backup volume created with the "Backup - all files.dset" script isn't intended to be booted (which I'll eventually want to do when repartitioning the original drive). That doesn't make sense because the volume is blessed after copying. :confused:

Anyhow, the script contains:
Code:

<key>Directives</key>
<array>
        <dict>
                <key>Directive</key>
                <string>exclude</string>
                <key>Item</key>
                <string>var/db/BootCache.playlist</string>
        </dict>
        <dict>
                <key>Directive</key>
                <string>exclude</string>
                <key>Item</key>
                <string>var/db/volinfo.database</string>
        </dict>
</array>

Yet both those db files are copied when the script runs, as I'd originally suspected. They're also in the "Exclude system cache files.dset" script, which is included by the two "Safety clone ..." scripts. Btw, that script also excludes:
Code:

<dict>
        <key>Directive</key>
        <string>exclude</string>
        <key>Item</key>
        <string>Library/Caches/com.apple.LaunchServices.LocalCache.csstore</string>
</dict>

That file doesn't exist on my 10.3.4 systems, but /Library/Caches/com.apple.LaunchServices.6B.csstore does. Any trouble there?

The objective is to have a clean bootable clone volume that's independent of the original volume. For now they'll have different volume names.

Some background...

A couple years ago I had an issue when running from a booted clone that mistakenly referenced the original volume; not sure if the volume names were the same or different. After first noticing it I unmounted the original volume to ensure nothing was being accessed on it, then made changes for the clone-booted volume as necessary. I think iTunes is what originally brought my attention to it. Since then I've been careful when using multiple volumes in ways that might cause that type of conflict.

I'll soon be working with multiple volumes more often in ways (e.g. clone booting) that I'm concerned may introduce the "identity crisis" again. Any recommendations/warnings related to that?

Wrapping this up with a summary of the main point:

The "Backup - all files" script mistakenly copies two excluded /var/db files that are undesirable on potential boot volumes.

Thanks again for the support.

dnanian 07-10-2004 07:14 PM

I'm not sure why that script is copying those files for you. We'll look into it.

Regarding booting and having the files on the original referring to the "wrong ones" -- that's something that can definitely happen when programs save aliases including volume names, and the names aren't the same.

Even if the volume names are the same, if both are present at boot time, you can end up with a weird issue. The alias manager doesn't look at the volume's UUID when it resolves, just the name. So if the names are the same, it basically just resolves to the first one with the right name.

If that's the one you want, great. If not, it doesn't tell you what's happened, and you can be in trouble... best thing to do is to make sure the other (source) volume IS NOT AVAILABLE when you're booting from the clone.

Regarding the cache, we know, and it's already fixed for the next version. It's not a big deal, though -- you'll end up with too many entries. Apple renamed the cache between Jaguar and Panther, and we didn't catch it. You can fix it yourself if you'd like while waiting for the new version -- just add an ignore of Library/Caches/com.apple.LaunchServices.*.csstore to your own script.

Hope that helps, we'll be back with more re: the two files soon. You're sure you didn't boot from that volume?

sjk 07-10-2004 09:11 PM

Yep, that was helpful... and reassuring. :)

I ran the full backup (with erase) specifically to check it the files were copied so I'm 100% certain I didn't reboot the target volume. Last time I booted from the FireWire drive was during last year's Panther testing/cloning.

dnanian 07-10-2004 10:28 PM

We've done some testing here, and we can confirm that these files are copied... don't quite know why yet.

The volinfo.database file is pretty minor: it's just a log of drive UUIDs that have permissions enabled... it'll be legit on the copy. I wouldn't be terribly concerned.

We'll try to figure out why this is wrong; very strange!

sjk 07-10-2004 11:25 PM

Thanks for the confirmation.

About volinfo.database, I read in Rapid Deployment of Mac OS X with Apple Software Restore:

This database keeps track of the volume serial numbers that are considered "native" to the system. A Volume whose serial number is not in this database will be considered "foreign", and ownership values on that volume will be ignored. Obviously that is bad in light of what we are trying to do here.

I couldn't find anything mentioning it served the purpose you described and I'm pretty sure the file existed before journaling was implemented.

dnanian 07-10-2004 11:30 PM

I must be tired. I am tired. Sorry about that. I know exactly what it does, just mistyped, goofed up.

Anyway, the reason it's OK is that since you've dealt with these volumes before, and you intend for them to be permissioned anyway, you'll end up with what you expect on the backup.

That's not meant to excuse the bug, which we'll fix, of course. Just to indicate that it's not a big problem in typical use -- your backups should be fine, because volumes you expect to be permissioned will continue to be that way.

(Journaling. What was I thinking? I shouldn't post answers after going out to dinner, obviously, especially when beer was involved. :))

sjk 07-17-2004 06:13 PM

Quote:

Originally Posted by dnanian
I thought I read somewhere that rsync would also output differential information that you could use.

I finally discovered the --backup-dir option that's useful for rsync incremental backups.

dnanian 07-17-2004 06:17 PM

Ah, that's the option, yes -- stores the files to be backed up in a different directory than they'd be originally...


All times are GMT -4. The time now is 01:05 PM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.