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)
-   -   Question re Users (https://www.shirt-pocket.com/forums/showthread.php?t=3894)

prouss 03-24-2008 01:24 PM

Question re Users
 
I have different User IDs on my Mac (for wife, kids etc.) SD is scheduled from my account, but seems to be backing up all users - which is fine. But if my kids happen to be logged in when SD is scheduled to run, it doesn't run. Is there a way to get SD to run whichever user is logged in at the scheduled run time? Thanks.

dnanian 03-24-2008 01:35 PM

Only if you schedule under each account.

prouss 03-25-2008 02:21 PM

Will a smart update produce exactly the same backup regardless of which user it's scheduled and run from?

dnanian 03-25-2008 02:47 PM

Yes: assuming no one is using FileVault, of course.

Michael@wengam 06-13-2008 02:20 PM

Keeping multiple copy scripts up to date with multiple user's
 
I have five scheduled copy scripts running on a daily, weekly and monthly basis when I am logged in. I would like to have the same five schedules and same five scripts run whichever user is logged in.

Is there any easier way to do this, and maintain it, than setting up all five syncs from scratch when logged in as each individual user?

For example, are there settings/script files I could copy across? I see that I am the owner of all the scripts and their enclosing folders in my SuperDuper! Application Support folder; everyone else has read-only permission. I presume I would need to change if I wanted to make a copy for another user, no?

dnanian 06-13-2008 03:00 PM

Sorry, no: you'd have to schedule as each user.

Michael@wengam 06-17-2008 04:34 PM

Even copy scripts?
 
OK, I can live with that, but does it even apply to my custom Copy Scripts?

It would be nice just to copy the folder of them over to the other user's Library-->Application Support-->SuperDuper folder.

I don't want to try it in case something goes awry.

dnanian 06-17-2008 05:03 PM

You can copy that folder over, sure.

Michael@wengam 06-18-2008 07:44 AM

And if both users are logged in...
 
So I did that, but forgot to consider what would happen if both users were logged in, which they were: one in foreground, one in background, under fast user switching.

The two identical backup schedules both ran, one in each account. I presume because of this, and one of the processes not being able to access the real backup volume, SD! created a second phantom backup volume on my start up disk in my invisible /Volumes/ folder, eventually filling my start up disk.

The extraneous backup volume was easily deleted by using 'Go to Folder' --> '/Voumes/, and nothing harmed.

Is there a way around this problem, too?

dnanian 06-18-2008 08:34 AM

That's weird: the background user shouldn't have started, because background backups won't run (no screen access). And, the 'real' backup volume is just a disk, so it should have copied to it regardless. Was it ejected or something?

Michael@wengam 06-18-2008 09:03 AM

Ooops, I forgot that the background user schedule should not have run -- that's why I am doing this double schedule setup anyway! So that is weird.

The backup volume is a partition on another SATA drive in the same computer (Mac Pro 2008). It is normally unmounted, and SD! mounts it for the backup.

I will send you the log file for the background users' (failed) run from within the application ('Send to Shirt Pocket...')

It was the foreground user's schedule that made the phantom volume/folder, at least I infer that because when I stopped it (because the disk was getting full), it had copied a huge amount of data (35GB) compared to a normal Smart Backup.

Of course both schedules were set to start at the same time (5:30 AM).

dnanian 06-18-2008 09:06 AM

I think what must have happened was that one of the backups unmounted the drive on the other one...


All times are GMT -4. The time now is 08:43 PM.

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