#16
|
||||
|
||||
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!
__________________
--Dave Nanian |
#17
|
||||
|
||||
Quick followup on this:
Quote:
Also curious why the "Exclude system cache files.dset" script isn't used by the "Backup - all files" script. |
#18
|
||||
|
||||
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).
__________________
--Dave Nanian |
#19
|
||||
|
||||
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.
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> Code:
<dict> <key>Directive</key> <string>exclude</string> <key>Item</key> <string>Library/Caches/com.apple.LaunchServices.LocalCache.csstore</string> </dict> 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. |
#20
|
||||
|
||||
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?
__________________
--Dave Nanian |
#21
|
||||
|
||||
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. |
#22
|
||||
|
||||
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!
__________________
--Dave Nanian Last edited by dnanian; 07-10-2004 at 11:31 PM. Reason: Fixed journaling/permissions confusion |
#23
|
||||
|
||||
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. |
#24
|
||||
|
||||
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. )
__________________
--Dave Nanian |
#25
|
||||
|
||||
Quote:
|
#26
|
||||
|
||||
Ah, that's the option, yes -- stores the files to be backed up in a different directory than they'd be originally...
__________________
--Dave Nanian |
Currently Active Users Viewing This Thread: 4 (0 members and 4 guests) | |
|
|