Hi, folks
I’m loving TM v2 – and would love to switch to it full-time, but have found a critical bug for me in b9147 which is making that awkward.
One of my projects is hosted on an old NFS v3 share (hosted on old Solaris 9 server) which is auto-mounted on my Mac Pro (running 10.6.8 – which I’m conscious is becoming deprecated with TM2; I’ll be upgrading to 10.8 soon). The file is owned by a different user, but the share is root-mountable from my workstation, so ‘sudo’ will allow me to update the file.
After making a change to a file, I press CMD-S, enter my credentials, and it prompts with: The document “filename.pm” could not be saved. set_attributes() failed: Attribute not found. The file *is* updated on disk, but the red “close window” icon in the top-left of the window remains in its unsaved state, and TM thinks the file hasn’t been saved.
I’ve tried the TM1-style fix (though I’m not sure whether this still applies to TM2) before restarting TM2: http://manual.macromates.com/en/saving_files#extended_attributes_metadata but this doesn’t help.
Logged messages:
$ g textmate /var/log/system.log Sep 18 10:07:06 [0x0-0x76a76a].com.macromates.TextMate.preview[34899]: TextMate: error unobserving fd 31: No such file or directory Sep 18 10:07:06 [0x0-0x76a76a].com.macromates.TextMate.preview[34899]: TextMate: error unobserving fd 13: No such file or directory Sep 18 10:07:07 SecurityAgent[46060]: com.macromates.textmate.openfile|2012-09-18 10:07:07 +0100 Sep 18 10:07:09 [0x0-0x76a76a].com.macromates.TextMate.preview[34899]: authorization (pid 34899): got âcom.macromates.textmate.openfileâ Sep 18 10:07:09 com.macromates.auth_server[51179]: authorization (pid 51179): got âcom.macromates.textmate.openfileâ
I’m not expecting you to be able to replicate the problem (my condolences if you’re using NFS for anything ;-), but I thought I should report the problem in case it was helpful. Is there anything I could try which would help you troubleshoot this?
If there’s a local change I can make (a .tm_properties file option for the root of the shared folder, say), I’d be grateful for any advice… (in the meantime, this is all the incentive I need to transition off our old NFS server to our git repo ;-) ).
Best wishes, Steve
PS my NFS shares are mounted with these options (which usually help with Solaris NFS servers)
$ m /etc/nfs.conf # Mount options to help ease problems with flaky NFS connections to Solaris 10 NFS (v4) shares
nfs.client.mount.options = vers=3,tcp,resvport,soft,intr,bg,locallocks,rdirplus,nosuid,nodev
___________________________________________________________ This email has been scanned by MessageLabs' Email Security System on behalf of the University of Brighton. For more information see http://www.brighton.ac.uk/is/spam/ ___________________________________________________________
On Sep 18, 2012, at 11:39 AM, Steve Holden S.J.Holden@brighton.ac.uk wrote:
[…] have found a critical bug for me in b9147 […] set_attributes() failed: Attribute not found.
Afraid the bug is in NFS. If TextMate gets an error from any of the API involved during save, it will report that as an error (as it should) and treat the file as not saved.
Here setxattr() clearly fails with an error other than “not supported” (which would be ignored).
I might change TextMate to ignore all errors related to extended attributes, though given that you are on 10.6, this wouldn’t help you right now.
I’ve tried the TM1-style fix (though I’m not sure whether this still applies to TM2) before restarting TM2: http://manual.macromates.com/en/saving_files#extended_attributes_metadata but this doesn’t help.
There is a 2.0 way to do the same:
defaults write com.macromates.TextMate.preview volumeSettings '{ "/net/" = { extendedAttributes = 0; }; }'.
This will disable them for all paths under /net/ — this setting should be moved to .tm_properties, but right now, the above should be a workaround.