Syncing to more than one external folder on Dropbox

I was wondering if anyone had a solution to this issue? I’d like to be able to sync a single Scrivener project to more than one external folder.

The reason for this is that I use WriteRoom on my iPhone to edit and add to my projects by syncing to the “WriteRoom” folder that the app forces into Dropbox. I now also have an Android tablet and am planning to use Epistle to work on my projects. Unfortuanely, like WriteRoom, Epistle forces its own “Epistle” folder into Dropbox. If either app allowed me to choose/designate which folder it used for Dropbox syncing, I wouldn’t be asking this question. But until one or both of them support that feature (I’ve asked both developers for it), I need another solution so I can work on projects between all three devices. To my mind, the easiest solution would be some way of syncing the Epistle and WriteRoom folders in Dropbox.

Any ideas?

And, yes, to the cheeky among you, I know this would all be obviated by getting an iPad. But for the moment that’s not on the cards.

Thanks in advance for any and all advice on the a short term solution.

Cheers!

This is probably one for Keith or Iowa, but using the Scriv project file, show package contents and drop a symlink to an external folder contained within DropBox into the documents folder therein, would this work?

I know the caveats about using DropBox and, even if the above method did work the risks associated with it might not make it worthwhile, but for anyone prepared to take those risks it could be a temporary way to achieve what the OP requires.

A couple of useful ways of creating Symlinks are:

MacDropAny: dropboxwiki.com/MacDropAny#Download
DropLink: dl.dropbox.com/u/1242195/DropLink/welcome.html

Both are free but donations welcome. Use at your own risk :smiley:

:open_mouth:

I’ve experimented with symbolic links for something like this before, and you’d really have to try with both applications before trusting your system to that. The main problem is that most of the mobile apps I’ve seen read in the file from the sym link, but when it comes time to write the file, it wipes the old one and replaces it with a new .txt file, instead of streaming the updated file data to the file pointer. It’s a technical thing, but what that means in practical usage for you is that the symbolic link is blown away and in its place is a .txt file. So location B becomes forked from location A (where B was pointing to, before), and you have to manually fix everything the next time you get to a computer. I have a strong suspicion this is a result of the Dropbox mobile API, and thus not something that the host application using it can control. After all, if the host application had an intimate enough connection to the Dropbox files that it could control whether it was streaming data to a file pointer instead of rebuilding a file in that position, it wouldn’t need the API!

Do test though, because I haven’t tested this myself in around a year and a half or so and Dropbox might have resolved this bug in that time.

The other solution is to use another sync service for one of them. Use Simplenote on one device and the Dropbox setup on the other. I have used Epistle, and it’s all right but it is nothing special, so if that appeals you might consider Simplenote on the Android and Dropbox w/ WriteRoom on the iOS device.

You think Kevin is the only one who deserves an identity crisis Ioa-iffer?

Have you considered hard links? They are typically nicer for sync services most of which seem to do a

fopen( fh, fname, CREAT); (I don’t remember the exact create static), which effectively asks the OS to create a file OR find index 0 of a real file. I believe this is what is whacking symlinks since there is not index 0 in a symlink at the OS level. Using a hard link should allow things to work properly.

That said, I could test this hypothesis, but then I would have to think. It hurts when I think so testing will have to wait.

:blush: Sorry AmberV (Ioa) (Tacitus hangs head in shame )

From what I’ve heard, Dropbox will destroy (de-sync) any hardlinks. They, like symlinks in the API, end up as two separate files.

Reference with response from DB support.

That would make sense with the index 0 fail, but if the symlink is to the parent folder, might that avert the problem? Well, I’ll have to play with it again. I think my old experiment might have tried symlinking the .txt files themselves rather than the folder, because the program I was trying to get working with Scrivener was iA Writer which was incapable of navigating folders, so I had t spoonfeed it files from the Draft folder.

Interesting. You can also try directory level hard links. The only real advantage to symlinks is the “real fire here” hint you get at a directory listing. The big advantage to hard links is that even if you remove the original file, the hard link is still functional as it is not a pointer to a file table entry, but an actual entry in the file table. Ex: jaysen:~ jaysen$ !ec echo "hello Ioa" >> test.txt jaysen:~ jaysen$ cat test.txt hello Ioa jaysen:~ jaysen$ ln -s test.txt test1.txt jaysen:~ jaysen$ ls -lrt test* -rw-r--r-- 1 jaysen staff 10 Apr 9 13:47 test.txt lrwxr-xr-x 1 jaysen staff 8 Apr 9 13:47 test1.txt -> test.txt jaysen:~ jaysen$ cat test1.txt hello Ioa jaysen:~ jaysen$ rm test.txt jaysen:~ jaysen$ cat test1.txt cat: test1.txt: No such file or directory jaysen:~ jaysen$ rm test1.txt jaysen:~ jaysen$ echo "hello Ioa" >> test.txt jaysen:~ jaysen$ cat test.txt hello Ioa jaysen:~ jaysen$ ln test.txt test1.txt jaysen:~ jaysen$ ls -lrt test* -rw-r--r-- 2 jaysen staff 10 Apr 9 13:48 test1.txt -rw-r--r-- 2 jaysen staff 10 Apr 9 13:48 test.txt jaysen:~ jaysen$ rm test.txt jaysen:~ jaysen$ cat test1.txt hello Ioa jaysen:~ jaysen$ rm test1.txt jaysen:~ jaysen$
I also like the fact that for massively scaled apps, hard links are a bit faster.

Although if you need links on a massively scaled app you are probably using multiple file systems or a really big SAN so the speed is probably less of a concern.

Okay, that test worked. Either DB fixed the API problem, or my old test was invalid to begin with.

You need to symlink the sync folder itself (I’d symlink the master folder, so you get access to both Drafts and Notes) from location A to location B. I created a test sync folder in Dropbox, and then symlinked it inside of my Elements folder. I was then able to edit the files in Elements and get synced updates to Scrivener after doing so.

You’ll still need to test with your target applications. You might find one works better with symlinks than the other, and so that will determine which application should have the original data and which should be linked.