<blockquote>
<p>I suspect it is, or was, to avoid getting notified by Geany's own changes to the files. This might have been fixed since then, or there might be a better fix.</p>
</blockquote>
<p>I thought that, but it shouldn't be a problem with local disks since the OS controls mtime.</p>
<p>IIUC there used to be a problem with network file systems since they use the server time for mtime, but if the server hadn't finished writing the file when the application did what Geany does and stats to get the timestamp shortly after a close, the stat gets the clients idea of mtime and the servers was likely later (newer).  But would trigger the message on the next stat when the client had updated its time, so it can't be for that.  And at least on Linux and NFS thats now fixed by forcing a sync with the server before a stat is returned, so mtimes are the same, don't know about Samba.</p>
<p>Or maybe in its really really early life (I didn't go back in history past ten years but I have a vague memory) the system time was used for the timestamp after save instead of statting the file again, it would always be newer or the same as the disk time so equals wouldn't work.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany/issues/2133#issuecomment-488967009">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAIOWJ4TRSJR4IUCHS5VP6LPTPNJBANCNFSM4HI2SZYQ">mute the thread</a>.<img src="https://github.com/notifications/beacon/AAIOWJ6V5PHFRA6DM2IIVRDPTPNJBA5CNFSM4HI2SZY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODUSQWYI.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/geany/geany","title":"geany/geany","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/geany/geany"}},"updates":{"snippets":[{"icon":"PERSON","message":"@elextr in #2133: \u003e I suspect it is, or was, to avoid getting notified by Geany's own changes to the files. This might have been fixed since then, or there might be a better fix.\r\n\r\nI thought that, but it shouldn't be a problem with local disks since the OS controls mtime. \r\n\r\nIIUC there used to be a problem with network file systems since they use the server time for mtime, but if the server hadn't finished writing the file when the application did what Geany does and stats to get the timestamp shortly after a close, the stat gets the clients idea of mtime and the servers was likely later (newer).  But would trigger the message on the next stat when the client had updated its time, so it can't be for that.  And at least on Linux and NFS thats now fixed by forcing a sync with the server before a stat is returned, so mtimes are the same, don't know about Samba.\r\n\r\nOr maybe in its really really early life (I didn't go back in history past ten years but I have a vague memory) the system time was used for the timestamp after save instead of statting the file again, it would always be newer or the same as the disk time so equals wouldn't work."}],"action":{"name":"View Issue","url":"https://github.com/geany/geany/issues/2133#issuecomment-488967009"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/geany/geany/issues/2133#issuecomment-488967009",
"url": "https://github.com/geany/geany/issues/2133#issuecomment-488967009",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>