Is there a 'defaults' option to disable atomic saves in TM2?
I host all my code on linux VM's on an ESXI server Usually I mount them via AFP, but Im ditching this now in favour of Samba
Since moving to SMB/CIFS, I'm finding TM2 is now frequently complaining that it cannot save a file due to 'Resource Busy'
When this happens, even restarting TM2 doesn't fix it, I have to restart the Samba service on the server (which isn't a great solution)
I think it may be somehow related to atomic saves, so Id like to disable those (given that I still have git to protect any aborted writes)
Thanks
On 24 May 2016, at 7:40, Carpii UK wrote:
I think it may be somehow related to atomic saves, so Id like to disable those (given that I still have git to protect any aborted writes)
TextMate use exchangedata() to do atomic saves *when supported*. I’m almost certain that your Samba mount does not support this, so there is likely nothing to disable.
What is using the files in your virtual machine? I’m assuming that it’s a web server, so sounds more likely that this is “locking” the files (caching?) which Samba translates to “resource is busy”.
Next time it happens, instead of restarting your Samba service, try restart anything that uses these files to see if that solves the problem.
Not saying it’s a better fix, but understanding the problem would be first step in finding a solution.
If e.g. it’s some sort of caching middleware, perhaps this can be disabled or configured to not lock your files.
On 24 May 2016 at 11:38, Allan Odgaard mailinglist@textmate.org wrote:
On 24 May 2016, at 7:40, Carpii UK wrote:
I think it may be somehow related to atomic saves, so Id like to disable
those (given that I still have git to protect any aborted writes)
What is using the files in your virtual machine? I’m assuming that it’s a web server, so sounds more likely that this is “locking” the files (caching?) which Samba translates to “resource is busy”.
Next time it happens, instead of restarting your Samba service, try restart anything that uses these files to see if that solves the problem.
Not saying it’s a better fix, but understanding the problem would be first step in finding a solution.
It appears to be the samba daemon itself which is locking the file.
Today I've been editing .tm_properties and have been getting the error regularly During normal operation, smbstatus shows a single lock on it as expected..
$ smbstatus | grep tm_prop 19518 1000 DENY_NONE 0x20081 RDONLY NONE /www/nodechat .tm_properties Wed Jun 1 12:25:27 2016
Maybe 20% of the time I save, I then suddenly get the 'Atomic Save Failed, Resource Busy' error from TM
When this happens, I notice there are be two locks for .tm_properties appearing in smbstatus At this point any further attempt to save the file just fails, and a new lock for .tm_properties~ is created every time I attempt to save
$ smbstatus | grep tm_prop 19518 1000 DENY_NONE 0x20081 RDONLY NONE /www/nodechat .tm_properties Wed Jun 1 12:25:54 2016 19518 1000 DENY_NONE 0x20081 RDONLY NONE /www/nodechat .tm_properties Wed Jun 1 12:26:05 2016 19518 1000 DENY_NONE 0x20081 RDONLY NONE /www/nodechat .tm_properties~ Wed Jun 1 12:26:05 2016
$ ps aux | grep 19518 nodechat 19864 0.2 0.6 396620 6516 ? S 12:21 0:00 /usr/sbin/smbd
Not sure what to make of all this, but perhaps someone who is more familiar with samba has some ideas?
Thanks
On 1 Jun 2016, at 14:15, Carpii UK wrote:
Maybe 20% of the time I save, I then suddenly get the 'Atomic Save Failed, Resource Busy' error from TM
The error text is probably a little misleading, because it’s really TextMate’s “swap and unlink” that fails, and this function tries to do an “atomic save” using whatever means the file system offers, i.e. exchangedata() on a local file system, rename() on a non-local system.
To get the exact error, try enable logging and see what it says: https://github.com/textmate/textmate/wiki/Enable-Logging
Though my guess would be that rename() fails.
In this case though, are you able to run this in a terminal:
mv .tm_properties~ .tm_properties
Or does that also fail with resource busy? And if it fails, does this work:
rm .tm_properties && mv .tm_properties~ .tm_properties
The latter is not something TextMate currently do, but if that works for you, it could fallback to that when rename fails, as we already have ensured the data is on the disk (just under a wrong name), so there should be no data loss issue by removing the original file.
Thanks for the help. I just had this issue again today..
Once the Atomic Save error appeared, I shut down TM and relaunched it from the cmdline You're right, its the rename that fails...
$ rename("/Volumes/nodechat/public/js/client.js~", "/Volumes/nodechat/public/js/client.js"): Resource busy
I ssh'd into that machine (as the same non-privileged linux user I'm using to access the share)..
$ mv client.js~ client.js
This was actually successful, and after that I could also save the file from TM
Now even though TM didn't show the Atomic Save error at this point, it did output a 'write: Broken Pipe' log entry, each time the file is saved. This is true even after restarting TM, so I guess renaming the file means it gotten out of sync with samba Even with the "write: Broken Pipe error", it does seem to save the file successfully.
I'm kinda confused why the rename() fails when TM tries to call it, but doing it manually under the same user account is successful.
On 3 June 2016 at 10:03, Allan Odgaard mailinglist@textmate.org wrote:
On 1 Jun 2016, at 14:15, Carpii UK wrote:
Maybe 20% of the time I save, I then suddenly get the 'Atomic Save Failed,
Resource Busy' error from TM
The error text is probably a little misleading, because it’s really TextMate’s “swap and unlink” that fails, and this function tries to do an “atomic save” using whatever means the file system offers, i.e. exchangedata() on a local file system, rename() on a non-local system.
To get the exact error, try enable logging and see what it says: https://github.com/textmate/textmate/wiki/Enable-Logging
Though my guess would be that rename() fails.
In this case though, are you able to run this in a terminal:
mv .tm_properties~ .tm_properties
Or does that also fail with resource busy? And if it fails, does this work:
rm .tm_properties && mv .tm_properties~ .tm_properties
The latter is not something TextMate currently do, but if that works for you, it could fallback to that when rename fails, as we already have ensured the data is on the disk (just under a wrong name), so there should be no data loss issue by removing the original file.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 5 Jun 2016, at 18:32, Carpii UK wrote:
[…] I ssh'd into that machine (as the same non-privileged linux user I'm using to access the share)..
$ mv client.js~ client.js
This was actually successful, and after that I could also save the file from TM
I want you to run `mv` from your Mac so it goes through the Samba driver as well, i.e.:
mv /Volumes/nodechat/public/js/client.js~ /Volumes/nodechat/public/js/client.js
And if that fails, `rm` the file (also via SMB) and then `mv` to see if that is a workaround (from the Mac side).
As for “write: Broken Pipe” I don’t see this error message in TextMate itself, so that’s a little puzzling. Was this the exact (and full) error message?
On 5 June 2016 at 17:44, Allan Odgaard mailinglist@textmate.org wrote:
On 5 Jun 2016, at 18:32, Carpii UK wrote:
I want you to run `mv` from your Mac so it goes through the Samba driver as well, i.e.:
Ok, I will do this next time it crops up
As for “write: Broken Pipe” I don’t see this error message in TextMate itself, so that’s a little puzzling. Was this the exact (and full) error message?
I believe I copy and pasted it from iTerm, but theres a small chance I just typed it in, so can't say 100%. I will get some exact info on this too, next time I see it.
Thanks
I'm still trying to get to the bottom of this, but not making much progress
Im starting to wonder if its possible a bundle I use could be involved somehow?
Heres a screenie of the JSHint bundle steps.... http://i.imgur.com/6aHFgCL.png
Is it possible TM could be piping the document to the bundle, before the atomic save step has fully completed?
It still wouldn't explain why I sometimes see the issue on non JS files (such as .tm_properties), but its definitely gotten worse since moving from AFP to SMB, so it feels like there is some race condition involved somehow.
I've also tried Atom quite a bit over the past week, but was not able to reproduce any issues in that editor I think I can rule out any issues with my SMB configuration, based on that.
Thanks
On 5 June 2016 at 17:53, Carpii UK carpii.uk@gmail.com wrote:
On 5 June 2016 at 17:44, Allan Odgaard mailinglist@textmate.org wrote:
On 5 Jun 2016, at 18:32, Carpii UK wrote:
I want you to run `mv` from your Mac so it goes through the Samba driver as well, i.e.:
Ok, I will do this next time it crops up
As for “write: Broken Pipe” I don’t see this error message in TextMate itself, so that’s a little puzzling. Was this the exact (and full) error message?
I believe I copy and pasted it from iTerm, but theres a small chance I just typed it in, so can't say 100%. I will get some exact info on this too, next time I see it.
Thanks
Just to chime in here and give some input:
I had this issue appearing on my machine as well and it only happened when editing files on a mounted drive located in a VirtualBox guest (Debian fwiw). I had other issues with that setup (file name case sensitivity, versioning also locking up, filesystem watchers not working and what not) that led me to reversing the setup. I now have the projects located on my MacBook and the VirtualBox guest mounts these instead. Cured all of my problems.
And to maybe spare you from digging further into it, this didn't just happen with TextMate. I tried other editors as well, some of them didn't even show a notice that the save didn't go through and just silently went on. Re-openend the file and all changes were gone.
At times it helped touching the file directly on the guest system (via touch or a text editor), but it wasn't a sure fix.
I know it's not a solution to the problem at hand, but maybe sheds some light. Pretty sure these are issues within the mounting process.
On Thu, Jun 16, 2016 at 11:09 PM, Carpii UK carpii.uk@gmail.com wrote:
I'm still trying to get to the bottom of this, but not making much progress
Im starting to wonder if its possible a bundle I use could be involved somehow?
Heres a screenie of the JSHint bundle steps.... http://i.imgur.com/6aHFgCL.png
Is it possible TM could be piping the document to the bundle, before the atomic save step has fully completed?
It still wouldn't explain why I sometimes see the issue on non JS files (such as .tm_properties), but its definitely gotten worse since moving from AFP to SMB, so it feels like there is some race condition involved somehow.
I've also tried Atom quite a bit over the past week, but was not able to reproduce any issues in that editor I think I can rule out any issues with my SMB configuration, based on that.
Thanks
On 5 June 2016 at 17:53, Carpii UK carpii.uk@gmail.com wrote:
On 5 June 2016 at 17:44, Allan Odgaard mailinglist@textmate.org wrote:
On 5 Jun 2016, at 18:32, Carpii UK wrote:
I want you to run `mv` from your Mac so it goes through the Samba driver as well, i.e.:
Ok, I will do this next time it crops up
As for “write: Broken Pipe” I don’t see this error message in TextMate itself, so that’s a little puzzling. Was this the exact (and full) error message?
I believe I copy and pasted it from iTerm, but theres a small chance I just typed it in, so can't say 100%. I will get some exact info on this too, next time I see it.
Thanks
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 16 Jun 2016, at 23:09, Carpii UK wrote:
I'm still trying to get to the bottom of this, but not making much progress
When you get the error please run these tests on your Mac (not via ssh):
# This is what TextMate does and should fail, otherwise the issue is with TextMate mv file~ file
# This should open ‘file’ in append mode, this might work echo Test >> file
# This is similar to above but also truncates the file echo Test > file
# This simply unlinks the file which is what is implicit in first test rm file
Here I assume that `file` is the file you want to overwrite and `file~` is the temporary file left by TextMate after a failed save.
Please be sure you have a backup of `file` before doing the tests.
Im starting to wonder if its possible a bundle I use could be involved somehow?
Highly unlikely.
When you get the error please run these tests on your Mac (not via ssh):
# This is what TextMate does and should fail, otherwise the issue is with TextMate mv file~ file
This failed, as it seems unable to address the ~ file when accessing it over the share....
$ mv audio.js~ audio.js mv: cannot move ‘audio.js~’ to ‘audio.js’: No such file or directory
$ ls -l audio.js~ -rwx------ 1 carpii staff 3412 Jul 1 12:19 audio.js~
$ cat audio.js~ cat: audio.js~: No such file or directory
I *think* what might be happening is that SMB is treating the audio.js~ as a mangled 8.3 character filename, like DOS used to use Not 10% sure though, as I'd expect it to do it consistently if that were the case
There's a samba config option to supposedly disable filename mangling anyway, so I'll see if that helps
Hopefully this isnt premature, but I think I've finally fixed this by tweaking smb.conf
Just leaving it here incase other people have a problem in future..
```` [accounting] case sensitive = yes
[data] mangled names = no mangle case = no
[global] preserve case = yes short preserve case = yes ````
On 1 July 2016 at 12:43, Carpii UK carpii.uk@gmail.com wrote:
When you get the error please run these tests on your Mac (not via ssh):
# This is what TextMate does and should fail, otherwise the issue is with TextMate mv file~ file
This failed, as it seems unable to address the ~ file when accessing it over the share....
$ mv audio.js~ audio.js mv: cannot move ‘audio.js~’ to ‘audio.js’: No such file or directory
$ ls -l audio.js~ -rwx------ 1 carpii staff 3412 Jul 1 12:19 audio.js~
$ cat audio.js~ cat: audio.js~: No such file or directory
I *think* what might be happening is that SMB is treating the audio.js~ as a mangled 8.3 character filename, like DOS used to use Not 10% sure though, as I'd expect it to do it consistently if that were the case
There's a samba config option to supposedly disable filename mangling anyway, so I'll see if that helps
-
Allan Odgaard -
Carpii UK -
Matthias