Generally speaking, I’m a bonehead, and I know this has probably been explained already. Will Scrivener save and read from iCloud - not necessarily “sync” - so that I can just work from the iCloud file and have it back up on my Mac? I run into the iCloud vs Dropbox stuff when I try to search, or syncing, per se, but not just saving and working from iCloud. I’m bought into iCloud, so it would just be easier in my chaotic world.
Never open any Scrivener project from a cloud service.
The project must be stored and opened/saved on your local drive. It can be synced to cloud, so make sure files are stored in the local drive folder for the cloud service and selected as available offline.
Just a caution, syncing is not backing up. If an error occurs in the file, that error is likely to be synced so both the original and the sync will have the error.
The most basic backup (essential!!!) is to use the Scrivener backup feature (select 25 IMHO), and backup to a location completely separate from any project files, be it another cloud service, network drive, USB drive etc. Whatever you do, do not neglect this - recipe for disaster if anything goes wrong.
3 Likes
This bears repeating. Scrivener is not a web application. It runs on the local machine, and expects your data to be available on the local machine as well.
2 Likes
It’s interesting you said this, but I have an app called Diarium (Journaling app) that runs on my local machine, not a web application, but it saves to a database stored in iCloud. It basically reaches out, verifies it has the latest database, and if it doesn’t it downloads it, then it operates solely on the machine and updates the database later. Because an app runs on the local machine, does not mean it cannot store it’s primary dataset in the cloud.
1 Like
The way I understand it is that this is a problem is the way iCloud works. You need to think of your scrivener project as a folder full of many files, rather than actually a single file. It only looks like a single file (with a bit of macOS smoke and mirrors). iCloud does some weird stuff with offloading and syning distinct parts of these packages, rather than the whole thing, which is where the issues occur. I suspect a database as you describe is just a single file rather than a package, so wouldn’t suffer the same constraints.
Sure, my only point was that Diarium is not a web application, runs on the local machine, and yet works from data in the cloud.
1 Like
D
is obviously not Scrivener. No point really in comparing. Take advice from @RuffPub and @kewms above as required.
So, the way you stated this sounds like it means that I should also NOT store a file on a local network share. If this is accurate, why are things set up this way? I mean, network shares are something that have been around for over 20 years.
SDLeary
1 Like
The fundamental issue is speed of access. If the file on the network share is guaranteed to be available when Scrivener goes looking for it, then you’re fine.
2 Likes
I’ve experimented with Scrivener projects on my NAS. They appear (APPEAR) to work just fine, but it was only an experiment, I don’t do it with active projects.
Just to clarify further. This applies to ALL cloud services, not just iCloud.
The project must be stored locally.
@kewms is a long-standing member of the Scrivener team, so obviously knows what they are talking about.
3 Likes
This is all somewhat aside from the original topic. To answer that very concisely: no, we have not programmed a direct interface to any server system into Scrivener. It is just a normal document editor like tens of thousands of others. We did support Simplenote back in the day, but that’s about it.
I don’t know what your purpose is, why you would want that, but if it’s simply to have another copy somewhere, then point your automatic backup folder to a Backblaze account or something along those lines, and keep the zip option enabled to reduce restoration confusion. You’ll be fine with that and it doesn’t need to be any more complicated.
Now as to networked file sharing, yes this is old tech (even way older than 20 years!) and it is very robust. Most businesses that have any emphasis on data, like a photography studio, would collapse without this technology being reliable.
I’ve done more than experiment. I heavily use networking on a daily basis as I often have to test projects on Mac, Windows and Linux. So I’ve got Windows using networked drives mapped to the Linux host, which is how all actual work is interfaced with since I don’t save anything on Windows other than settings. Yes, they are sharing the same SSD, so there is no noticeable speed drop, but technically it is through the same networking technology one would use if the physical drive was in another room.
Meanwhile the Linux machine has the Mac system mounted to it, and I’ll edit projects off of that using the Wine copy of Scrivener/Scapple/NewThingWeDon’tTalkAboutYet, or even the Windows virtual machine running on that (meaning its networked to a networked system!). Meanwhile the phone/tablet is jacked into the workstation with iFuze, which is another kind of networking layer that lets me open projects directly off it without having to sync or copy anything back and forth.
That’s a lot of technobabble that most people will never encounter. The important takeaway is that all of this works seamlessly and flawlessly. It works way better, I would say, than any kind of sync because all changes are made immediately to the source, there is no confusing mishmash of “local copy” vs “online copy” and waiting for updates to circulate the planet or even bounce off of low orbiting satellites before it gets to the other device on your desk. The instant I close the project on Windows it is safe to open it on the Mac. I can rapidly toggle between iPhone and Linux without any delay, or punching sync buttons.
Networking over WiFi can be a little slower for some operations, naturally—particularly large-scale Scrivenings, or other commands that would impact or use multiple files, like compiling. But this slowness does not manifest into any kind of operational risk, unlike cloud sync usage.
@kewms : The fundamental issue is speed of access. If the file on the network share is guaranteed to be available when Scrivener goes looking for it, then you’re fine.
Yes, speed is the main thing, but unless you have a really shoddy WiFi connection, the sort that gets disturbed when a microwave is turned on, the reliability should be very high. I’ve not once ever had a data issue. If things are failing correctly, if the network share is stuttering or interrupted, it is handled by the local system as a halt, not an “oh well, I can’t see that I’ll just move on” event. I.e. the software accessing the data will freeze until the connection is reestablish, and if it never is then errors are thrown (of a similar severity to the case where you delete your project while it is open) and we really know something is wrong. It’s not at all like a cloud sync failure where stuff just loads no matter what, even if most of the data isn’t actually there, or you can be gleefully working on last week’s data in half of your project but not the other.
I’m not sure what this is in reference to, but I wouldn’t say that’s a very common event. iCloud Drive works roughly the same as most other sync services in this regard. What you might be thinking of is how it has an “Optimise disk usage” setting enabled by default, which is just as bad as the smart sync setting in Dropbox, or OneDrive. If anything, iCloud’s approach to this is better than Dropbox’s, because the latter doesn’t download anything unless you tell it to (witness the endless sea of “my project is blank!” posts), whereas iCloud only deletes things if you pay no attention to the maintenance and upkeep of your system and let its drive fill up past the safe point.
5 Likes
Thanks for that comprehensive response.
When I finish the demolish and rebuild of our new house (and get the NAS up and running again) I’ll co all out on using the NAS. much more storage and available to all machines.
WTH is a 74yr old doing ‘owner-building’ (reality, project managing and acting as ‘slave’ to the various trades) a house? Guess writing will suffer for the next 8-12 months. 
2 Likes
If you’re going into the walls, you might as well make sure there is good quality Ethernet cabling. While anyone accustomed to SSD speeds will note a drop in speeds, it’s going to be a lot closer to spinning platter drive speeds than WiFi. When I did IT for a little video editing and graphic design shop, almost all of the work was done over servers wired into stations (buffering raw data from cameras into workstations being the main exception, you definitely need a local RAID-0 setup to do that kind of bandwidth). Writing and reading text files is nothing compared to that.
Whether that requires dongles or adapters on laptops is another matter!
3 Likes
My husband spent way too much time in our last house crawling through our attic and fishing cables through walls getting ethernet connections where they were needed. Both a pro and a con of home ownership 
Gah, that brings back traumatic memories of wearing a full respirator and head to toe coverings in a 30°C attic for hours, and still getting fibreglass burns everywhere.
1 Like
My background is all semiconductors/IT, so yes I will be running all the electrical wiring and ethernet cables. The sparky will check the wiring and connect to the switchboard.
There are two ways that Mac apps work with iCloud. With Scrivener, you can save a file to iCloud Drive. You can see that file, move it to another location, etc. Apps that work with databases use what’s called CloudKit, a framework that Apple has developed so apps can connect to a database stored on iCloud that users don’t see. Apps like that don’t open documents, just their database.
Just barging in to add “… unless the whole system is cloud-based” 
(in which case the files are seen on a local drive by Scrivener)
Don’t open a project on two devices at the same time. Make sure to upload and download on each computer. That’s works fine