Working off of network drives (MobileMe, thumb drives...)

[AmberV]

I know these questions have been answered in the thread, but because of all the different advice, I am totally lost as to what to do. I am starting the write up of my PhD dissertation and want to work with a system that is the most stable.

Most stable: avoid all of the sync stuff; it's not really designed for working on the same project anyway. It's for people who use mobile simplified programs, so they can do spot edits on the go and have those edits moved back into their project later. If you want to work on multiple computers, just copy the Scrivener project around---same way as you've been doing work on multiple computers since floppy disks. I'd however, recommend using flash thumb drives or something instead of actual floppy disks. You could even use Dropbox to transfer the project file around. Syncing would be unnecessarily overly complicated when you can just drop the project file onto a USB stick and be done with it.

[Darren]

Hello AmberV,

Thanks for clearing things up!

I will follow your advice and use a flash thumb drive for working between my two Macs. I will use DropBox for backups only.

Just one last question, is it best to:

1. Point Scrivener to the .scriv project file on the flash thumb drive so Scrivener would be always writing to the thumb drive in real time ... or
2. Have the .scriv project file on the computer's local HD and when work is done for the day, drag the scriv file to the flash thumb drive and thus be overwriting/replacing the older data on the thumb drive?

Apologies for getting so nit-picky, but I want to make sure I get into a good habit from the start and do not want to lose any value writing I do on my PhD dissertation.

Looking forward to your further guidance ... you angel!

Cheers!

Darren McDonald
Tokyo

[AmberV]

No need to apologise for being nit-picky about safety protocols. I'm notoriously picky. I'll make six copies when two will do.

Therein is your answer: it doesn't really matter a whole lot where you work on the .scriv project; if it is on the flash drive or on the hard drive. There are minor points in favour of the drive-centric use, even if it is less convenient: it will be faster loading; and you'll wear out the Flash drive sooner if you use it to work on. Neither of these are major concerns, though. The important thing is to not limit yourself to one place or another: eggs in one basket problem. If you work off of the flash drive, spool off backups to your local drive (and Dropbox definitely helps you out there, since it will further copy your backups to the rest of your machines, including their servers). If you work on the machine's hard drive, then make backups to the flash drive (rather than just copying one version at the end of the day over the other version). What I would do there is just let Scrivener's automatic backup handle the Dropbox uploading and then use `File/Back Up/Back Up To...` command to create a date-stamped sequence of .scriv.zip files on your Flash drive. This way it is always clear which is the latest, and you aren't writing over the same copy every time you back up.

It's a whole lot of duplication, but for surprisingly little work. Scrivener handles all of the automatic sequenced backing up for you, and if you point it at a Dropbox folder, it even uploads those and propagates them to all of your machines. That just leaves you to run the end-of-day transfer which can be done with a single menu click---arguably no more difficult than dragging it from Disk A to Disk B in the Finder. The work-on-Flash method is even simpler, at the slight cost of speed and longevity of the device.

[Darren]

Hello AmberV

Thanks for spending the time to give me such a complete and thoughtful explanation.

Thanks to your help, I finally clued on to the safest and easiest way to go about working on the same project between two (or more) Macs.

I will work mainly with the local drive. (I recently got a new MacBook Air with the SSD which is screaming fast specifically as my main PhD dissertation write-up computer). Once I have completed the work for the day, I will then transfer the scriv file to the thumb flash drive and do a back up to DropBox.

Since I am in the Hi-tech heaven that is Japan, I am going to look into finding a large and the fastest read/write thumb flash drive.

Thanks again for all your help. Apologies to have taken you away from your own writing for this. I will pay forward your kindness.

Cheers!

Darren McDonald
Tokyo

[AmberV]

That sounds like a good plan, Darren. I've been using the new MBA for Scrivener for about a week now, and you are absolutely right: it's a screamer, especially for its size. It honestly feels like a desktop does in terms of responsiveness. Since you are on an MBA, I can assume you have a WiFi connexion in your home? You might just consider that as your transfer protocol. This is what I've been doing at the end of the day out with the MBA, I just connect to my main computer via file sharing, and copy all of my Scrivener projects directly onto the machine.

[malter]

Did you know that Automator is helping you managing all the backup stuff ?

I was thinking about using Dropbox to sync my MBA and my old MBP and to work live inside Dropbox. Now I have discovered this topic yesterday and was since then trying to mess up a demo project. I succeeded quite easily by just closing the lid of the MBA while syncing to Dropbox. Since this is way to risky in my opinion I've though about alternate methods of syncing between my Macs.

Now this is where Automator saves you a lot of trouble. What I did is configuring one folder action and one service. From now on every time a backup is saved into my backup folder it will be automatically copied into a Dropbox folder. And every time I want to switch from my MBP to the MBA I just have to start the service. It will sync my project files between the two Macs via WiFi (or vice versa).

Cheers!
Sebastian

[AmberV]

Sebastion, I do something quite similar, except a bit more geeky. Rather than use scripts to copy files around, I just created a symbolic link between my Scrivener backups folder and my general backup archive in Dropbox. The way to do this, paste the following into Terminal.app, assuming all programs are using default settings:

Code: Select all

ln -s ~/Library/Application\ Support/Scrivener/Backups/ ~/Dropbox/ScrivenerBackups

This will create what looks like an alias, called "ScrivenerBackups" in your Dropbox folder. You should immediately see Dropbox status indicate upload activity.

Alternatively, you can point Scrivener's backup repository to Dropbox itself in the backup preferences pane, but if you do that you'll want to remember that your backup files are physically stored in Dropbox, rather than in your general Scrivener application support folder (in case you back that up separately for safe keeping, periodically).

[malter]

Symbolic links are quite useful, thank you for the hint. But I will stick to Automator since I want to rename the backups like this: 18112010-002848-*projectname*.bak0.

However you seem to have some geeky experience regarding the Terminal.app … I've noticed that the script I use for sync seems to have a problem with .scriv files. The command I use is:

Code: Select all

rsync -va --delete "source" "target"

It seems that the .scriv file is synced correctly but still I receive an error message ?

Cheers !
Sebastian

[Jaysen]

what error are you getting?

[malter]

Here is what is causing the trouble:

Code: Select all

rsync: chgrp "/Volumes/Projects/SCRV/DPSK/DPSK.scriv/QuickLook/.qlbg.jpg.2TX3Lp" failed: Operation not permitted (1)

sent 1231510 bytes  received 1124 bytes  352181.14 bytes/sec
total size is 1227872  speedup is 1.00
rsync error: some files could not be transferred (code 23) at /SourceCache/rsync/rsync-40/rsync/main.c(992) [sender=2.6.9]


It only happens, when I rsync via network. Local everything is just fine.

[Jaysen]

my battery is dying so this will need to be quick.

rsync can not change the ownership of a file. This is typically due to mismatched UID/GID between the source and destination, or lack of full permissions on the remote file system.

I'll pst more once I have power.

[Jaysen]

Since you are using rsync I assume that you understand some of the internal workings of OSX/BSD/*nix as related to user info and file access permissions.

Since rsync operates directly in the unix layer of OSX you have to ensure that the command line knows about the UID/GID tables on both ends of the connection. The info does not need to match exactly, but at a minimum the UID and GID must exist, have the same relationship (UID a member of GID), and the UID must be able to perform all actions needed to ensure UID/GID/perms are properly replicated. You can reduce some of this by losing the -a and specifying only the needed options (the one that is killing you is the preserve gid).

A different approach would be to ensure that you are using transfer method that happens outside of a "mounted" share. I assume that you have mounted the shared disk in /Volumes (it shows up in the finder). If you use ssh as an underlying transfer mechanism (instead of the OS mount) then ssh will manage the UID/GID for you if you allow it (lose -a again).

So reconsider the -a option. Consider -rlpt

[malter]

Hi Jaysen thank you very much!
-rlpt just works fine!

Cheers!
Sebastian

[Jaysen]

Glad to hear it.

[21firewire]

Re Dropbox:
Metadata, such as resource forks, are invisible files that contain data essential to the visible file. Dropbox ignores resource forks when syncing the file. The file on the original computer remains untouched, but the synced copies won't open on other Dropbox-linked computers without the necessary resource forks.
A list of files known to use metadata includes Scrivener files (.scriv)

If you use multiple computers, it is possible that putting these types of files in your Dropbox and renaming or editing them could cause them to break when accessed from other Dropbox-linked computers. The Dropbox engineering team is working on backwards-compatibility for files with metadata. In the meantime, you should avoid storing these file types on Dropbox until the problem is addressed.

https://www.dropbox.com/help/6