The modification date of a directory containing an .rg file is unexpectedly updated when the file is opened and updated again when that session is closed, and in the latter case this happens when nothing is changed or saved.
Steps to reproduce:
1. Start RG
2. Save the session e.g. session.rg in a directory called session
3. Close the session
4. Note the modification time of both the session.rg file and the session directory (e.g. ls -l or ls -lc)
5. Wait long enough to ensure that any time change is noticeable in the OS (a minute is sufficient)
6. Start RG and use Open to navigate to the session directory...note the modification time is not changed by just navigation
7. Open the session.rg file and the session directory time is immediately updated, but that of the session.rg file is unchanged
8. Again, wait long enough to ensure that any time change is noticeable in the OS
9. Close the session and the session directory time is immediately updated again, but that of the session.rg file is still unchanged
Although RG's behavior is not affected in any way, it does not make sense to alter the modification time when nothing has changed, especially a directory which may not be exclusive to RG use.
This is probably due to the lock file that we create.
Unless you have a case where this is causing actual harm, I think this can be rejected.
I forgot to take the lock file into account. The steps to reproduce just happen to cause it to disappear by the time I looked, even though I've seen it in the past :-) So, the directory was indeed modified, just no evidence left to show it.
Yes, you can close this ticket...it's not a bug at all.
Something I forgot to mention, but doesn't change the fact this isn't a bug. Most of the time, my file manager is sorted by modification date with most recent being first. So, in a directory containing RG directories, the ones I am currently working on are at the top. Occasionally, I go back to a really old session just to look at something, and from then on that old session is among the top directories because it was modified by that lock file, although no other RG file in that director was modified.
I guess if you happen to be working in that area in the future, as a new feature (which I won't formally request at this time), you might consider creating the lock file in the temporary directory, unless there is some significant downside to doing that. The lock file is temporary after all.
I've learned over the years not to put too much trust in the directory modification date. Sometimes it is helpful, but usually it is pretty random for various reasons.
Can't put the lock file in a different directory. What if there are two files with the same name in two different directories? The lock files have the same name and things are broken. It's a can of worms. We'll leave it as-is. This is how everyone else does it (e.g. LibreOffice).