I sometimes open a file to see the content, and then close it without any modification. I think Scrivener should not touch the file in this case, but actually it updates Finder Date Modified. I think this is at least not a standard behavior of Mac applications.
Are you talking about the whole project, as opposed to looking at individual items in the Binder? If it’s the whole project, that’s because the program always auto-saves when you close. That’s a safety precaution, and you probably wouldn’t want it to actually be disabled as that could result in loss of work in many cases. A project is quite a bit more complicated than an normal individual file. Opening a project isn’t at all like opening a .txt file on your drive. Keith would know better than I, but there are probably hundreds of things that happen when a project is opened. It’s a very complex operation, and closing a project is no less complicated. It would thus be extremely difficult to decide whether or not any one of those hundreds of things is worth a save or not. It’s not going to work like a single file that can be loaded into RAM and them dumped to disk or not.
As an alternative to opening the project, if all you want to do is poke around at the structure and see if it is the right project, try using Quick Look instead. The new Quick Look view displays an indented outline of the entire Draft’s title and synopses. That should give you a good idea whether or not it is the right project you have selected.
Yes, as Ioa says, this is most definitely not a bug. A .scriv project is a folder of files, and when you open a project a special “lock” file is created inside the .scriv bundle that is used by Scrivener to check that it’s not trying to open a project that’s already open on another machine - that alone is enough to update the modified date of the enclosing .scriv folder. But even if that didn’t happen, as Ioa says, the main project file gets auto-saved on close even if there are no modifications. There are also settings to bear in mind - even if you open a program and make no changes, if you switch to another document or change panes in the inspector, these things need to be remembered, and saved into the UI settings part of the file.
This is standard for programs with similar structures - Xcode projects, for instance, get their modified dates changed just by opening and closing them.
All the best,
Keith
Thanks for the comments.
I hadn’t checked Xcode. But other major applications using a package to store a document, like Keynote, GarageBand, TextEdit (rtfd), OmniGraffle, OmniPlan do not alter modification date just by opening and closing it. What is the difference between Scrivener and those applications? Last modified date is an important metadata. I often search files (or projects) based on modification date using Spotlight. This does not simply work well with Scrivener projects.
As far as I checked, Scrivener does not touch the project folder when it creates the lock file because the lock file is created in a folder in the project’s top folder. Modification date of the top folder is changed when closing a project, as Scrivener saves everything when closing it even if the project is not modified. I don’t really understand why it needs to do so when it knows there’s no modification. What kind of situation do you think of in which the user loses something if the unmodified project is not saved?
To save such information, I think a straight-forward way is to mark the project as modified when such operations are made. The project will be saved when the user closes it because it is marked as modified. If such operations are not made, then the project will not be saved thus modification date is not altered. Is there any particular reason why Scrivener can not be programmed as this?
You can make so many different changes in Scrivener.
Probably (this is just a guess, as I don’t know anything of the codebase) it would be quite probable to introduce a bug if you wanted what you described in your last paragraph. I mean, for this the programmer has to first asses the whole program with all its functionalities, make a catalogue of all possible changes, mustn’t forget even one, and then add the proper code for “remembering”. The last thing is not the complicated one, but assessing all possible changes, and not forgetting any… now, that’s the horror of anyone responsible for the next stable release.
I mean, it would be very stupid, if a user relied on “changes are saved when closing Scrivener” and then, because one routine was forgotten to be marked, would loose that data/setting. (Of course, this could only happen if they changed only that setting which is among the forgotten ones). But still, that would be very annoying (loss of data) to any user, nothing for production.
szabi, Thanks for the comment. I understand what you say. But at least generally, it shouldn’t be so difficult. This is a very common programming pattern that most applications follow. Also as far as I know, many modern application frameworks support implementing such functionalities (dirty flag and undo related things) to some extent. Of course, it must be no piece of cake to implement the functionalities to an already-made application. But if the design is not an intentional choice by some necessary reason, then I think an application should follow the standard behavior that users expect.
I also checked Xcode 4 and it didn’t alter a project’s modification date by opening and closing it. I guess KB mentioned Xcode 3?