[TxMt] lost work when editing over an AFP share

[Allan Odgaard]

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.

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.