Remote storage of data

I write primarily from two locations, one home, one not home. At those two locations, I use two separate computers.
A feature that would appeal to me is one that would allow me to save and edit files from an FTP server, for instance like BBEdit and Coda do. They offer the option to save files and read them from an FTP server, provided you enter the correct username and password, of course.
That would allow me to save my Scrivener files in one location and edit them from any computer that had Scrivener.

Scrivener is the writing tool I’ve been looking for for years, and that feature would make it absolutely perfect.

This wouldn’t be terribly feasible. The main reason being: a Scrivener project is actually bunches of files, at times thousands of them. If you right-click on a Scrivener project and elect to view the package contents, you’ll see everything that goes into making a project file work. Every little thing has its own file. The index card contents, document notes, the document text itself, snapshots, media files, et cetera. The other issue is Scrivener’s aggressive auto-save. As you worked in Scrivener, you’d likely be firing off dozens of files to the FTP server, there would likely be a constant hail of files being sent out, some right over the last one still in transit. You could reduce this setting, but that still doesn’t get into the issues of how FTP protocol doesn’t really play nice with Mac formats like the package bundle, anyway.

Case in point, there is already a service that lets you keep a folder on your Mac that gets automatically synced to the Internet whenever you make changes in it. All of your computers can be hooked up to this same folder. It is called DropBox. But as I have posted elsewhere, it is not recommended in any way to work off of this folder with a Scrivener project because of all the above. I am not a terribly careful user, in fact I often try to break Scrivener on purpose, and I’ve never seen a corrupted project file except when I was testing out DropBox.

BBEdit, YummyFTP and so forth can get away with remote file editing because they are working off of an entirely different document philosophy. The file is loaded into memory and then nothing happens to the disk until you save it (triggering an upload). Scrivener is completely different. Disk activity is going on whenever you do anything. Select something in the Binder: disk activity. Create a split window: disk activity. All of this helps create a seamless and persistent editing environment, but its not very good for remote delivery where the disk is not physically wired into the computer somehow.

I actually was aware of that issue, and as a Mac programmer, I’m familiar with package files, which is largely what Scrivener’s documents are.
I think a preference to throttle the aggressive autosaves could address the issue, with a caveat to the user that saving will be both slower and less thorough when working from a remote drive.
As a user, I’d be more than willing to make that trade-off to gain the ability to work from a remote drive.
And the aforementioned avalanche of files is exactly why I don’t use a utility like Dropbox, though it had crossed my mind.

I understand if such a feature isn’t atop the priority list for development, but I thought it would be nice to plant a bug in the developer’s ear nonetheless.

You know you can “throttle the aggressive autosaves” under Preferences? Possibly not to the extent you might want, though.

Lots of us save locally and then back-up a zipped file to a remote server (zipping seems to prevent the avalanche). It enables the flexibility you want, preserves a copy of your work even if the back-up fails and doesn’t seem to hamper the writing flow. The key caveat is not to have the same project open simultaneously on two machines.

H

I use a combination of two tools to keep universal backups of my Scrivener projects (and other things as well). The first is an FTP client that is capable of creating droplets, small applications that will upload a file to a server in the background when dropped on it; I use YummyFTP for this. The second application is Hazel, which is a simple folder-based automation preference pane where you can tell it to monitor a particular folder and if files within that folder match a certain criteria, will take various actions on them. One such possibility is to scan for new zip files that have not been seen before by Hazel, and send them to the FTP droplet. This will be made even better in the next version of Scrivener, which will have options for automatically generating zipped backups on a periodic basis, or in response to certain events like opening or closing the project.

I realise that I’ve just given a roughly $60 answer to a problem, but chances are you already have an FTP client laying around, and it might have a “watched folder” feature which could be used to replicate a degree of this. If not, I believe CyberDuck can do much of this for free.

What you get isn’t a project you can “open on an FTP server” but rather a repository of archived versions. When you switch computers you just download, unzip, and start working away. Until 2.0, you’ll have to remember to always use Backup To… before you quit for the day, though.

I think this topic needs to be taken a bit further. FTP is old technology. We need to look at Scrivener as more of a Google Docs level. Allowing us to turn on the program, at work, home, or our notebook, and connect remotely to a cloud and access our latest versions.

Cloud computing space is cheap. L and L can charge people for storage, let’s say $5/month, $50/ year, and all your work is stored remotely and backed up automatically.

This could be an income generator and enhance the usage level of Scrivener.

I personally use it at home, but sometimes get inspiration either on the road (iphone) or at work. I currently end up emailing myself the ideas and then processing them later. I’d prefer to edit the documents and files where ever I am. With new stories, I use Google Docs, because I can edit them and amend the ideas from anywhere. I’m currently sing Google Docs more than Scrivener, but would prefer not to.

Perhaps we can even look forward to a web based application to allow us access to our stories from anywhere.

Just because something is “old” doesn’t mean it’s inferior. In fact the maturity and stability of FTP is one of its merits. A good SFTP connexion to a private or protected server is going to be quite a bit more secure and stable than any kind of Google Apps type interface with nebulous ownership terms-of-usage agreements and security, many of which are locked with exceptionally weak passwords so that people can type them in on their mobile devices without fifteen minutes of data entry. Security is going to have its weakest link at whatever access mechanism is most clunky. “Cloud” stuff, because it connects everywhere (cellular broadcast is not at all secure) and to everything, probably has the weakest chain out of anything.

-1

Development of Scrivener should focus on writing, not file transfer and synchronization for which perfectly good tools already exist outside of Scrivener.

Basically what is being asked for is an integrated network storage client of some kind (ftp or whatever) within a word processing program. This is a model that would lead to a different backup / remote solution for every piece of software, which makes no sense. The original poster doesn’t address the issue of where the ftp server will be but later posts seem to be suggesting Scrivener should also provide cloud server space. That makes even less sense.

Do you really think you will only want cloud access to your Scrivener projects when you write? Do you really never need another file from somewhere else on your computer? Network storage / synchronization is something that’s necessary for lots of programs / file types, and shouldn’t be done on a program-by-program basis, it should be done through separate, generic / system-wide tools. (BBEdit and Coda are exceptions here b/c they are focused in part on maintaining web sites for which server sync. is integral to their functioning).

There are lots of working synchronization solutions that have been discussed on this board (I personally use Chronosync with an external USB drive and three Macs and/or a webdav server depending on the situation) for people who want to have access to their files on many different computers.

Scrivener is a writing/word processing program and I would much rather see development efforts go into developing these core functions rather than reinventing the wheel to address problems for which external solutions already exist.