NOTE: THIS NOTE CORRECTED BY ORIGINAL AUTHOR ON 3/11/2014
mom42terrificgirls and TravelingBard,
I’ll offer the following in the hopes that it is more help than hurt. Robert or the Scrivener folks can correct me.
File compression consists of taking one or more files, quite often entire folder structures/contents (as an example a Scrivener project .scriv folder which may contain hundreds of files), compacting them size wise and lumping them all together in a single physical file, usually having .zip on the end of that file’s name. This proves useful for signficantly reducing storage space used and for assuring entire collections of files can be dealt with as single easy to copy/backup/transfer/manage items whose integrity can be assured.
The catch is that their contents generally cannot be directly edited or worked on. Such compressed .zip files generally need to first be extracted/decompressed, producing an extracted copy of the contents elsewhere that can then be directly edited or worked on, used for recovery, etc. In newer versions of Windows, one basically does this by right clicking on the .zip file and specifying extraction of the contents to some location. In older versions of Windows, or if one prefers, this may involve the installation and use of some third party compression utility… WinZip, 7Zip, etc.
Windows (and presumably Mac OS X) can tend to fake one out on this issue, as the file system explorers allow one to somewhat transparently drill into .zip files and view their contents, without realizing that one has crossed the boundary between regular file system and compressed file contents.
If, when one is viewing the contents of a .zip in this manner, one opens a single simple .txt or .rtf file, it appears that one can edit/change and attempt to save the file. Problem is, what one is editing is a temporary copy of the file that Windows has supplied… and when one goes to save, will have to specify some other location, outside the .zip file, to save it to. (There are some third party utilities that can sort of work around this on a file by file basis, but they aren’t practical for a simultaneous multiple file situation like databases or Scrivener projects.)
That’s what you are encountering.
Basically, think of a compressed .zip version of a Scrivener project folder being a frozen project. You can look at its contents (to some extent) in file explorer, but in order to actually work with it as a live project, you first have to thaw/unfreeze (i.e. uncompress/extract it).
In TravelingBard’s screenshot, note the presence of “StairwayNo3.bak4.zip” in the directory path being accessed. That is a compressed .zip file. Windows is trying to be helpful… letting you peer inside the .zip file at its contents… but is also misleading a bit, in that in doing so, it gives the impression that the contents should be directly editable by Scrivener. They are not. They have not been extracted.
In order to access those contents via Scrivener, they first have to be extracted back out into regular file system format. That can be done by right clicking on the .zip file and specifying extraction to some other location, where Scrivener will then be able to work with them.
A Scrivener project is a regular file system folder (with .scriv on the end of its name) that is created wherever you told Scrivener to create it or where you copied one or extracted a compressed version of one to.
Auto-save backups are compressed .zip versions of project folders, maintained wherever specified in Tools > Options > Backup > Backup location.
Additional on-demand backups created whenever one wishes via File > Back Up > Back Up To, are created wherever you specify during that process and are either regular project folders or compressed .zip versions of same, depending on which you specify during that process.
Where one should best locate each of these (project itself, auto-save backups, on-demand backups) varies depending on needs, personal preference, one’s backup strategies, locations, etc. The general recommendation is that project folders themselves should not be located in Dropbox unless there is a critical need to be able to directly edit them from more than one computer (taking pains to assure that only one computer has the project open at a time and that sufficient time is allowed for Dropbox syncing). Rather, the auto-save and/or on-demand compressed .zip backups are probably more appropriate to be in Dropbox. My personal practice is to only have on-demand compressed .zip backups go in the Dropbox folder.
Please see:
Also please see the following Scrivener knowledgebase articles:
Hope that helps.