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.