I am not sure if this qualifies as a bug, so I am posting it to the wish list…
I have all my work on an SD card and switch between three different machines. Some of these machines are in hibernation mode when I switch cards. Now occasionally, I forget to insert the right SD card when I turn on a machine again. Scrivener’s reaction to this is that it screams “FOUL!!! I can’t find the file path!!!” and shuts itself down while putting a backup copy of whatever was opened into some arbitrary folder. To me, this is a major headache - it would be fantastic if Scrivener could actually be a little bit more interactive in this situation. A simple “Retry” button would go a long way!
Note that I am using Version 1.6.1 (Windows), but since Scrivener has been doing this as long as I can remember, I am assuming it still does.
I don’t think you can assume that because a suggestion has received no endorsement from L&L, it is therefore deemed unreasonable - especially during a holiday period. (Although it may be. )
Removing removable media from any machine without first using the operating system’s “eject” function leads to one conclusion the media will become corrupt. Just because the machine appears to be hibernating does not mean that all writes to the media are complete. You run the risk of losing work if you do this. Doesn’t matter than 99 times out of 100 physical removal is okay you will eventually run of of luck and you will lose data and in the extreme case corrupt the media so it can no longer be used without a complete reformat. Don’t do it.
I am aware of that, but it has nothing to do with how Scrivener reacts to missing media. Two different issues. Also, if by removing the media will only pose a 1% risk of data loss, it makes little sense that Scrivener takes care of the other 99%, making the total risk 100%.
A retry button probably wouldn’t hurt anything by itself (it could be misused, but so can Save As). I’ll see if that is something we can look into. I think we might have already done that on the Mac in response to feedback, I’ll have to double-check.
I would personally recommend not leaving your projects open on hibernated computers if the projects are on removable media that you tend to swap around. But, I suppose as long as you make certain to never try an open a project a second time it is theoretically fine to continue working that way.
As for leaving projects open in hibernated computers, well it often doesn’t happen intentionally. Close the lid at home, want to continue ten minutes later in the bar, then don’t. Happens easier that you can think. :mrgreen:
Yesterday I was in a hurry because I badly needed to print out a document on my other computer, so I briefly moved SD cards from a hibernating machine. Forgot to return the SD card to my working computer, and here it goes again: An important path was changed. Now you can reinsert your SD card all you want, but I, the Scrivener program, don’t care. After hitting Ok, I won’t forgive you - instead, I will create a needless backup and simply shut down. Mehehehe.
Noticed that this was fixed, and came here to post a big THANK YOU!
But today I also noticed something unexpected. I have to test this a bit more, but it appears like:
If the path remains missing, you click to confirm the “missing file path” info and nothing else happens. That’s great, becaus it gives you all options to either re-insert the SD card or save somewhere else.
However, if you restore the missing file path before hitting “ok”, it seems like Scrivener will still save the backup and close down. Obviously, that doesn’t make much sense (if the path is back again, why close the document).
Again, I need to do some more testing, but it appears like that is what it’s doing.
EDIT: Ok, somehow I couldn’t repeat this manually. This only happened to me (twice) when waking up from hibernation.
The project could not be saved because the project package has been deleted or moved, or the volume on which it exists has been ejected. Files that could be recovered have been saved to RECOVERYPATH. The project will now close.
Version 1.9.6.0 of 3. August 2016
When you reopen the project, you’re not even in the same folder you were when your were forced to eject.
Not sure if the problem has reappeared, or if I simply overlooked it, but it is very disappointing, to say the least.
)
