Backing old data over new data is an old headache. Back in the bad old days when I was using a pc with Windows 3.1 and backing things onto floppies, I did this several times. Made me want to toss the computer out the door and into the yard.
I’ve been careful to just open up my laptop and let it “talk” to my iMac for awhile whenever I get home from working where there isn’t an internet. I think I’m blessed that I only have two computers. More than that is too much for my delicate organizational skills. I’m getting ready to start my busy time on my job. That means long hours and lots of stress; the sort of situation that manufactures dumb mistakes. My solution last year was to turn off the iMac on days when I was working such long hours and just use the laptop. Then, on my day off, I shut down the laptop and went to the iMac. I always used Chronosync to get them right with each other when I made the change-over. It worked without a single glitch.
I have an internet at work. So the two computers should sync with Dropbox. I think I’ll still set the iMac to shut itself down on long days and then leave them for a while to work it out between them when I really get home (as opposed to just showing up to shower and sleep) for a day off. It’s best if I do what I can to defend myself against myself when I’m distracted and tired.
Oh me. The tangled webs we weave when we try to simplify.
For the last few days I’ve been trying MobileMe, using the iDisk sync as a way of keeping my two laptops in sync. Found that it’s even more dangerous than Dropbox. I just can’t get it to upload an updated file on one computer and then download the update onto the other. So I’m abandoning it. I’m shutting down iDisk sync and will only use my iDisk as an archiving system, logging into it manually and uploading stuff manually when I need.
I’ll go back to using Dropbox for the synchronising job, but will take care to only put a back up of the Scriv file on Dropbox and will keep another back-up on a portable external. It’s as near as I am going to get to Jaysen level belt-and-braces … scriv file on MBP and MBA hard disks, synchronised through back-ups on Dropbox, with a back-up of the latest version from whichever laptop on the portable and the MBP backed up fully every night to an external FireWire drive. And when I finish with a project, I’ll zip it up and archive it on iDisk.
iDisk is hinky. Period. I put a couple of databases (big databases) on it back when I first switched to macs, and they’ve been there ever since, archiving away. It will sync simple little files, and it does a good job with iCal and Address Book and Mail, which makes it worth the $ for me.
They only way I try to use it with Scrivener is with a zipped file. It burps on anything else. Even then, it takes a long time to back it up. It can be a real pain in that regard. However one time a few months ago, I tripped and fell into search strings hell with my Scrivener file. It was on my laptop, and I hadn’t plugged in my portable drive to let TM work its way. I would have lost quite a bit of work except hinky 'ole iDisk came to the rescue.
For my money, iDisk is mostly unrealized potential. Apple is so good with most of its products. I wonder why they can’t get it right with this one.
Has anyone ever tried using ‘symbolic links’ to sync Scrivener via dropbox? I’ve just discovered this technique for syncing address book, ical, and safari and it seems to work just fine. I’m tempted to give it a try…
Basically, you create a symbolic link (similar to an alias) of your data (eg ~/library/calendars) and put it in your dropbox folder. Then you do the same thing on your second computer (but follow the more detailed instructions on those links). Then somehow / automagically they seem to sync. You can add and delete ical entries on one computer and when you quit ical, they get synced. Then they appear / disappear in the ical app on the other computer. The trick is to be patient and let dropbox do its stuff before trying to open to synced data.
It could work for Scriv as well. I’ll let you know if I have any success. Although the technical amongst you may be able to shed more light on this…
The same sync issues would still apply. All a symlink is, is a pointer to a real location. Just like an alias on the desktop. Basically drop box “follows” symlinks as if they are real files which allows this to work.
I would not recommend this technic for the same reasons that Amber points out in her original post. Basically this changes nothing, it is just a different way to do the same thing.
I’m still worried about what problems, because I’m using dropbox as the main backup for my novel(s) in progress. I’m only using one computer for actual writing - all I have done on other computers, or on the website, is print out files for others to read. And I do save to my hard drive first. Am I going to have problems? Because so far, it’s been seamless, accurate and easy.
SImply use the backup feature (To create a zip) or Zip the file before copying over and no worries. BUT make sure all the files are shut down before zipping or copying (unless you use the backup feature to make a copy and only copy the backup and not the original.
For those of us who work a lot on the road (or work frequently between two different computers), it would be great if perhaps in the 2.0 release the saving structure was modified to work with these services. I’ve corrupted a few files before I found this thread.
Several other well-regarded Mac apps have adapted their structure for such syncing (1Password, etc), and I’d love to see this in place for my favorite writing app as well.
I’d be interested in how this could be achieved. The problem - at least as I understand it - doesn’t really lie with Scrivener so much as with how many of these services work. Scrivener projects are “packages”, and any Cocoa application could recognise them as such - as distinct from a folder - using NSFileManager’s (the Cocoa file manager) -isFilePackageAtPath: method. So in theory, any of these programs could look at a Scrivener file, determine that it is a package, and thus update it in its entirety (except for those services that just provide a box to drop in such as, er, DropBox, of course). I’m not sure why some of the Mac solutions don’t do this, to be honest.
But if these services aren’t offering a solution, how would Scrivener do it? How would the saving structure be modified? Surely the only solution would be for a .scriv project to be a single file (a zip package itself, perhaps). But in that situation, every time you saved, the whole project would have to be saved, not just the current document. For those with large projects with lots of research material in them, this would not be a fun experience, having to save 100MB or so every time. With the current set up, if you import a 100MB movie or sound file, once it’s imported, that file never needs saving again. With a single file, it would have to be rewritten every save. The current format is actually more secure on a local drive than a single file - a single file corrupted would lose everything; on a local drive, if the .scriv binder structure gets corrupted, you still have access to the underlying writing; you can extract it easily enough. It is only in these network and shared drive instances that it becomes less safe. But the price for making it safer is getting rid of the multiple file format and having longer save times, updating every file unnecessarily every time there is a save…
Forgive my ignorance, but can you lock the file from the OS level. I use flock on solaris which can be flagged to prevent even read only access. I this would theoretically prevent any backups until the lock is removed.
On a different front is the idea of leveraging the fs journal. I would expect that to be implemented on the backup software side, but it “could” be done by scriv. In this model you snapshot the package at the fs level and all calling progies see the static snaphost. Scriv makes changes to the real data and when done (or at regular intervals) it releases the new data. We use this method to backup the SAN (24TB).†
All that said, it might be more trouble than it is worth.
†[size=75]Ok to really do this right you would need to use a dmg with the package on it. I think this would require quite a bit of effort. It might be solvable as a service but that would be outside scriv.
This had got to be one of the worst solution I have come up with recently. [/size]
New idea… what about an “auto archive changed files to” preference? Using rsync you could update a copy pretty efficiently. All you would need to do is freeze auto-save for the duration of the sync. The interval could be large, say 30 minutes.
Gah, Well I just found out the hard way that using a MobileMe box as my main box storage for Scrivener files and lost a couple of days worth of work. Nothing major, more annoying. I was thinking about not using MobileMe as my main folder yesterday. I should have gone with the urge.
I think that sync services are going to come on but I don’t that relying on them as the main folder for stuff is a good idea. It might take more seconds to copy over files to the sync folder but at least you know you’ve got a good copy on the machine you’ve last been using.
My files managed to corrupt somehow - probably due to the way they are packaged and not a single file. Not that I’m complaining more explaining.
Scrivener is a great piece of software - it’s user error this time!
How about using BACKUP PROJECT TO function to a directory you want “updated”, then on the other end you can download the most current zip, open it and get to work. Once done BACKUP PROJECT TO a directory that is updated/backed up and repeat the process down stream.
Works like a charm since its a “zipped” file (no corruption) and you are always using the most current file if you always use the zip files as your main files and use the .scr as working files.
After all the only thing this will do is take a little more time depending on file size and you can’t be in two places at once so…
Wock beat me to it but this is how I do it. I have backup to via zip and ::KnockOnWood:: have had zero issues. In fact, I prefer it this way so that I can control the backups. I do not want an auto back up as has been previously suggested.
Actually, I have found that “Backup Project to …” will always revert to the folder that it wrote to the previous time it was used. So, if you keep your active project on your internal hard disk, then do a first backup to a suitable folder on DropBox or MobileMe or whatever — like a “Scrivener” folder for instance — then each time you do a backup it will be put in that folder, and in the case of DropBox will automatically be uploaded and synced to every linked computer.
I am one who has suffered losses — not catastrophic, though — through trying to use DropBox as the location for active Scriv projects, and am resolved on taking that route from now on. Perhaps if there were an overall preference, or maybe a preference that could be set in each project as to where the backups go, that would remove one more issue … Now someone is going to tell me that there already is, over and above the defaulting to the last backup path used!
the other “problem” with backup up to zip is that you need to sync the whole file. This is horribly inefficient. Especially if you have one of those giant projects we hear about.
Maybe KB can be talked into a collaborative project where someone writes the sync and he tells us how he will indicate locked files. Maybe. Or maybe not.
I think I heard Keith mention somewhere at some time (my moonshine addled brain is a tad foggy) that in the next major upgrade (2.0) that he overhauled the preferences and I think he mentioned there was a “backup” preference that you could set the backup directory default and a few other neato things that Keith does.
Don’t quote me on that but I think 2.0 will have some beefed up backup preferences from what I think I thought I heard (or actually read since I heard nothing).
I would really love to work directly off of files saved to my iDisk as I find saving a backup to the idisk and then copying that backup to the local hard drive on the other end and uncompressing can get a bit convoluted. How about using the iWork 2009 trick of saving everything as glorified zip files. Would that work and/or be feasible?
— then each time you do a backup it will be put in that folder, and in the case of DropBox will automatically be uploaded and synced to every linked computer.
— so backup times are not an issue.