When I open my project, although I don’t do anything or enter anything, Scrivener shows the project as modified (asterisk next to the name of the file).
Yes, there are some housekeeping tasks that run as the project is loaded from the disk, and these are queued up to be saved in the next auto-save cycle.
The problem is that you bring up a big project just too look at it, and then see that it’s been modified. You think “Did I press a key by mistake, or did I make some important change and forget about it?” You then try to make a backup before the potential errant keystroke is recorded, or you press Ctrl-Z to try to figure out what changed.
I saw this kind of problem listed on a “Don’t you hate it when…” web site.
So reconsider whether you want Scrivener to tell you “Things have been modified” when you haven’t actually modified anything.
But you have modified something, indirectly, that’s why it indicates changes, or are you suggesting that we shouldn’t do any sanity checks, housekeeping and status updates when loading a project? That could lead to a cascade of problems down the road, and immediate problems with multiple user conflicts (we have to change the project to indicate it is open to other clients).
I guess I’m not understanding.
Let’s say I finished a book on Feb 1. I publish it. I’m all done.
Now on April 10, I open that file to copy some text or just to look at how I phrased something.
Can you give me an example of something that that Scrivener would do to that project that I would want done? Something that would cause the modified date to change, such that I would no longer know when I actually finished modifying it? Sometimes I want to look but not touch.
I’d think I’d want that project left exactly as I’d left it. I don’t want to look, a year later, and say "Whoa, I published that book on Feb 1, why was the project modified after that?
I’m sympathetic to the issue Al raises.
Well, yes. But there is a difference between “changes” made by the program as a matter of housekeeping and/or initializing the work session, and changes that a user makes when actually working on the project. From a user pov, only the latter qualifies as a change, as that is typically understood.
Would it be possible for Scriv to defer committing the initial “just-opened project” changes until the user changes something?
To get around this, let me suggest that once you’ve generated the final output of a project, and will no longer be working on it, use the Backup To command and save it to a folder other than the default folder for routine backups. This becomes your definitive project archive. By default, these backups are all timestamped. With the completion date in the file name, the modified date no longer matters for identification purposes.
I do this routinely at each stage of the project, or when I’m about t cross a point I might what to return to. I also add “sop,” for State of Project, to the file name, just before the date stamp, which further differentiates it from other versions and baks, and makes that category of files more easily searchable.
I first started doing this in another software, where I would output a (presumed at the time) “final,” but might still go in and make changes (eg, production notes), days or weeks later.
I think Save and Save As dialogs should always have an option to add a timestamp (in a user defined format) to the given file name.
Thanks, Mad Cow. I cannot think of any other app that will modify a document even if you don’t modify it.
I will say that the Scrivener’s backup system is inspired, and I love being able to backup a special copy to a thumb drive with abandon, and have it named with date or time or allow me to give it a more significant name. Thanks for that. Take a look at some of my backups:
Just to make sure we’re all on the same page here, what files are we referring to, specifically, when talking about modification dates changing? Originally the objection was in regards to the project doing some housekeeping and then auto-saving it after opening, but now we’ve drifted into modification datestamps on the file system, and I’m not sure what files are changing that you object to.
If you literally just open a project and poke around a bit without changing anything, then close it, the .scrivx will not be modified. Now, there may be some actions in there that you wouldn’t think of immediately as “changing something”. Just so much as selecting some text or moving the cursor around in the editor will trigger an auto-save on the .scrivx because that is where the persistence data is stored.
But if you mean any file in the project hierarchy at all, absolutely there is stuff that will update even if you just open and close it immediately, and since stuff like scroll position and item selection is stored in the ui.ini file, that’s always going to change. There are also internal backups that are refreshed when you open and close the project, and a lock file is created so that second attempts to load the project will throw a warning. So opening and closing a project will always increment a few modification dates. But most of these are going to be tucked away out of sight anyway, I don’t think you’re worried about the ui.ini file, in other words. 
I can’t agree with this one enough. I learnt to distrust filesystem modification dates long ago. I date everything in the filename using a concise format.
As a naive user, my reaction is the same as TromboneAl and Mad Girl Disease. If I just opened a project to look around in it, but made no changes, why is any visible change flag or visible save/delay or behind the scene file time stamp modification occurring when I exit/close? Doesn’t happen with Word and Excel.
On the other hand, both file content and file time stamp modifications happen if I just open and exit an Access database without making any changes.
As a naive programmer, I recognize that Scrivener is a database app, and I defer to L&L’s experience, decisions and expertise. The tools, environments and resources involved and required may dictate this or make the alternative prohibitively expensive.
One can always speculate as to what the ideal should be, but speculation is cheap and implementation is hard and costly. Software is never magic or perfect, even when developed by billion dollar megacorps.
A number of folks have whined about Scrivener not actually stuffing everything inside some idealized database, as opposed to its use of a database plus lots of file system files and folders… Obviously wrong, should be fixable in a weekend…
But that would have an alternate set of problems and issues. Hey… my project is corrupted, how do I extract stuff out of a broken database? What? I have to use an SQL utility? What? It’s in some proprietary/non-human readable form? Go find some experienced SQL admin to help me?
I just checked and one attempt at implementing a Scrivener-like writing app using an SQL database (implemented atop Word, stored multiple Word docs inside an SQL database) has since backed away from that, due to various SQL database related issues, to using lots of Word documents in the operating system file system, plus a smaller (presumably simpler) SQL database to lash them together… presumably in a manner much more like what Scrivener employs.
See writingoutliner.com/writing-software/blog/
particularly “Some data security notes:” (database issues vs DropBox) and
“About to fundamentally revamp” and “The None-human-readable file format”.
Gosh, thought Scrivener was the only app impacted by cloud sync issues and the only app foolish enough to not put all its eggs in the database basket… 
Best I can suggest is 1) post such a desire as a polite well reasoned request for consideration in some future version and 2) keep an eye out for some other app that does things the way you prefer (or write your own). If L&L are wrong technically or in terms of what many/most want or need, the real world will correct them. To date, their real world track record suggests they know what they are doing and are making good calls.
Okay, I’m done venting.
This is one of the things I love most about Scrivener, that it worked with individual files and not one big database. It was decisive in my giving it a chance, since under a worst case scenario of a totally corrupted “Scrivener project,” the core of my work would not be at risk.
My assumption going in was that S would work similar to Access or Outlook, with one huge database. So it was a pleasant surprise to find the “mess” of individual rtf files – and that even the .scriv file was readable should the need (or overwhelming curiosity) arise. So in effect, Scrivener uses the native file system as its “database.” Nice.
There is something having to do with saving that I’ve been meaning to ask about: What actually happens when auto-save runs?
The reason I ask (other than curiosity and being a paranoid backer-upper) is, I’d like to get an idea of the different levels of (let’s say) vulnerability a project goes through during a session, and how this relates to the auto-save interval.
Is it the case that, at the moment the asterisk disappears from the title bar – including when that happens after a manual save – the project and all of its files are fully saved, or might there still be rft or other files in the ‘docs’ folder that have not yet been saved? I’ve made a casual attempt or two to figure this out myself, looking at timestamps, and it looks like it only saves the .scriv. But it’s not very clear.
Never heard of this program. Sounds interesting. To be honest, the idea of a Scrivener-like work environment and file management model that used Word as its text editor has a lot of appeal. It’s all in the implementation. For all its quirks and eyeroll-inducing flaws, Word is hard to beat as a text editor. (Am I allowed to say that here? 
)
[Edit: One downside of basing it on Word is the risk that MS will again change some aspect of how Word works, or (as just recently happened) change its licensing policy, which could make useless any shell environment built on it. That said, I’d be thrilled if Scrivener was able to fling docx files with the same ease and transparency as it does rtfs.)