[TxMt] Re: disable atomic saves?

[Carpii UK]

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 at 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 at lists.macromates.com
> http://lists.macromates.com/listinfo/textmate
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macromates.com/textmate/attachments/20160605/1564b152/attachment.html>