It’s definitely one of the few things I miss, having moved overseas; I’ve had to adjust. But me and my little moka pot manage!
2 Likes
I bought an antique coffee pot a couple of weeks ago. It would be impossible for me to overstate how much pleasure it gives me just to pour from that thing.
5 Likes
Of these, I would say that #2 is by a wide margin the most common source of support queries these days, but it’s usually easily fixable without further issues. #1 is the most common cause of actual data loss.
1 Like
Does syncing a ZIP backup to a cloud server create a risk of data corruption? No.
Should you rely on such a scheme as your only backup of critical data? No.
The entire point of cloud sharing services is to replicate data across multiple devices. But people don’t consider that they also replicate deletions. To use one extreme example, I once helped a user who had synchronized his personal Dropbox folder to his work computer, but neglected to de-authorize that computer when he left the job. Former employer promptly wiped the disk, obliterating his Dropbox folder, then Dropbox – working completely as designed! – propagated the deletion across all his devices.
Was that a stupid thing for him to have done? Yes, absolutely. But a major reason to have backups in the first place is to protect you from your own stupidity.
4 Likes
Please expand on this; reference unclear. Thanks.
Discussed in this forum so often; not giving device time to complete sync, putting backups on sync service, keeping scrivener project files on “online” folders, deleting the local copy but thinking all ok as files are saved as there will be a copy in the sync server, not understanding role of scrivener vs sync service, using Google drive with Scrivener even though L&L documents not to do, …
4 Likes
No. I’ve done this forever, and never had an issue. And I frequently dig out a zipped backup to check something.
Technical aside: Perhaps worth mentioning that zip maintains a checksum of its contents, and verifies it after compression and, later, after decompression.
2 Likes
Why is it that when someone, @popcornflix in this case, asks about saving backups to the cloud, the thread gets conflated to a discussion of putting active projects in the cloud? It muddies the waters, particularly for those new to Scrivener, who confuse the two.
Mark
2 Likes
That’s true, but I think in relation to the description given in the video, it sounds a lot like this initial error was caused by live project sync errors started the problem. So I can see how the conversation got there.
To focus more on the original post: there are really two questions being asked here:
-
Is it safe to store .zip files with cloud sync: if the answer there is no, then it is not safe to use cloud sync for anything at all. (Obviously the answer is: as safe as these services can be.)
-
Can Scrivener destroy its own .zip backups in a global manner from a single event (as posited in the YouTube video): I suppose anything is possible, but that would take a bug of almost satirical proportions, one that exhibits signs of reaching intelligent self awareness and volition:
- The software updates. The first thing the bug does is go into the backup folder and look for sequences of .zip files.
- For each naming pattern, it then performs a disk-wide search for the original project that created the backup (an enormously complex failure if there is no code that does that).
- The project is opened (which Scrivener never does on its own), and its entire contents are thoroughly deleted (another incredibly complicated sequence of source code that doesn’t exist, that a bug would have to spontaneously replicate equivalent human effort in making the code to do it).
- It then goes through each of the backups relating to that project and updates each .zip to the current state of the project (also, not something the software can do that would take detailed code to enable, recognising date stamps vs sequential number vs zips vs bare .scrivs and handling all of that variation intelligently).
- The project is closed, and it moves on to the next batch of .zip files.
All without the user noticing, incidentally, that for half an hour or whatever the bug is doing nothing but loading every project they have ever made, deleting it, and saving three to twenty-five backups over and over.
Needless to say, there is no code in Scrivener that would even come close to doing that. In fact it’s so far away from being able to do this, even accidentally, that this is one of the things people who are unfamiliar with their data complain about: when the Recent Projects list gets lost (such as in an upgrade), Scrivener has no clue where any of their projects are. But yet somehow it was able to track down every project, open it, wipe it and its backups?
Okay, so putting aside the literal assertion and to speak of what is more plausible: can Scrivener’s backups over time become damaged? Yes, that was discussed above. All it is doing when it backs up is making a copy of the project to a temporary folder, zipping it, and copying it into the backup folder, deleting the oldest in the stack. So if the project this is being done for is itself damaged, and one keeps opening and closing damaged copies, eventually all of their .zips will resemble the damage. There is no way around that in code, because that is a very human problem and the software is blindly doing what the human asks it to do: one by one, delete all good backups and replace them with newer bad ones. That action, from a machine’s perspective, is identical to making good backups.
So in theory a panicked individual could open their “smart synced” project, observe that it appears empty because most of it isn’t downloaded, close it (backing up the empty copy), opening the most recent backup (which is now empty), close it (making another backup), and repeat until they are all now blank, and meanwhile in the background both sync services that are looking at this one folder (in and of itself a bit of a red flag, that’s a really bad idea) are dutifully uploading these new backups. This is not a bug or a malfunction: it is again the machine blindly doing precisely what one asked it to do.
Can at that point tech support help you? Yes, there are ways out of that trap. As dire as that sequence of events sounds, the primary solution is to turn off smart sync and command the service to download all of your data to the device. Now your project is back and your backups can start populating with good data again. If that does not work, most cloud services also support version tracking, and save deleted files for a month or so. All those zips that got messed up, or .scrivs if that option is off, are probably in the deleted-files list, or in the version history for individual backup filenames if the datestamp feature is off.
In short: the video seems to be describing a combination of perhaps the aforementioned Recent Projects confusion, mixed with a dose of maybe cloud sync configuration (the empty project being “smart synced”), and maybe incorrect backup recovery of some sort, like the above scenario. Who’s to really say all this time later, but any of those possible mistakes are very much more likely than a bug that acts more like a systematically programmed virus than a real bug inside of a program that cannot itself do any of those things.
Now for the disclaimer: Scrivener’s automatic backups are, without an external backup preserving them, naturally, at best a weak backup system, in a similar vein to how Time Machine is a weak backup system. They are better thought of as Undo on a larger scale than document editing. And like Undo, they are not meant to be your only recovery option. You can accidentally run Project Replace on every instance of the letter ‘e’, replacing it with ‘x’, and “undo” to yesterday’s backup. If yesterday’s backup is no good, and all the rest are no good, that’s when you use real backups. If Undo doesn’t work in your text editor because you closed it before noticing, you have to look to other sources for recovery. Neither is meant to be infallible, but both are meant to be more convenient than hauling your real backup out of a fireproof safe, plugging it in and running whatever commands you need to pull yesterday’s data from it.
Think of it that way, and you’ll be fine. Thinking of it and cloud storage as a replacement for backing up, and unfortunate stories like in the video may happen.
4 Likes
@AmberV Thanks for explaining that. Would you consider this an accurate summary:
-
The data loss experienced by the lady in the video is not typical and does not represent a known bug in Scrivener;
-
Data loss like hers are sometimes caused by user error because they don’t understand how a partially downloaded file can propagate through the backup system and delete data. This is not a bug, and there are no steps being taken to change Scrivener to protect the user from their own error;
-
Copying the ZIP backup files to a cloud service through a sync mechanism should be as stable and dependable as syncing any other ZIP file to the same cloud service. Scrivener’s ZIP backup system has no history of fragility or corruption that would be exacerbated by syncing the ZIP files to a cloud service;
-
Syncing a working Scrivener project to a cloud service can cause problems including data loss because of a number of factors including human error and the practices of cloud services. This is not a bug, and there are no steps being taken to change Scrivener to alter this behavior.
EDITED: Well, I had hoped for a reply from @AmberV, but I will take their lack of objection as assent.
Scrivener is not responsible for misadventures caused by software other than Scrivener. We have no control over, or ability to change, the behavior of third-party software tools that may be given access to Scrivener projects.
3 Likes
This sounds VERY much like a post that was on a FB group. She was scathing, even to the point of registering a web site with the intent of calling out L&L and Scrivener. Towards the end, I believe she very begrudgingly began to see that Scrivener was not at fault.
The confusion between syncing and backup is widespread.
After trying to explain that a synched project was not a backup which one of the posters insisted it was I was called pedantic.
Seems there are far too many who assume because they’ve put it on the cloud it’s a backup, and refuse to acknowledge that if they stuff up a project when connected, the likelihood is their ‘backup’ will be corrupt before they even realize they’ve made a mistake.
The other common thread was people putting their projects and backups on the same drive/cloud folder. (and not setting offline)
You mention Time Machine. I find it extremely useful and it is my first port of call. During my time at Apple I reviewed hundreds of calls where a Time Machine backup was used to rescue customers. That said, I also use GoodSync to my NAS and Carbon Copy to an external drive. (To be sure to be sure)
3 Likes
I would phrase this as “can make it vulnerable to problems” etc. Your phrasing implies that there is an inherent incompatibility between Scrivener projects and cloud services, which is untrue.
2 Likes
Are you writing a documentary, @popcornflix, or trying to explain a data loss to an insurance company? You seem to be labouring this one despite quite a clear answer.
- Using backups = good.
- More different backup types / locations = slightly higher resilience.
- Follow the intended processes from both your data source and your backup provider and you’ll mitigate the most common source of issues (user error).
- No backup ever gives complete protection, but that doesn’t invalidate their worth.
- You have to make your own judgement on time and money cost vs risk tolerance.
But you could have written that list yourself, before this conversation started.
3 Likes
Of course you keep additional backups. My comment was about how a convenient system like Scrivener’s backup folder or Time Machine is convenient for the same reason it is a weaker backup: it’s always on, attached to the host, and thus subject to the same soft and hard risks. One brownout can take the whole thing down.
It is important to distinguish between these kinds of weaker backups and the ones where it would take an extraordinary catastrophe to lose everything (and then probably at that point one would be more worried about things like potable water and injuries than their novel).
4 Likes
Brownouts - having previously lived in an area prone to such, UPSs litter the garage (NBN fibre modem) and office. 
1 Like