I’m tying to make this workflow work, my tests prove it possible with Simplenote, but I run in to problems with I try doing this with PlainText.
DropboxFile.scriv <-----> External File Sync <----------> iPad Edits on the go
Simplenote syncing makes this work, but when I try PlainText and sync to a DropBox PlainText folder on computer A, computer B is thinking another project has synced to that file and doesn’t wanna sync to it. Is there a workaround for this? If not, I’ll live with the Simplenote option, which still works, but I would prefer PlainText for the interface.
Thanks for all your patience with my questions the past couple of days. Just got the software last week so I’m running a bunch of tests of different options.
The problem here is that your office machine probably has a different user name than your home computer, and so that is throwing off the sync settings, which save the full path. For instance, “/Users/officename/Dropbox/MyNovel” does not equal “/Users/homename/Dropbox/MyNovel”. Only the last parts match. Since the feature is not specifically designed to only work with Dropbox, and is meant to be a general purpose tool that can point anywhere, it wouldn’t be reasonable to lop off the first part and assume “~/Dropbox”. So when you get home, you fire up your project but it’s got your office path, which doesn’t exist on your home computer, so Scrivener shuts off sync and when you try to point it back to the Dropbox folder on your home computer, the safeguard detects an existing sync folder and denies attachment to it. Originally, this was just a caution box with a “Proceed at your own risk” type tone, but it grew problematic with it left on that way as not everyone reads caution boxes and just hits Okay. Some nasty snarls resulted out of that.
There is a way to approach this problem that is slightly (or very, depending on your level of aptitude) technical. What you really need is a way to fool Scrivener into thinking that “/Users/homename/Dropbox/…” is actually “/Users/officename/Dropbox/…”. I should preface this with a “do at your own risk” statement. There are some variables in this list since I don’t know your precise path structure, where you’ll need to interpret and correct the commands. The commands themselves are all benign, with ‘chown’ being the most risky (nothing that can’t be fixed, but it can make a huge mess of things if your fire it off at the wrong target). Just make sure you target the new folder you created a step above. You only need to do this on one computer, and you’ll need admin access, here are the steps:
- Open Terminal.app from the Applications/Utilities folder
- Type in cd /Users and press return
- Your command line session is now in the “Users” folder, directly above your home folder.
- Type in sudo mkdir otherComputer where “otherComputer” is the short name of your user account on the other computer. Note this is case sensitive. We want to make two routes to the same location. This step will require you to key in your administrative password, as the ‘sudo’ command lets you execute things as system root.
- Now sudo chown userName otherComputer Same drill on ‘otherComputer’, and ‘userName’ is your account name on this computer. You are setting the ‘otherComputer’ folder to be owned by you. When you use sudo to make a folder, it is owned by the system root and that would be perfectly useless for what we want to do
- Type in mkdir otherComputer/Dropbox. All right, now you have two static folders in mimicry of your office machine (or home if you are doing this at the office). Now, if your sync folder is buried a few folders down from the main Dropbox folder, you’ll need to reproduce that as well. Here is an example, mkdir -p otherComputer/Dropbox/Writing/Scrivener, where “Scrivener” is the folder that the actual sync folder is in. You don’t want to make the sync folder yet, that’s the next steps. You just want to build a static scaffold up to that point. Note the -p in this command example. That will create an entire sub-folder chain at once as you specify it.
- Type in cd otherComputer/Dropbox and then ln -s ~/Dropbox/SyncFolder . <-- Note the dot at the end, that is a part of the command. SyncFolder here is of course the name of the folder Scrivener is using. Of course, if your sync folder is down a few levels, the first example command assume it’s at the top level. You’ll need to change these commands to use real path.
There might be an easier way of doing this, but this strikes me as the safest way to do it. The only symlink is the one at the very end, everything else is static and has nothing to do with your home folder or top-level Dropbox folder. In theory you might be able to just symlink either of those and get the whole tamale as they say on this continent, but personally I wouldn’t try symlinking either without a little research.
Of course, the easier solution is to only sync from one location. I do understand though, that if you commute or something it would be desirable to keep the iPad up to date for both trips. I do hear you about Simplenote though. It’s easier to set up and use, but I like having the freedom to choose which text editor I use, on the iPad.
AmberV, thanks for the thorough response! You’re right, I do have different usernames on the two machines. Based on what you said, I’ll have to roll with Simplenote for this workflow. I love playing around with different workflows and options but when it comes to command line stuff, that’s usually when I get lost .
But this totally answered my question, and Simplenote does have its advantages. Thanks again!
One thing to mention, which was implicit in Ioa’s reply but not overtly mentioned, is that you need to remember that the project on your office machine and the project on your home machine are different projects. Even though one was copied from the other, the copy is a different file and as soon as you have two separate files it’s not really feasible to sync the same files to both. This is why Scrivener refuses to allow both to sync to the same external folder. If you weren’t careful, you could soon run into problems with corrupted projects if Scrivener allowed this. For instance, say you do some work on your office machine and then sync it all to the external folder. Then you go home and forget to replace the version of your project on your home machine with the version you worked on at work, and go to sync with the external folder - now it will bring in all the work you did on your external folder, but there is no guarantee that the internal IDs of all of those files will match those of the other project (internal IDs must be assigned to files in order for them to be manipulated in Scrivener). Now if you do some more work and sync again, you could easily end up with a situation whereby files in one version of the project have the same IDs as different files in the other project, and so when you sync you will end up overwriting files or getting the wrong text in the wrong place.
As Ioa says, this used to be an “at your own risk” think, with the warning message telling the user that the external folder seems to be in use by another project and only to proceed with the utmost caution. It would only ever work if you were very, very careful always to replace your project with the latest version (that is, if after working on the office version you were careful to copy that and replace the one on your home machine with it before opening it at home, and vice versa). However, it soon transpired that most users don’t realise that a copy of a project is no longer the same project, and so would click “OK” to this - or ignore it entirely - and end up with some very funky projects. Thus it’s now prohibited, because it became a massive support issue.
If you want to access the same project from both machines, the best way is to store the project itself on Dropbox, ensuring that you follow these rules:
All the best,
I am storring the actual Scrivener file on Dropbox and I am following all the practices of proper syncing, and I haven’t had any problems with that so it’s all good. With what you and Amber described, I think I can make a two computer + Simplenote workflow work without any issues. There is also the option creating a separate project to sync with Plaintext and use that to daft on the go, then import those documents into my main project file, so I think I’ll be ok.
Ok, correction. I am running into some some issues with Simplenote with this workflow with file names, etc. So, for now, I’ll play with some workaround solutions for iPad editing.
What is the nature of the difficulties you are running into with Simplenote? Are Binder names reverting to older versions, after sync?
Yes, I’m getting file name warnings, as well as warnings that the project seems to be open on the other computer, though I’m sure I have closed and quit. The two maybe unrelated, but I’m taking those as a sign that I may be pushing it with this workflow. All of this is with a test project so I’m not loosing any actual work and I’m also not having any sync problems with “regular” files and Dropbox sync, so I’ll just work with my workaround for now.
Hmm, okay. These don’t sound like Simplenote problems, so you should be fine on that score. These sound like general Dropbox issues when putting a .scriv file on it and working on it from there. It is possible to avoid problems like this, but it is important to be punctilious with the related guidelines that Keith linked to, and which are also discussed in the “Scrivener Everywhere” portion of the Cloud Integration and Sharing chapter, in the user manual. You might have closed the project fine, but put the computer to sleep/shut down before it could get a chance to fully upload the .scriv folder to the server—leaving the lock file intact, which is what Scrivener uses to check if the project is already open or not. In other words the copy you have now available to you on Dropbox might be in a partially closed state.
You should be all right; a lock file is only there for your protection, and obviously you aren’t using the other computer as well, so it is okay to proceed. If you notice anything else odd, though, you might want to sweep through the .scriv package contents, looking for files marked by Dropbox as “conflicted”.
Same drill as when you get a conflicted .doc file with Dropbox.
Oh, ok. I’ll keep testing it and playing with, maybe I can iron out the kinks in the workflow.