I'm not sure if this is a TextMate bug, or something else, but oh is it very, very irritating. I'm not sure what/why this happened, but I'm hoping someone here (Allan? or anyone?) might be able to explain it.
I was running TextMate on computer A, editing a file accessed through an AFP share on computer B. Computer B at some point got put to sleep (lid of laptop was closed), and when that happened, the file was in need of saving. A "lost connection with server, disconnect?" dialog did come up. I woke computer B from sleep, and the dialog went away by itself. Then I tried to save the buffer. TextMate conjured a spinning beach ball for a time (1-2 minutes or so), after which it appeared the file had been saved. No errors were reported, and the 'needs saving dot' in the red close button, upper left hand corner, had gone away. Thinking it was in fact saved, I closed the window, and TextMate did not complain.
Then, when I (immediately after) tried to open the file back up, I found it to be empty. The file had definitely been saved many times as it was edited -- the time after the hiccup certainly wasn't the first.
I lost like 6 hours of work.
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?
Thanks...
-- Matt Anderson
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.
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.
-
Allan Odgaard -
Eric O'Brien -
Matt Anderson