SOLVED : Crash lost my nights work

UPDATE:

Error is believed to have occurred because the user (me) was running the .scriv project from a USB external thumb drive. It is strongly suggested that the user run the .scriv project from some place on their local machine.

The Scrivener 2.0 release will contain advanced backup procedures to protect the user from their own stupidity. :smiley:

-thanks
j


Hi,

My machine crashed when the power went out (yay!). Does scrivener happen to save anything to a tmp dir some where? I am working from a thumb drive and none of my 5 hours of work was saved. From the command line I have been digging around the file structure of the .scriv directory and can find no auto-save files anywhere. This is a pretty big blow to my confidence of your product. I hate to complain but it sucks when this stuff happens.

Any advice on how to proceed?

-thanks
j

Scrivener auto-saves files into the .scriv directory, so they should be there. When reopening the project, they should appear in a “Recovered Files” folder if they do not appear in the original place in the binder. Of course, if when your machine crashed it did something horrible and somehow reset itself to five hours before, then there is nothing Scrivener can do about that, but Scrivener does all it can by auto-saving regularly, so the files should be there…
All the best,
Keith

Thanks for the response. When I originally opened the product, it gave some warning concerning the file and program not being closed correctly. Scrivener then appeared as if it was trying to correct the problem. Instead it has reverted to where it (the .scriv project) was at the beginning of the day.

drwxrwxrwx  1 removed  removed  65536 Jun  5 17:41 11.rtfd
drwxrwxrwx  1 removed  removed  65536 Jun  5 17:41 11_notes.rtfd
-rwxrwxrwx@ 1 removed  removed     29 Jun  4 10:12 11_synopsis.txt
drwxrwxrwx  1 removed  removed  65536 Jun  5 17:41 12.rtfd
-rwxrwxrwx  1 removed  removed    503 Sep 29  2007 15_synopsis.txt
-rwxrwxrwx  1 removed  removed  23641 Sep 29  2007 16.pdf
-rwxrwxrwx@ 1 removed  removed     80 Jun  4 07:47 21_synopsis.txt
drwxrwxrwx  1 removed  removed  65536 Jun 15 15:06 22.rtfd
-rwxrwxrwx@ 1 removed  removed     49 Jun 15 15:06 22_synopsis.txt
drwxrwxrwx  1 removed  removed  65536 Jun  5 17:41 23.rtfd
-rwxrwxrwx@ 1 removed  removed     29 Jun  4 10:51 23_synopsis.txt
drwxrwxrwx  1 removed  removed  65536 Jun 15 15:05 24.rtfd
-rwxrwxrwx@ 1 removed  removed     56 Jun 15 15:05 24_synopsis.txt
drwxrwxrwx  1 removed  removed  65536 Jun 15 15:04 25.rtfd
-rwxrwxrwx@ 1 removed  removed     11 Jun 15 15:04 25_synopsis.txt
-rwxrwxrwx@ 1 removed  removed     57 Jun  4 10:08 26_synopsis.txt
drwxrwxrwx  1 removed  removed  65536 Jun  5 17:41 28.rtfd
drwxrwxrwx  1 removed  removed  65536 Jun  5 17:41 30.rtfd
-rwxrwxrwx@ 1 removed  removed     57 Jun  4 15:24 33_synopsis.txt
-rwxrwxrwx@ 1 removed  removed     64 Jun  5 13:31 35_synopsis.txt
drwxrwxrwx  1 removed  removed  65536 Jun 22 01:14 36.rtfd
drwxrwxrwx  1 removed  removed  65536 Jun 15 15:06 39.rtfd
drwxrwxrwx  1 removed  removed  65536 Jun  5 17:41 4.rtfd
-rwxrwxrwx@ 1 removed  removed     23 Jun  8 11:23 41_synopsis.txt
drwxrwxrwx  1 removed  removed  65536 Jun  8 11:27 42.rtfd
-rwxrwxrwx@ 1 removed  removed    117 Jun  8 11:27 42_synopsis.txt
drwxrwxrwx  1 removed  removed  65536 Jun  8 11:27 43.rtfd
-rwxrwxrwx@ 1 removed  removed     45 Jun  8 11:27 43_synopsis.txt
drwxrwxrwx  1 removed  removed  65536 Jun  8 11:28 44.rtfd
-rwxrwxrwx@ 1 removed  removed     46 Jun  8 11:28 44_synopsis.txt
drwxrwxrwx  1 removed  removed  65536 Jun  8 11:28 45.rtfd
-rwxrwxrwx@ 1 removed  removed     42 Jun  8 11:28 45_synopsis.txt
drwxrwxrwx  1 removed  removed  65536 Jun  8 11:29 46.rtfd
-rwxrwxrwx@ 1 removed  removed     66 Jun  8 11:29 46_synopsis.txt
drwxrwxrwx  1 removed  removed  65536 Jun 22 08:30 47.rtfd
drwxrwxrwx  1 removed  removed  65536 Jun  5 17:41 4_notes.rtfd
-rwxrwxrwx@ 1 removed  removed     35 Jun  4 09:36 4_synopsis.txt
-rwxrwxrwx  1 removed  removed  34384 Jun 22 08:30 BinderStrings.xml
-rwxrwxrwx  1 removed  removed   3687 Jul 22  2007 ExportSettings.xml
drwxrwxrwx  1 removed  removed  65536 Jun 22 08:30 QuickLook
-rwxrwxrwx  1 removed  removed  16147 Jun 22 08:30 binder.scrivproj
-rwxrwxrwx  1 removed  removed    240 Sep 29  2007 info.plist
drwxrwxrwx  1 removed  removed  65536 Jun 22 00:50 snapshots
-rwxrwxrwx  1 removed  removed  33474 Jun 22 08:30 ui.xml

I see no sign of a “Recovered File” directory.

Does this sound like a bug to be investigated?

Or is this a design decision…

FYI

The machine crashing was just a power outage. Also wouldn’t it make sense to store a time/date stamp of the machine for further validation against?

developer.apple.com/documentatio … 9-CJBEJBHH

-thanks
j

The “Recovered Files” folder should appear at the bottom of the binder, not inside the .scriv package.

I’m not quite sure why you linked to the dev docs on Core Foundation date representations?

Have you changed your auto-save settings in the Preferences at all? These are set to auto-save after a two second pause unless you changed things. If you have extended the auto-save and didn’t do a manual save at all, then that would explain a loss of files. Otherwise, though, Scrivener saves the files into the project directory, so that was all set up it’s a little difficult to know what is going on and I’m afraid is unlikely to be Scrivener’s fault, although I understand that isn’t what you want to hear when you have lost data.

There are several RTFD files listed in the package with today’s date - have you checked them all to ensure that none of them contain the writing you were doing?

Regards,
Keith

Here is exactly what I did.

1.) Plugged in USB thumb drive
2.) launched .scriv project by double clicking on the .scriv package in Finder
3.) Worked on writing for 5 hours. Not taking a break. Constantly typing. Hitting Apple+S every 15 mintues or so.
4.) Power Outage
5.) Rebooted Machine
6.) Launched .scriv project by double clicking on the .scriv package in Finder
7.) (Paraphrased) Scrivener displayed a message that the project was not closed successfully. It informed me that it was going to try and restore my project. I clicked ok (I am hoping you can shed some light on what was happening here)
8.) Project launched in under 5 seconds and data appeared to have been lost

No, still set two 2 seconds of inactivity. That worries me a little bit. Because I was never inactive. I know that sounds crazy, but I was in the zone and words were just flowing out. So I didn’t try and stop. :slight_smile:

That was me typing into a new page to see how the information was stored in the .scriv package. Just a nerd exploring (and hoping) that his writing was somewhere.

I used ‘VIM’ to explore all the txt files from the command line but I couldn’t track down any of my work. I GREP’d the .scriv package recursively to see if I could find any keywords at all from my writings. Nada :frowning:

Just trying to help out from this earlier statement.

I guess I would us CoreFoundation to store and then validate against the TIME/DATE.

The solution I was thinking in my head was that if the system TIME/DATE has changed in an inappropriate way. (As in less than the current date, or greater than 30 days). Then prompt user to do a full backup of project to .zip/.tar/.txt/.pdf file. (Really anything would be fine)

My current hypothesis is that step #7 was where things went south. If scrivener had backed up the project, or even prompted me to, I would be a little more forgiving.

Again, I am truly just trying to be helpful and save users this headache in the future. Hopefully this advice doesn’t sound arrogant because I really want to love your product. I just didn’t realize the limitations (either perceived or self inflicted) concerning data loss.

-thanks Keith
j

USB writes (all writes actually, but thumb drives most significantly) are cached. Even though you hit cmd-s unless you explicitly flushed (unmount the drive or other OS level force) there is a high likely hood that your write didn’t make it to disk. If you search the forums you will find several threads that clearly stating that thumb drives should not be used for an active project. Backups, yes, active, no.

Here’s hoping KB can help you.

Thanks Jaysen, I was afraid of that. I was assuming that Scrivener was writing to the local hard drive, and then writing to the project file. Tough way to find out though. Guess that teaches me to assume :slight_smile:

I am making an assumption though. If your step #2 was the hard disk then you would be correct that scriv would have use the local disk. Your list seems to indicate that you double clicked the project ton the USB drive. Scriv works just like every other program and saves the file at the same location which was used to open the project.

If I my assumption is incorrect (I hope it is) then a spotlight search for a key phrase in the new content might save you.

You are correct in that I opened the .scriv package from the USB drive. So if Scrivener doesn’t write to a tmp directory locally, I am screwed.

I kinda disagree though with this statement.

There are a lot of applications that behave this way. But there are also those that exist which write in several places locally. In order for data redundancy.

I probably would check the path where the package is being opened from. And account for the USB drive. Or maybe give the option to have projects automatically backed up locally. /Users/username/scrivener/local/

Again, lesson learned, this is just some feedback. :slight_smile:

Automatic backups will be coming up, I think. They’ll probably go to the application support folder in the user’s home. I’m not sure if it is possible for Cocoa applications to “know” what type of drive it is playing with. All external drives get mounted to /Volumes, but those could be Firewire 800, fibre, SCSI, or USB.

My experience is that the “redundancy” of data that you are talking about is the exception not the norm. You are correct that some progies do this, but 99% of the users would be surprised to know that alternate file locations exist.

On a technical note, KB has mentioned several times that scriv’s package based file format (that which lets you see the individual rtfd files) greatly complicates the “Save As” as well as data redundancy concepts (such as the one you suggest). Add to this the habit some folks have of using sciv as something more like Devon Think and you would have a small night mare on your hands pretty quick.

The best strategy for preventing lost work of any kind is
0. Always work from a local disk, not removable media.

  1. Backup.
  2. Backup often.
  3. Backup to external media.

This goes for every app, not just scriv.

As Amber says, automatic backups are coming with 2.0, as scheduled by the use via the Preferences.

The USB drive is the culprit here, though. As Jaysen says, Scrivener really does do what most programs do here - it just saves to the place you have specified for saving. As with most programs, backups are really up to the user - no program can prevent data loss 100% of the time, I’m afraid. I really don’t think that Scrivener can be blamed for this situation, as it is just a sad fact of computing that these things happen. As a developer all I can do is try to make the data Scrivener saves as secure as possible, and as new things come up try to address them and keep making it safer. Your suggestion for local writes for individual files has therefore been duly noted.

All the best,
Keith