Extensive edits lost

[TonySig]

Curious as to why Scrivener lost all my edits. I work on a PC. HUGE amount of work. I saved and always do, religiously. All files go to Dropbox. Always have. It is integrated into my desktops. Sccrivvener kept insisting I do an upgrade. Could that be it? MS Word is looking dang good right now.

Anyone have any insights? Might there be a way to recover the chnges?

Thanks

[JimRac]

Find your zipped backups. That’s your priority.

[Major Major]

I must say I'm absolutely stunned by the sheer numbers of people who come on this forum to say that Scrivener has somehow eaten their work, and that the responses are so mild, like "well, find your backups" --- as if it was perfectly normal for a program to lose one's work!

Hello??!! It's not!!

I'm amazed that there isn't a more concerted effort by the L&L folks to find out why this happens to SO MANY PEOPLE, and to stop it from happening.

Really, boys and girls - you seem like a decent company. THIS IS NOT NORMAL. Please do something to fix it.

[krastev]

I must say I'm absolutely stunned by the sheer numbers of people who come on this forum to say that Scrivener has somehow eaten their work, and that the responses are so mild, like "well, find your backups" --- as if it was perfectly normal for a program to lose one's work!

Hello??!! It's not!!

I'm amazed that there isn't a more concerted effort by the L&L folks to find out why this happens to SO MANY PEOPLE, and to stop it from happening.

Really, boys and girls - you seem like a decent company. THIS IS NOT NORMAL. Please do something to fix it.

Have you noticed that those are almost always people who happen to have only one post? Not that I'm insinuating anything, like it may be someone from a rival company or disgruntled users, I'm definitely not saying that.

I also notice, that the few legitimate cases are usually resolved, by finding out the mistakes has been on the user side, or his hardware, or other types of software (like antivirus,) and not a Scrivener fault?

[JimRac]

I must say I'm absolutely stunned by the sheer numbers of people who come on this forum to say that Scrivener has somehow eaten their work, and that the responses are so mild, like "well, find your backups" --- as if it was perfectly normal for a program to lose one's work!

Hello??!! It's not!!

I'm amazed that there isn't a more concerted effort by the L&L folks to find out why this happens to SO MANY PEOPLE, and to stop it from happening.

Really, boys and girls - you seem like a decent company. THIS IS NOT NORMAL. Please do something to fix it.

IMHO there is no mystery, although I can't say yet what happened in this poster's particular case.

I've been hanging around these boards long enough to see that *most* times--not all, but most--a poster who has lost work was syncing their projects.

Syncing is inherently risky, when you're working with something as complex as Scrivener's file structure.

It's simple enough to do correctly, but very easy to screw up, not to mention there are forces at work outside the user's control. I've seen dozens of posts where it's apparent that a syncing mistake botched a project, and, I've got to tell you, it breaks my heart when people lose writing, but I've learned to move on. It's a never ending current of folks who don't understand the risks involved until it's too late.

And that's also when we learn they haven't implemented a backup strategy, And *that's* what results in lost work..

I had a back and forth here a few days ago with a guy who insisted on storing his live project on Dropbox *as a backup*,despite the fact he was (properly) taking zipped backups and storing them elsewhere on the cloud, and despite the fact that he wasn't sharing his project with another computer, In other words, he had no reason to put the project on the cloud, yet still he did so. And he was wondering why he started getting errors in his project.

People just don't understand the risk, until it bites them in the ass.

So, to answer your specific point: People lose work because they embark on a program of syncing without understanding the risks, *and* they don't implement a backup strategy.

It's sad, and it doesn't have to be that way, but IMHO, it's no mystery at all.

(Again, I can't say that this is the current poster's challenge. We'll see what they say.)

The fine people at L&L couldn't have made implementing backups any easier, and there's only two faults I can find with their approach:

1) I disagree strongly with the default of retaining only 5 backups. Their reasoning is they don't want to clutter the user's hard drive with backups. My thinking is that cluttered hard drive is better than empty broken project + 5 zipped backups that look just like the empty, broken project, and are useless for restoration purposes.

2) They don't explain clearly enough in the manual that Scrivener's "save after 2 seconds" is *not* the same thing as Word's "save", at least on the Windows platform. This gives people a false sense of security that Scrivener's *save* is fully backing their project up, when in fact it's not. (Then again, since it seems many people don't read the manual, making this change probably wouldn't help anyway.)

I've wandered far off the original poster's concerns, so I'll stop here.

[tomwood]

JimRac - good points.

If a project is broken during a botched sync, is it just the Binder (the XML file) that is actually corrupted? If so, even damaged projects can be re-constructed by going into the project folders and retrieving the RTF text files. It's a pain, but doable.

[kewms]

JimRac - good points.

If a project is broken during a botched sync, is it just the Binder (the XML file) that is actually corrupted? If so, even damaged projects can be re-constructed by going into the project folders and retrieving the RTF text files. It's a pain, but doable.

Any file that has changed between Computer A and Computer B is potentially at risk.

A synchronization error occurs when a change on Computer A is, for whatever reason, not successfully uploaded to the Dropbox (or other) server, then downloaded to Computer B. The results will depend on exactly what piece of information failed to synchronize.

Katherine

[kewms]

I must say I'm absolutely stunned by the sheer numbers of people who come on this forum to say that Scrivener has somehow eaten their work, and that the responses are so mild, like "well, find your backups" --- as if it was perfectly normal for a program to lose one's work!

Hello??!! It's not!!

I'm amazed that there isn't a more concerted effort by the L&L folks to find out why this happens to SO MANY PEOPLE, and to stop it from happening.

Really, boys and girls - you seem like a decent company. THIS IS NOT NORMAL. Please do something to fix it.

In my experience, the FIRST PRIORITY of someone who has lost work is to get it back. Restoring from a backup is usually the fastest and easiest way to do that.

THEN, once the person is no longer seeing their life flash before their eyes, it can be useful to examine what happened and how to keep it from happening again. As JimRac noted, almost all such incidents involve synchronization in some way, and they very often involve what I would consider poor synchronization practice, such as failure to confirm that the synchronization has completed before switching systems.

Katherine

[JimRac]

JimRac - good points.

If a project is broken during a botched sync, is it just the Binder (the XML file) that is actually corrupted? If so, even damaged projects can be re-constructed by going into the project folders and retrieving the RTF text files. It's a pain, but doable.

While I see what you mean, ultimately it shouldn't matter which file(s) got botched, because you've got zipped backups to CYA.

That's my theory & practice, anyway.

(My sincere apologies to TonySig for hijacking this thread!)

[steveshank]

I basically agree with the people who are blaming the victims here, but not completely. All syncing etc. is dangerous and the people who have problems tend to not even provide enough information to try to solve their problems because they don't know enough to even think clearly about their problems or understand them.

Please Scrivener experts, correct me if I am wrong, but it appears to me that Scrivener has setup a very complex system where thousands of files are all coordinated by a single control file. They avoid the complexity of a database and mostly use an xml file and thousands of rtf files. In making the decision to avoid the complexity of say an SQL database, they also lost the built in safety it would have provided. This is a reasonable decision, but it did increase the fragility of the system particularly for users who:
1. are computer neophytes.
2. sync between multiple computers or act as if they do.

The fact is, that using word and saving each chapter as a file would probably be less likely to give these people problems.

What I would like to see is more safety built into the system to reduce the fragility of the system. I think some metadata should be stored with each document file so the master scrivener binder file can be reconstructed from the documents folder. Then a file option like "Rebuild the master index file" could offer that.

Is this planned for version 3?

[kewms]

Keep in mind that the Mac Scrivener 2 / Windows Scrivener 1.9 project format was designed before either Dropbox or iOS Scrivener existed. It was modified some to support iOS Scrivener, but mostly by adding a "Mobile" folder: the core structure did not change.

In the Scrivener 3 format, each content file and its associated meta-data files -- like synopsis and footnotes -- resides in a folder with a unique identifier. Suppose, for example, that you create a file on Computer A, but don't sync before opening the project on Computer B. Seeing that the file is missing, you create another copy of it. The A version and the B version have different identifiers, and so when the two are finally united in the same copy of the project, Scrivener is able to recognize that they are different and ask the user what to do. Similarly, Scrivener 3 is not limited to Dropbox's somewhat primitive conflict resolution, but is able to recognize conflicts that Dropbox has flagged and ask the user what to do about them. Moreover, having "grown up" in a world where synchronization exists, Scrivener 3 understands that these kinds of conflicts *can* happen, and has more sophisticated error checking to detect them.

These changes greatly reduce the chance that files will be "orphaned:" present in the project folder, but with no corresponding Binder entry, and therefore invisible to the user. Orphan files are both the scariest conflict -- missing work! -- and one of the most difficult to fix, as they almost always require digging around the project folder, sometimes on multiple systems.

My experience since Mac Scrivener 3's release is that synchronization errors are generally less common, and definitely easier to resolve. More important from the user perspective, I'm seeing a different *kind* of error. When a problem occurs, it's more likely that changes on an iOS device aren't being transferred to a Mac (or vice versa), but at least one version of the project is intact. That's both less frightening and easier to fix than trying to extract a Dropbox conflict file.

Which is a long way of saying that no, Scrivener 3 doesn't include a "Rebuild Binder" command, but it does have a more robust project format that seems to be less vulnerable to the slings and arrows of the Internet,

Katherine

[lunk]

A basic problem is that Scrivener was originally made for Mac, using its packages function (folders looking like files to avoid users from tinkering with the folder content), and then written for Windows using the same file structure which then suddenly is wide open for the user to sabotage. The easiest way to avoid those user errors would have been not to create a Windows version.

[devinganger]

Another culprit, building on what Lunk points out, is the fact that the Windows software ecosystem is a lot more wide open. There is a LOT of poorly written "security" software out there that likes to wedge in between usermode and the filesystem drivers to silently perform real-time operations on files being written and read. I cannot tell you all how many dozens of instances I have personally witnessed of "top end" security software introducing subtle and not-so-subtle bugs -- ranging from annoying to catastrophic data loss -- into applications on Windows server and desktop systems, applications that otherwise work *just fine*.

Then add in all the crapware like desktop background randomizers, "registry cleaners" and "system optimizers", and all the other assorted applications that shim themselves between the cracks in the Windows architecture, and you wonder how people get anything done on Windows. Most applications and helpers that people run these days violated the good programming guidelines from the year they were first released, let alone now years later after the software authors keep finding ways to shim and wedge and work around the best practices and guidelines that have been around for ever on how to write well-behaved Windows software.

Not trying to blame the victims, but there is a very real cost to all the additional complexity we Windows users pile onto our systems. To paraphrase a well-known Windows security researcher, given the choice between stability/security/performance and dancing bears, the average user chooses the dancing bears every time.

[kewms]

Not trying to blame the victims, but there is a very real cost to all the additional complexity we Windows users pile onto our systems. To paraphrase a well-known Windows security researcher, given the choice between stability/security/performance and dancing bears, the average user chooses the dancing bears every time.

Yes. This is why my husband and I switched all our family members over to Macs years ago.

Katherine

[krastev]

Yup, there always will be people, who will take the blue pill, and then there are those who value freedom above all.