Gah! I just came online to post a question and came across this file.
Iâve just discovered Dropbox, and was treating it as the best thing since sliced bread; time to think again, apparentlyâŠ
I think Iâm safe so far, though - Iâve been keeping the file in my Dropbox on my Macbook, and letting it backup to the cloud. Iâve not needed to call on the backup yet.
Dropbox is great, though it can cause problems with file packages. Keeping your .scriv project in the Dropbox folder on your Mac does not ensure safety. The trouble is, that if for any reason while it is uploading there is a glitch or the process is interrupted, the uploaded version will be corrupted but will have a later creation date than the good one in the Dropbox folder on your Mac. Dropbox will synchronise the two as soon as you next go online using the one on the server as it was the most recent. Potential disaster in the making.
Do heed what has been said on this thread. There are only a few of us out of the many who use Scrivener who have suffered in some way â only minor loss of data in my case, thank heavens â but just ask yourself if itâs worth the risk. Keep your project in another folder on your Mac, and do a regular zipped-up âSave As âŠâ to the Dropbox folder. Zipped files are less problematic than .scriv projects, as theyâre single flat files, not bundles of hundreds of small files in a package.
Iâve noticed that folks are using Drop Box for local file transfers (ie laptop to desktop etc).
Drop Copy is an app well worth exploring. You drop the file you want to transfer to a Drop Copy image on your desktop and it appears instantly on the receiving computer or computers if there are more than one. I repeat - instantly.
Also works great with DropCopy Mobile to transfer files to and from your iPhone or iPod Touch to another iPhone or iPod without a computer being involved â the devices simply âsee each otherâ when they are both on the same wifi network.
Just another solution to the back up story - I use this Drop Copy process personally for local file transfers from my desktop to my laptop and vv, and have no hesitation recommending it. It is FREE! It will transfer any kind of file, folder or application from one computer to another on a local WiFi or ethernet or USB network.- I use a WiFi network (that is what I use my TimeCapsule for - its wifi transmitter). So I guess finally the best advice is - already clearly spelled out by Amber - set your Backup preferences to save the backups as .zip files to keep everything together that should be together. Yes, Drop Box is probably the best solution for âremoteâ file transfers - lots to recommend it. Drop Copy is pretty nifty for âlocalâ file transfers.
Seconded on Drop Copy. Very good little free programme. I havenât tried it on my iPod Touch, but I donât use that for files from my laptops ⊠but between the MBA and the MBP, itâs great.
Would someone mind summarizing for me the current thinking on the safest way to work with Dropbox?
My understanding is that the best thing for me to do would be to work with the Scrivener file on my laptop, and, when Iâve finished it, save it as a zipped back-up. The zipped file could then be safely posted to Dropbox. Then, when Iâm back to working on my desktop, I could open my Dropbox, drag the zipped project file onto my desktop, unzip it, and continue working on the resulting restored Scrivener file.
Is that it?
And would a similar approach to backing up to USB flash drives be advised?
Yes, the original post in this thread is up to date and contains a summary of best practices, which are essentially what you just described.
There are a lot of factors involved in flash drives, way too many to really summarise it into a âdo or do notâ type answer. If I had to produce one though, it would be to feel free to use them as a working device, but as with all things, backup, backup, backup. Donât ever let one spot be the only spot where you stuff is saved. If that one spot is the size of a stick of gum (and thus easy to drop/lose/run through the wash/etc) then you put your work at extra risk.
As with Dropbox, Iâve only ever relied on flash drives for the transfer of information. I would ChronoSync to them on a daily basis, but only to update my other computers so that they remained in parityânever as an external drive that they could all access and use common information from, but never store locally. It just makes no sense to me, if one has extra computers, to not make vital use of that asset as redundant backups. Two identical computers are a great backup all in itself.
I want you to know that I did read your original post, but suspected that over the years some things might have changed. Iâm probably a little skittish because Iâm still fairly new to Dropbox.
Nope! Thanks for checking, though. Iâve kept that top post up-to-date as new information came to light and so forth, so it remains the de facto advisory. There is unlikely to be any change in this in the near future. Itâs really a problem of competing technologies, and so the only way to find a true resolution that is safe for everyone to use is to change at least one technology. We canât control Dropbox of course, and changing the Scrivener project format is undesirable, difficult, and probably not wise in the grand scheme. There really isnât a good solution on the Dropbox end of things either. The frustrating part about it is that neither system is in itself badâin fact except for in combination, both systems are about as good as you could ask, for what they do. Itâs like ketchup and peanut butter. Two âuse on anythingâ condiments that are pretty bad when used together.
I would echo all the opinions about Scrivener and Dropbox. Use Dropbox only as a repository for zipped backups created by Scrivener.
Iâm too soon old and too late smart, and learned this lesson the hard way. I was able to extrapolate it to other programs that create âprojectsâ, i.e. collections of files in a folder, and am careful to zip everything into a single file when I use those other programs as well (one example is Personal Brain â thebrain.com â Dropboxâs procedures can corrupt âbrainsâ, too).
So zip it, THEN ship it. Version control (looking at and paying attention to date and time stamps) becomes more critical using Scrivener on different machines â but itâs better than having lost hours of work to corruption by not archiving properly.
Yup, this advice extends to all formats that use âcohesive bundles of filesâ for their data storage. DEVONthink and VoodooPad are two others that have known issues with the technology, not to mention Ulysses, which has a similar mechanism internally as Scrivener.
The best thing to do is check your file formats. Right-click on those saved files and if they say âShow package contentsâ, chances are you shouldnât be storing it as a live file on Dropbox. There are certainly exceptions (applications being the main one), but to err on the side of caution, thatâs a good place to start.
How about storing the .scriv package inside a disk image (sparse or regular) in the dropbox folder? If you happen to open the same image on 2 computers, or forget to eject the before leaving the computer, it simply creates a copy of the image (with a new name), so you have a record and can resolve the conflicts manually. It seems that the image file is not updated until the disk is unmounted, so you wouldnât want to work off an image all day without unmounting it periodically so that your edits are saved to disk.
It should work for bigger disk images too, because dropbox only uploads the part of the image that has changed (dropbox.com/help/8), so I assume you wouldnât have to upload the entire image if you make a small change. I wouldnât want to use a sparsebundle, since that appears to be a package. Youâd want to keep the disk image small if Time Machine storage is an issue.
Of course, this will make the files inaccessible to iPad/iPhone, but it should be OK for syncing between multiple macs.
Disk images are pretty stable, though some people worry about image corruption. But the good thing is that youâll KNOW when a disk image is corrupted, because it wonât open. If that happens, you just go back to a previous version. Thatâs better than losing bits here and there without ever noticing, in my opinion.
The question that occurs to me is â why is this better than placing a zipped back-up in Dropbox?
(Apart from anything else, âStore package in disk imageâ doesnât trip off the tongue as easily as jimocarrollâs âZip it â then ship itâ. )
there are a couple of things that make a disk image attractive. I am too lazy to put an exhaustive answer together, but imagine having non-scriv assets all packaged together. Think about a person writing a book about development in cocoa. Source code and executables all on the one disk image with the .scriv.
It is better because there are less steps. I find the zip method to be somewhat tedious, especially if Iâm working in a number of different scrivener files or just want to add a quick note in one of my projects.
Steps for using a zip file:
open dropbox, find most recent zip file
copy zip file to desktop
try to find file amid desktop clutter
double-click on scrivener file to open project in Scrivener
write
make new zip file
copy zip file to dropbox
delete scrivener project file from desktop
Steps for using a disk image:
click alias of scrivener project in dock (alias points to a Scrivener project file inside the disk image); the disk image automatically mounts and your project opens in Scrivener).
write
eject disk image
If you use a dock alias, itâs just one click and youâre writing. Then one click and a keystroke to eject the disk when youâre done. Just one more step than keeping a Scrivener project on your hard drive.
The only thing to watch for: donât want to use bundle images on Dropbox for the same reason you donât want to use Scrivener projects on Dropbox. This format of disk images have an allocated upper size limit, but only use what space they actually require, in storage. So you can have a 5gb sparse disk image, but if it only has 20kb in it, the actual disk size will be closer to the latter. Appleâs format will create new sub-file entries in this bundle as it needs to, and therein lies the problem. Since it is a cohesive bundled format, like a .scriv project, Dropbox will introduce mayhem if its internal parts ever become conflicted.
Using regular disk images (which use all of their allocated space), or sparse images (which do not, but come with an overhead that might make them larger than regular images if they are small), should be safe.
There would definitely be advantages to working this way, as zip files require you to extract a copy of the project, while a disk image would let you work on a single copy. That is also a dis-advantage from a backup standpoint. Transferring via datestamped zip files gives you an implied sequence of backups. Editing a single project in place does not. Pick your poison, but if you choose to edit in place, make sure you keep external backups. In other words, this doesnât really alleviate the workload of creating zipped projects, unless you choose to work without backups and favour convenience over security.
Otherwise, I can think of no reason why this would be risky. All dropbox sees is the string of binary information that the disk image is. As you work in Scrivener, this string of binary code gets modified, and Dropbox alters its image of that file appropriately. It is wholly unaware of what you are doing inside the image, and so will not cause the sort of problems that having a âbareâ .scriv file would.
In short: Good idea! Just make sure you couple it with good backups (as always)
Thanks, Ioa. That sounds great, but are you sure the sparse image is a bundled format? I was under the impression that a .sparse image is one giant file, while the .sparsebundle image is a package.
Either way, I donât need to use a sparse image at the moment â Iâm only using a tiny image and at this scale sparse seems to use more overhead space than a regular image. Thatâs not an issue for DropBox with its binary diff method of syncing, but it might be an issue for Time Machine. BTW, I do use Time Machine (and Crashplan), plus DropBox keeps recent versions up to 30 days, I think. And those are all automated backups, so backing up doesnât impact the workflow at all⊠I love technology.
Yes, sparse bundle is what I was thinking of, I forgot about sparse images being a separate type. Thanks for that, Iâve updated the original post!
P.S. And in 2.0 youâll be able to add Scrivenerâs own automatic backups to your list. By default it stores them in your Application Support folder, but you can point it anywhere. Iâve pointed mine to Dropbox, and turned the zip option on, which means every time I force save or close a project, I get duplicated backups spawned to all of my computers, and their servers, too.
Seriously? In this day and age weâre still having issues with syncing to the cloud?
I was actually thinking about buying this app but if itâs going to be more of a headache working on two machines then I hardly find it worth the time.
When is this going to be fixed? Or is it not going to be fixed?
Seems the Dropbox part could be solved by simply implementing the Dropbox API in the app. Since itâs free it seems like a nobrainer option for those working on multiple machines.
It doesnât quite work like that. This is an issue with any application that saves to folders rather than a single file because of Dropboxâs renaming policy, and the API, which is for interacting with Dropbox accounts for mobile apps, has no bearing on that. So thereâs nothing to be âfixedâ here. For Scrivener to have the features it has - the importing of any research file - it requires a package file format; and Dropbox doesnât work well with package file formats.
This does not mean that you cannot use Scrivener successfully with Dropbox - plenty of users do so, and I keep backups of all my projects on Dropbox so that if I need to I can access them anywhere. It just means that you need to take a little extra care, thatâs all.
I donât think youâd actually like that as much as you think you wouldâeven if it were feasible. The thing that makes Dropbox cool is that it uses your hard disk as a parity cache and backgrounds the network activity. Switching to a network transfer API would introduce all of the reasons why we never really used Internet disks for serious large-scale real-time work in the first place. Would you actually tolerate having to sit there for 15 minutes every time you opened your 100mb PDF reference file, or wait 3 hours for your project to save, or 5 minutes just to load a project while local cache files were compared with network datestamps?