Thread: File not completely saved when Save is interrupted by quit
Cream is a free, easy-to-use configuration of the Vim text editor
Brought to you by:
digitect
From: Ben A. <BAr...@dy...> - 2006-07-04 13:38:00
|
Three of my users have experienced total or partial loss of their files when they performed these actions: 1. Click the "save" icon 2. Immediately afterwards, close Cream by clicking on the close widget (X) on the titlebar - A dialog box appears: "Save changes to <filename>. [Yes] [No] [Cancel]" 3a. If you press "Yes" or "Cancel", the file is properly saved. 3b. If you press "No", the file is partially saved. Depending on the timing of step 2, you may even be left with no file as a result of 3b. People may not notice this problem at all unless, like us, they are editing files on a slow filesystem (e.g. a network fileshare). Peter suggested to me a possible solution: "Save should set a flag when it starts so that the ['do you want to save" dialog from x=close program] can auto answer a Yes." Ben |
From: Ben A. <BAr...@dy...> - 2006-07-04 14:01:22
|
Stephen Stagg wrote: > I don't know much about cream/vim config but shouldn't the app check to make > sure that all current write operations have completed before exiting?, > whatever the state of the save confirmation dialog. I would have thought > that this would be a more robust solution. > I would have thought so too. I've just confirmed that this is reproducible in gvim 7 without Cream, so the problem still exists in the latest and greatest. I'm off to check the bug tracking system for vim ... Ben |
From: Lodewijk O. <lp...@xs...> - 2006-07-04 14:01:49
|
Ben Armstrong wrote on 4-7-2006 15:37: > Three of my users have experienced total or partial loss of their > files when they performed these actions: > > 1. Click the "save" icon > 2. Immediately afterwards, close Cream by > clicking on the close widget (X) on the titlebar > - A dialog box appears: "Save changes to <filename>. [Yes] [No] > [Cancel]" > 3a. If you press "Yes" or "Cancel", the file is properly > saved. > 3b. If you press "No", the file is partially saved. > > Depending on the timing of step 2, you may even be left with no file > as a result of 3b. > > People may not notice this problem at all unless, like us, they are > editing files on a slow filesystem (e.g. a network fileshare). > > Peter suggested to me a possible solution: "Save should set a flag > when it starts so that the ['do you want to save" dialog from x=close > program] can auto answer a Yes." On several occasions I did have a similar/comparable problem. Using the latest Cream on Windows XP Professional, after saving with the "save" icon, and then closing Cream by the Menu -> File -> Exit, Cream or Vim 7.0 did crash, asking me to report this error to Microsoft (which I did of course ;-) and they still haven't come up with a solution :-D ). The files were saved properly. But a crash is not a nice thing on the exit of a program. The problem cannot be repeated by me on purpose, it happens one time, and it will not happen the next time and thereafter it will occur again quite unexpectedly. I suppose my file system is _not_ slow. And I have no idea what causes the crash. Perhaps I can make someone happy with a dump of some kind, but one has to tell me how to get this information. |
From: Steve H. <dig...@mi...> - 2006-07-05 11:45:46
|
On Tue, 2006-07-04 at 16:01 +0200, Lodewijk Otto wrote: > > On several occasions I did have a similar/comparable problem. > > Using the latest Cream on Windows XP Professional, after saving with > the "save" icon, and then closing Cream by the Menu -> File -> Exit, > Cream or Vim 7.0 did crash, asking me to report this error to > Microsoft (which I did of course ;-) and they still haven't come up > with a solution :-D ). > > The files were saved properly. But a crash is not a nice thing on > the exit of a program. The problem cannot be repeated by me on > purpose, it happens one time, and it will not happen the next time > and thereafter it will occur again quite unexpectedly. > > I suppose my file system is _not_ slow. And I have no idea what > causes the crash. Perhaps I can make someone happy with a dump of > some kind, but one has to tell me how to get this information. Probably the best approach would be to set 'verbosefile to something unique: execute "set verbosefile=".g:cream_user."debug-".localtime().'.txt' and then use :verbose (maybe preceded by silent) in front of the various commands potentially involved in the crash, for starters all the commands within the cream-lib Saving, Close, and Exit folds. I'll see if I can't work out a devel option for this, it sure would be useful from time to time. -- Steve Hall [ digitect dancingpaper com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: Steve H. <dig...@mi...> - 2006-07-05 03:04:11
|
On Tue, 2006-07-04 at 11:00 -0300, Ben Armstrong wrote: > Stephen Stagg wrote: > > I don't know much about cream/vim config but shouldn't the app > > check to make sure that all current write operations have > > completed before exiting?, whatever the state of the save > > confirmation dialog. I would have thought that this would be a > > more robust solution. > > I would have thought so too. I've just confirmed that this is > reproducible in gvim 7 without Cream, so the problem still exists in > the latest and greatest. I'm off to check the bug tracking system > for vim ... The "only" bug tracking system for Vim is it's author. Best results are obtained by mailing bu...@vi..., and describing the steps to a sure crash without using any startup scripts: gvim -u NONE -U NONE -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: Ben A. <BAr...@dy...> - 2006-07-05 12:31:49
|
Steve Hall wrote: > The "only" bug tracking system for Vim is it's author. Best results > are obtained by mailing bu...@vi..., and describing the steps to a > sure crash without using any startup scripts: > > gvim -u NONE -U NONE > > I had forgotten they have no bug tracking system. Frustrating. I would like to know if anyone else has had this problem before or not. Ben |
From: Steve H. <dig...@mi...> - 2006-07-05 03:38:24
|
On Tue, 2006-07-04 at 10:37 -0300, Ben Armstrong wrote: > Three of my users have experienced total or partial loss of their > files when they performed these actions: > > 1. Click the "save" icon > 2. Immediately afterwards, close Cream by clicking on the close > widget (X) on the titlebar > - A dialog box appears: "Save changes to <filename>. [Yes] [No] > [Cancel]" > 3a. If you press "Yes" or "Cancel", the file is properly saved. > 3b. If you press "No", the file is partially saved. > > Depending on the timing of step 2, you may even be left with no file > as a result of 3b. > > People may not notice this problem at all unless, like us, they are > editing files on a slow filesystem (e.g. a network fileshare). I'll give this a test tomorrow over a network, can't seem to reproduce it on a local file. > Peter suggested to me a possible solution: "Save should set a flag > when it starts so that the ['do you want to save" dialog from > x=close program] can auto answer a Yes." The thing is, you shouldn't get the dialog if the initial save worked, Cream only prompts if there are unsaved files. (The bug is that the user picked "No". :) It's just responding to conditions, Cream relies entirely on Vim for I/O. I'll hazard a guess at what could be happening: 1. User presses Save icon (or Ctrl+S) 2. Vim goes to save the file (:write) ... 3. User presses Window Manager "X" button. 4. Window manager tries to kill off program, sends signal to Vim. 5. Vim processes Cream autocmd to prompt user to save unsaved files. 6. User presses "No" 7. ...Vim has still not finished saving the buffer back to disk from #2! 8. Vim responds to user's "No" and proceeds through the autocmd function, which ends at a :qall! command. 9. This :qall! somehow takes priority over the ongoing :write which is aborted mid-stream leaving file fragments. I think this is a Vim bug, it should manage it's buffer save and I/O process and hang until complete. Perhaps it is being too polite to the window manager? I don't see how a function or autocmd is able to continue in the background of a :write process, that should be sacred. Can you reproduce this in plain gVim with a big buffer? -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: Ben A. <BAr...@dy...> - 2006-07-05 12:30:24
|
Steve Hall wrote: > I'll give this a test tomorrow over a network, can't seem to reproduce > it on a local file. Right. And depending on the speed of the network, you may still have trouble. You could try making the file Very Large as I did in my tests, and/or put a sufficient amount of load on either of the systems involved so that the save takes long enough to observe the problem. > The thing is, you shouldn't get the dialog if the initial save worked, > Cream only prompts if there are unsaved files. (The bug is that the > user picked "No". :) It's just responding to conditions, Cream relies > entirely on Vim for I/O. > I see. > I'll hazard a guess at what could be happening: > > 1. User presses Save icon (or Ctrl+S) > 2. Vim goes to save the file (:write) ... > 3. User presses Window Manager "X" button. > 4. Window manager tries to kill off program, sends signal to Vim. > 5. Vim processes Cream autocmd to prompt user to save unsaved files. > 6. User presses "No" > 7. ...Vim has still not finished saving the buffer back to disk from > #2! > 8. Vim responds to user's "No" and proceeds through the autocmd > function, which ends at a :qall! command. > 9. This :qall! somehow takes priority over the ongoing :write which > is aborted mid-stream leaving file fragments. > Sounds about right. > I think this is a Vim bug, it should manage it's buffer save and I/O > process and hang until complete. Perhaps it is being too polite to the > window manager? I don't see how a function or autocmd is able to > continue in the background of a :write process, that should be sacred. > I agree. That write must finish, barring an absolute catastrophe, such as running out of disk space. Ben |