I accidentally deleted a Scrivener project I was working on while it was open and Scrivener allowed it to happen. This is really poor experience…The file should have been locked.
At any rate when I went back to Scrivener I was presented with a message that read
When I clicked OK, Scrivener then closed my file. Unfortunately for me, I had emptied my Trash can too.
It recovered a very small amount of what I had worked on. I don’t suppose there is anything I can do to recover the rest of the file is there?
I’ve tried Disk Drill recovery software, but I can only find a few .rtf files (no .txt files). Is there any other file types I could look for?
Do you have Scrivener backups available?
Or Time Machine backups, perhaps?
How? How could Scrivener prevent you from deleting the project? Scrivener has no control over what you do in the Finder. If you lock a file, it becomes read-only, so Scrivener wouldn’t even be able to open the file in that case anyway (and if it could, you wouldn’t be able to do any work on it).
As Briar Kit says, though, as long as you didn’t disable automatic backups, backups of the project should be available.
As a “dumb way to break the entire point of scrivener efficiency” …
Maintaining an active file handle on each file in the directory with file position != to EOF or 0.
Quick test shows that any file not currently opened will be deleted while open files will show a “file open” error in the finder when the trash is emptied.
That wont stop someone from putting the file in the trash, closing scriv, then whacking the contents. And it has the added negative of bloating scriv in mem footprint.
Bad idea. Bad.
Briar Kit - Thanks, I was able to recover a version of my file…All was not lost.
As for the other posts - I’ve used Windows primarily in the past and when I have a file open and there is an attempt to delete or move that file, it is not allowed to happen as the file is open.
I thought a Mac would do the same. I just tested out the same scenario with Word and I am allowed to delete the file as well. This is still an extremely poor user experience. I should never be allowed to alter a file with another program when the file is open. I don’t want to get into a debate about it, it’s just my two scents…
Not a Scrivener problem, but perhaps an OS problem.
Good news…heartbreaking to lose work.
Not an OS problem. It’s a philosophy problem.
Windows kernel manages files completely differently than OSX due to the nature of their historical development (single vs multi-user (multi-headed-multi-user, not 2 single access account at a time)). Newer versions of windows (I think it started with 7) use a more “unix like” approach to file handles though.
Additionally, the “type” of file and method of active editing re important as well. A package, what a scriv doc on OSX is, isn’t a file, but a directory with untold numbers of files in it. A word doc is a single file, a true file (not really as it is a compressed package (or as last time I looked)) . BUT… if the app (word) loads the file to RAM and sets the file handle pointer at EOF (End Of File) then the unix kernel will interpret it as available unless an flock* open sequence is used. Then the OS sees that the file is locked and “should” respect the in use concept. BUT … flock libs aren’t guaranteed to work. If I’m using flock in my code, but you are simply calling open(), read(), write(), close() and (god forbid) unlink() then … well so much for my lock.
flock is also “expensive” in terms of OS overhead. apps like scriv may have a gazillion files open will likely run into performance issues pretty soon.
All the propeller heads are going to rip this post to shreds. Just remember that not everyone gets the tech jargon like we do. Sometimes a simple “close enough” answer is all that is needed. Let it be until someone really needs a full file locking tutorial…
Yes, I like parenthetical expressions. It’s how I think. A bit scattered. But all there.
Yes, I like ellipses. It’s how I think. A bit scattered. But all there.
- [size=80] that’s actually f-lock … File LOCK … it’s a low level thing that exists in most OS that is supposed to signal a file that is open and unavailable for writing by other apps. IT bit heads forget to share our decoder ring on occasion. [/size]