Just discovered another similar occurrence that may add some more data. It appears that when I switch GIT branches, which causes some files in my folder to be changed, TextMate is not reloading the changed files (as it did in Version 1). What I used to get in V1 was that if there were no changes pending on the file when I switched branches, TM would quietly load the new version of the file; if there were changes pending, it would ask if I want to save the current TM copy or overwrite it from the copy on disk. But it seems like it might not be doing this (or at least not doing this consistently) on V2. All this makes me think that there might be an issue with TextMate’s file system handling under OS X.

Unfortunately, I only discovered this issue today (based on GIT history I can tell that it happened three days ago), so I wasn’t able to apply any of the suggestions from your earlier email. You can be sure that I’m keeping an eye on this now.

On Aug 21, 2016, at 9:56 AM, Jack Royal-Gordon <jackrg@pobox.com> wrote:

From: "Allan Odgaard" <mailinglist@textmate.org>
Subject: [TxMt] Re: Weird file not updating problem
Date: August 21, 2016 at 2:56:20 AM PDT
To: "TextMate users" <textmate@lists.macromates.com>
Reply-To: TextMate users <textmate@lists.macromates.com>


On 20 Aug 2016, at 8:57, Jack Royal-Gordon wrote:

I made some changes to a file that was open as part of a Rails project (the whole project was opened) and saved the changes. TextMate showed the file as having no unsaved changes. However, inspecting the file outside of TextMate, I could see that the the changes were not saved.

And even pressing ⌘S did not change that? ⌘S will always save, even if it shows “no changes”.

Did press ⌘S several times, as when I ran the file and it did not work I thought I had forgotten to save.

Also, when you have a file open, you can use Bundles → Diff → Document With Saved Copy. This will run a diff util on the buffer and the file on disk, that should be able to confirm if somehow TM’s buffer is different with the file on disk after ⌘S.

That’s a good idea. Did not know about that.

I rebooted my computer and when TextMate reopened, there was the file with my changes showing (but which were not saved although again it showed as having no unsaved changes). I had to close the file, reopen it, and re-apply the changes before saving again in order to actually save the changes

So you rebooted, re-opened the file, and while TM found your (unsaved) changes, it would still not save on ⌘S. But closing file (again) and re-opening now did show the file on disk, and you could save?

Correct. When I reopened, it showed the file without the changes that did not save.

[…] I wanted to see if this was a known issue with 2.0-beta.12.

Nothing I have heard of before, but from the description above, it really sounds like TextMate was operating on a different file than what you was inspect on disk, that would explain all of the behavior perfectly, including rebooting and showing the updated file “with no changes”, yet after closing it and opening the (right) file, you now lost the changes, and had to re-do them.

Since I opened a folder in Textmate and was accessing files via the File Browser, I have a hard time imagining how it was accessing a different file. But I agree that that would explain all of the strange behavior.

So what should probably be looked into is, how did it get to operate on this other file, and where on disk was it?

Yes, that would be the question.

Did anything work on the files on disk (TextMate will track renames, hence if you open /path/to/file and then move it to /path/to/other/place, it will update its reference).

Should it ever happen again, you can right-click the proxy icon to see where the file is on dis, or use File Browser → Reveal Document.

I will do that. Thanks for the response.