[TxMt] lost work when editing over an AFP share

[Eric O'Brien]

On Jul 21, 2007, at 4:19 AM, Allan Odgaard wrote:

> On 21. Jul 2007, at 05:26, Matt Anderson wrote:
>
>> [...]
>> Obviously, there seems to have been some IO issue due to the  
>> network connection being interrupted, and/or the remote server  
>> going to sleep.  Can someone explain what (the deeper / more  
>> specific the technical detail the better) it is? A likely sequence  
>> of events, consistent with what I described, that would cause this  
>> result?  Can it be considered a bug that TextMate doesn't react to  
>> this kind of issue, and a file gets silently truncated on the  
>> remote server?
>
> I’ve heard of incidents where a program initiates a save over AFP,  
> the remote host first truncates the file (i.e. overwrites the file  
> node), but then the connection dies after that -- in these cases  
> the program saving the file is normally stuck with a busy wheel.  
> Might be there is a timeout.

Even so, I wonder if the file as it existed before the connection  
went down is hidden away in whatever is used for the temporary folder.

>
> One sort of fix for that problem is to enable ‘Perform atomic  
> saves’ in Preferences → Advanced. This will write a new file  
> first, then “swap” it with the old, when succesful. So in case  
> the connection dies before the file is fully saved, the old file  
> should not be lost.
>
> When saving a file, the system reports success/error, and only in  
> the case of a reported success, will TextMate indicate that the  
> file is now saved. So in your case, it’s a system bug, that  
> success was reported, for a save-operation which failed.