When I use the CMT+T File Chooser, I type "webapi" to open lib/webapi.js, but on hitting enter, it actually opens lib/socket.js
Likewise trying to open socket.js, opens bot.js
Strangely it is even opening the wrong file when I dblclick from the File Browser on the left.
Some files do still open correctly.
On 8 Jul 2016, at 15:42, Carpii UK wrote:
[…] it is even opening the wrong file when I dblclick from the File Browser on the left.
Is this a local HFS+ file system?
Have you tried relaunching TextMate? And if so, try also reboot your machine, because it sounds like something is seriously messed up.
And just to be sure I understand this correctly, when you do open file A, and file B opens, the proxy icon / title bar etc. will point to B, right?
Original post at http://lists.macromates.com/textmate/2016-July/039633.html
Is this a local HFS+ file system?
Unfortunately not, its a samba share, and a continuation of the long-running problems I've been having developing with TM over SMB
And just to be sure I understand this correctly, when you do open file A,
and file B opens, the proxy icon / title bar etc. will point to B, right?
These are the symptoms I'm seeing, yes. I've since noticed this only happens after getting an Atomic File Save failure, so its all kinda linked back into the original problem I was having with Atomic Save failures, the difference is I;ve since tried to reconfigure SMB a bit
Restarting TM does not fix it, nor does restarting samba server. Unmounting the share from OSX and remounting it, does fix it.
The dilemma is I've yet to see the same issue using other editors like Atom, nor do I think TM is doing anything it shouldn't be For whatever reason though, the combination of atomic saves over an SMB share just doesn't seem reliable for me
I plan to try and branch TM to disable Atomic Saves for certain paths (like /Volumes/*) I've dug through the source a little, but this change doesn't seem trivial, so any gotcha's or pointers would be appreciated
Anyone who is using TM over a SMB share, and not seeing this issue, I'd really love to hear from you!
Thanks Paul
On 24 Aug 2016, at 2:40, Carpii UK wrote:
I've since noticed this only happens after getting an Atomic File Save failure, so its all kinda linked back into the original problem I was having with Atomic Save failures, the difference is I;ve since tried to reconfigure SMB a bit
So even after you disabled the support for mangled Windows 95 names, you are still seeing failure from atomic saving?
I plan to try and branch TM to disable Atomic Saves for certain paths (like /Volumes/*) I've dug through the source a little, but this change doesn't seem trivial, so any gotcha's or pointers would be appreciated
TextMate reporting “Atomic Saving Failed” is a bit of a misnomer.
I think I described it earlier, that on a network file system it would create a new `/path/to/file~` and then run `mv /path/to/file~ /path/to/file`.
So what you probably want is to instead open the original file directly and just overwrite it, so you are not disabling a feature, your changing the code (to be less safe).
I mentioned some tests in the thread about atomic saving, if it still fails for you, evne with the name mangling support disabled in SMB, it would be good to get the results from these tests, as then TextMate could maybe handle the issue better.
So even after you disabled the support for mangled Windows 95 names, you are still seeing failure from atomic saving?
Unfortunately, yes.
I was sure my Samba config changes had fixed the problem, but it was just a red herring My changes don't seem to have fixed much at all, although when it does fail, acts a little differently to what it did before
I plan to try and branch TM to disable Atomic Saves for certain paths (like /Volumes/*) I've dug through the source a little, but this change doesn't seem trivial, so any gotcha's or pointers would be appreciated
TextMate reporting “Atomic Saving Failed” is a bit of a misnomer.
I think I described it earlier, that on a network file system it would create a new /path/to/file~ and then run mv /path/to/file~ /path/to/file.
So what you probably want is to instead open the original file directly and just overwrite it, so you are not disabling a feature, your changing the code (to be less safe).
Thanks, I'm right in thinking ./Frameworks/file/src/save.cc is the place I should be looking to make this change?
I mentioned some tests in the thread about atomic saving, if it still fails
for you, evne with the name mangling support disabled in SMB, it would be good to get the results from these tests, as then TextMate could maybe handle the issue better
Good point. I will re-run these tests I think I provided the results from this before I made any smb changes, but I will try again now my SMB config is different
Thanks Allan, As I say, I'm sure it's not a TM problem so much as the environment Im using it in, So I do appreciate your continued advice :)
Paul
On 24 Aug 2016, at 23:13, Carpii UK wrote:
TextMate reporting “Atomic Saving Failed” is a bit of a misnomer.
In current HEAD I improved this so now you see the actual issue (rather than having to read that in the console).
Thanks, I'm right in thinking ./Frameworks/file/src/save.cc is the place I should be looking to make this change?
This is probably what you want to change: https://github.com/textmate/textmate/blob/master/Frameworks/io/src/intermedi...
This abstracts away “atomic saving” and you could replace it with something that is basically a no-op, e.g.:
struct PUBLIC intermediate_t { intermediate_t (std::string const& dest) : _path(dst) { }
operator std::string const& () const { return _path; } operator char const* () const { return _path.c_str(); } bool commit () const { return true; }
private: std::string _path; };
Then just delete the `intermediate.cc` file and you have “unsafe saving” that just overwrites the file in place.
But don’t blame me if you experience data loss!
This is probably what you want to change: https://github.com/textmate/ textmate/blob/master/Frameworks/io/src/intermediate.h
This abstracts away “atomic saving” and you could replace it with something that is basically a no-op, e.g.:
Thanks Allan, this is a huge help
But don’t blame me if you experience data loss!
Don't worry, I wont!
I'm seeing occasional data loss as it stands anyway, but I'm certain its due to some oddity with samba. Hopefully this change will help shed some light on what the actual problem is
Gits got my back for these occasions anyway :-)
-
Allan Odgaard -
Carpii UK