Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On 24 February 2008 14:13, Dave Korn wrote: On 23 February 2008 21:51, Dave Korn wrote: The solution has two parts then: And here is part 1. No comments then? I'll apply it sometime tonight or tomorrow if nobody objects. Meanwhile (here's the RFC part), my suggestion for part 2 is attached (merged into part 1). It's pretty crude: it disables and reenables the cancel button around each call to Installer::installOne(). This probably doesn't stop the user from pressing the cancel key or clicking the X close box, although I haven't tested that yet. I would be interested in hearing from anyone who reckons they do know the proper way to do this. cheers, DaveK -- Can't think of a witty .sigline today setup-modal-dialogs-patch-2.diff Description: Binary data
Re: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
Dave Korn wrote: And here is part 1. No comments then? I'll apply it sometime tonight or tomorrow if nobody objects. Well, you labeled it as part 1 and so I mentally said, okay, I'll take a look at this whenever it's complete. Meanwhile (here's the RFC part), my suggestion for part 2 is attached (merged into part 1). It's pretty crude: it disables and reenables the cancel button around each call to Installer::installOne(). This probably doesn't stop the user from pressing the cancel key or clicking the X close box, although I haven't tested that yet. I would be interested in hearing from anyone who reckons they do know the proper way to do this. Ick. I don't really like that. It seems to me that we simply don't support canceling in any sane way once the installation step has begun. Even if we are able to cancel cleanly at a point in between unpacking two packages, that still could leave the system in a horrid state -- missing dependencies, postinstalls not run, etc. We should disable the button for the entirety. Brian
RE: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On 26 February 2008 13:59, Brian Dessent wrote: Dave Korn wrote: And here is part 1. No comments then? I'll apply it sometime tonight or tomorrow if nobody objects. Well, you labeled it as part 1 and so I mentally said, okay, I'll take a look at this whenever it's complete. Ah, no, I intended to break out and submit the separate parts of the patch incrementally, sorry for any confusion. Meanwhile (here's the RFC part), my suggestion for part 2 is attached (merged into part 1). It's pretty crude: it disables and reenables the cancel button around each call to Installer::installOne(). This probably doesn't stop the user from pressing the cancel key or clicking the X close box, although I haven't tested that yet. I would be interested in hearing from anyone who reckons they do know the proper way to do this. Ick. I don't really like that. Just the reason why I wanted to keep the uncontroversial bits separate from the more obviously-correct bits! It seems to me that we simply don't support canceling in any sane way once the installation step has begun. Even if we are able to cancel cleanly at a point in between unpacking two packages, that still could leave the system in a horrid state -- missing dependencies, postinstalls not run, etc. We should disable the button for the entirety. Right, I'll rework part 2 on that approach. Meanwhile, part 1 OK for trunk? cheers, DaveK -- Can't think of a witty .sigline today
Re: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On Tue, 26 Feb 2008, Brian Dessent wrote: Dave Korn wrote: And here is part 1. No comments then? I'll apply it sometime tonight or tomorrow if nobody objects. Well, you labeled it as part 1 and so I mentally said, okay, I'll take a look at this whenever it's complete. Meanwhile (here's the RFC part), my suggestion for part 2 is attached (merged into part 1). It's pretty crude: it disables and reenables the cancel button around each call to Installer::installOne(). This probably doesn't stop the user from pressing the cancel key or clicking the X close box, although I haven't tested that yet. I would be interested in hearing from anyone who reckons they do know the proper way to do this. Ick. I don't really like that. It seems to me that we simply don't support canceling in any sane way once the installation step has begun. Even if we are able to cancel cleanly at a point in between unpacking two packages, that still could leave the system in a horrid state -- missing dependencies, postinstalls not run, etc. We should disable the button for the entirety. I don't like Dave's proposal either. However, simply disabling the Cancel button altogether is not the solution -- if the user is unable to interrupt the installation, she will just kill the process, with disastrous results. The question is: what kind of behavior do we really want in case of cancellation? If we want setup to stop whatever it's doing (dependences, etc, aside), but be able to resume at a later point to fix the state of the system, then Dave's part 1 is the right approach. If we want setup to always leave the system in a sane state, even when it's interrupted, then we should capture the exit message and figure out how to clean up the missing dependences. Keep in mind that processes can be killed in a way that isn't capturable, so setup *will* leave corrupt listing files and missing dependences in some cases. Making sure setup does not crash when restarted after such cases is probably the best we can do. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it. -- Rabbi Hillel
Re: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
Dave Korn wrote: Meanwhile, part 1 OK for trunk? Yes, I think making that dialog modal is good. Igor Peshansky wrote: I don't like Dave's proposal either. However, simply disabling the Cancel button altogether is not the solution -- if the user is unable to interrupt the installation, she will just kill the process, with disastrous results. Yes, but there will always be a way for the user to shoot themselves in the foot. The best we can do is try to make it harder to find the bullets. Right now it's quite easy to get into trouble since we allow arbitrarily stopping the install at any point. I think disabling the Cancel button (and the close 'X' button) for the entire install phase does put us at a better place than we're at now. Even if they look up the PID of setup and kill it that way, it's still no worse than what we have now. The sad fact is that we don't truly support canceling in any sane form, so we shouldn't advertise that ability in the UI. The fact that you can usually repair things by just rerunning setup (and especially so now that a corrupt .lst doesn't kill the party) is good, but it doesn't mean we should rely on this. To really do this right (e.g. how MSI can rollback to the starting state midway through a aborted install) is a tremendous amount of work that I don't think anyone here is prepared to take on. Brian
RE: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On 26 February 2008 14:55, Igor Peshansky wrote: The question is: what kind of behavior do we really want in case of cancellation? If we want setup to stop whatever it's doing (dependences, etc, aside), but be able to resume at a later point to fix the state of the system, then Dave's part 1 is the right approach. If we want setup to always leave the system in a sane state, even when it's interrupted, then we should capture the exit message and figure out how to clean up the missing dependences. You've somewhat missed the point. The justification for part 1 is that, entirely orthogonal to and regardless of whatever else we do, those dialog boxes should be modal and they aren't. It Is Just Plain Wrong. It is a fortuitous side-effect of making them correctly modal that it becomes slightly trickier to accidentally cancel an installation when you thought you were just cancelling an individual pop-up request. cheers, DaveK -- Can't think of a witty .sigline today
RE: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On 26 February 2008 15:24, Brian Dessent wrote: Dave Korn wrote: Meanwhile, part 1 OK for trunk? Yes, I think making that dialog modal is good. Thanks, will commit at a convenient moment. Igor Peshansky wrote: I don't like Dave's proposal either. However, simply disabling the Cancel button altogether is not the solution -- if the user is unable to interrupt the installation, she will just kill the process, with disastrous results. Yes, but there will always be a way for the user to shoot themselves in the foot. The best we can do is try to make it harder to find the bullets. Hear hear. I'm just focussed on helping the end-users avoid trouble to make the package friendlier. Right now it's quite easy to get into trouble since we allow arbitrarily stopping the install at any point. I think disabling the Cancel button (and the close 'X' button) for the entire install phase does put us at a better place than we're at now. Even if they look up the PID of setup and kill it that way, it's still no worse than what we have now. Anyone who's clever enough to attach a debugger to it, I don't need to help. The sad fact is that we don't truly support canceling in any sane form, so we shouldn't advertise that ability in the UI. Ditto. I just want to help people avoid unexpected consequences of what might seem like reasonable actions. cheers, DaveK -- Can't think of a witty .sigline today
RE: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On Tue, 26 Feb 2008, Dave Korn wrote: On 26 February 2008 14:55, Igor Peshansky wrote: The question is: what kind of behavior do we really want in case of cancellation? If we want setup to stop whatever it's doing (dependences, etc, aside), but be able to resume at a later point to fix the state of the system, then Dave's part 1 is the right approach. If we want setup to always leave the system in a sane state, even when it's interrupted, then we should capture the exit message and figure out how to clean up the missing dependences. You've somewhat missed the point. The justification for part 1 is that, entirely orthogonal to and regardless of whatever else we do, those dialog boxes should be modal and they aren't. It Is Just Plain Wrong. Sorry, I misspoke (mis-wrote?). I meant to say that your part 1 takes us towards that goal. Also, in my morning confusion, I referred to the fix for the corrupt lst.gz files as your part 1. There is no question that both were the right thing to do. It is a fortuitous side-effect of making them correctly modal that it becomes slightly trickier to accidentally cancel an installation when you thought you were just cancelling an individual pop-up request. An alternative would be to pop up a warning box on Cancel that says that this action may leave the system in an unstable state, and are you sure you want to cancel?. I'd still like to have the ability to cancel a long install (preferably with the ability to fix things later by rerunning setup). Incidentally, we already get an incremental install from the way setup is structured -- it will not re-download packages, and will rerun any postinstall scripts remaining from the previous run. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it. -- Rabbi Hillel
Re: Ping? + RFC [was RE: Setup.exe vs corrupt lst.gz files.]
On Tue, 2008-02-26 at 07:24 -0800, Brian Dessent wrote: To really do this right (e.g. how MSI can rollback to the starting state midway through a aborted install) is a tremendous amount of work that I don't think anyone here is prepared to take on. FWIW this is why I started porting dpkg to cygwin, way back when - it was with the intent of getting a transaction packaging system without writing one from scratch. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
RE: Setup.exe vs corrupt lst.gz files.
On 23 February 2008 21:51, Dave Korn wrote: Yes, I see, the dialog isn't modal and so it allows the 'X' which is effectively the same as cancelling. The solution has two parts then: 1) make the pop-up modal so the user can't mess with the app's main window while answering the question, and 2) make sure clicking 'cancel' or 'X' while in the middle of installing anyway close down gracefully. Part 1 I've already figured out. And here is part 1. The problem is that calling MessageBox (NULL, ...) to modally block the main dialog window can only work when you're running from that window's main message thread; otherwise windoze has no idea which window you might be referring to. The install code runs in a separate thread, so the trivial solution is to pass in the HWND for the main dialog (which it has available from the thread startup context arguments) and specify it explicitly as the owner in MessageBox calls, and that's what this patch does. 2008-02-24 Dave Korn [EMAIL PROTECTED] * install.cc (Installer::installOne): Accept new HWND argument from caller and pass it to MessageBox calls so that MB_TASKMODAL can work. (check_for_old_cygwin): Likewise. (do_install_thread): Pass owner's HWND (from thread context) when calling them. cheers, DaveK -- Can't think of a witty .sigline today setup-modal-dialogs-patch.diff Description: Binary data
Re: Setup.exe vs corrupt lst.gz files.
Dave Korn wrote: After a little more testing, and unless anyone yells, I intend to apply this patch later tonight to catch the infamous corrupt lst.gz file crash in current setup.exe. Thanks for looking at this, but that's really only solving half of the problem. The other half is that we generate one of these bogus .lst.gz files while installing a package if the user is prompted to retry an in-use file and clicks the close-X in the dialog instead of chosing retry or replace. But go ahead and commit this. Brian
RE: Setup.exe vs corrupt lst.gz files.
On 23 February 2008 18:50, Brian Dessent wrote: Thanks for looking at this, but that's really only solving half of the problem. The other half is that we generate one of these bogus .lst.gz files while installing a package if the user is prompted to retry an in-use file and clicks the close-X in the dialog instead of chosing retry or replace. I'll get to that next :) This is just to be nice to any users who have already got one of these files (or corrupted it by any other means). cheers, DaveK -- Can't think of a witty .sigline today
Re: Setup.exe vs corrupt lst.gz files.
On Sat, Feb 23, 2008 at 06:54:19PM -, Dave Korn wrote: On 23 February 2008 18:50, Brian Dessent wrote: Thanks for looking at this, but that's really only solving half of the problem. The other half is that we generate one of these bogus .lst.gz files while installing a package if the user is prompted to retry an in-use file and clicks the close-X in the dialog instead of chosing retry or replace. I'll get to that next :) This is just to be nice to any users who have already got one of these files (or corrupted it by any other means). Thanks for doing this. I think this bug may be near the top of the list for why everyone thinks cygwin's setup.exe sucks. cgf
RE: Setup.exe vs corrupt lst.gz files.
On 23 February 2008 18:50, Brian Dessent wrote: problem. The other half is that we generate one of these bogus .lst.gz files while installing a package if the user is prompted to retry an in-use file and clicks the close-X in the dialog instead of chosing retry or replace. Need a bit of clarification here: I could only get this to happen by clicking the X on the main setup.exe dialog behind, not the popup warning itself; I take it that's what you meant. cheers, DaveK -- Can't think of a witty .sigline today
RE: Setup.exe vs corrupt lst.gz files.
On Sat, 23 Feb 2008, Dave Korn wrote: On 23 February 2008 18:50, Brian Dessent wrote: problem. The other half is that we generate one of these bogus .lst.gz files while installing a package if the user is prompted to retry an in-use file and clicks the close-X in the dialog instead of chosing retry or replace. Need a bit of clarification here: I could only get this to happen by clicking the X on the main setup.exe dialog behind, not the popup warning itself; I take it that's what you meant. You'd also get that if you press Cancel in the main dialog while the package is being installed. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it. -- Rabbi Hillel
RE: Setup.exe vs corrupt lst.gz files.
On 23 February 2008 21:23, Igor Peshansky wrote: On Sat, 23 Feb 2008, Dave Korn wrote: On 23 February 2008 18:50, Brian Dessent wrote: problem. The other half is that we generate one of these bogus .lst.gz files while installing a package if the user is prompted to retry an in-use file and clicks the close-X in the dialog instead of chosing retry or replace. Need a bit of clarification here: I could only get this to happen by clicking the X on the main setup.exe dialog behind, not the popup warning itself; I take it that's what you meant. You'd also get that if you press Cancel in the main dialog while the package is being installed. Yes, I see, the dialog isn't modal and so it allows the 'X' which is effectively the same as cancelling. The solution has two parts then: 1) make the pop-up modal so the user can't mess with the app's main window while answering the question, and 2) make sure clicking 'cancel' or 'X' while in the middle of installing anyway close down gracefully. Part 1 I've already figured out. cheers, DaveK -- Can't think of a witty .sigline today
