Prevent system sleep during IO operations that touch (read or write) to/from the device

[missmah]

Prevent system sleep during IO operations that touch (read or write) to/from the device

[CookiePLMonster]

This is a reasonable idea so count this reply as a +1 to requests.

I'll go further - having used Rufus in the past,, I can't think of a scenario where suppressing sleep isn't desirable. I think the "increased UI clutter" argument has some merit here, so I would be in favour of just making this a default behaviour. Apps and games do this already and everyone is happy.

[pbatard]

add a generic check box for whether to prevent sleep during the process that is interacting with the device, rather than an "are you sure?" dialog.

No. Having had ample time to consider it I don't see penalizing all users with an annoying prompt that is exceedingly unlikely to apply to them, just so that a few users who should know to disable sleep when an operation is clearly going to take a long time can avoid a few clicks in going to settings and disabling sleep, as something I want to add to Rufus.

Plus, the number of requests I have received in 4 years for such a feature is exactly... 2, which doesn't strike me as high demand.

→ Rejected. Please go through the Windows sleep setting when an operation is likely to take a long time, That's what everybody does.

[missmah]

Not gonna alter the UI either for a feature that very few people will use either.
I think you would be super surprised how many people would use it..... Have you considered that you, as maintainer of the utility, may not actually be very much like most of your users? Hint: most of your users cannot even write code....

People can open new issues or e-mail. The closing comment on an issue is literally " Please open a new issue if you think you have a related problem or query." which you did, and which everyone can do. My e-mail is also plastered all over the place.

Have you met humans? Path of least resistance or bust, 99.9% of the time. You making it high resistance filters out 99.9% of the people who would have said something about it. Does not mean those people did not exist.

Similarly, not having the feature means 99.9% of people deal with it, but it does not mean they would not like or appreciate it - again, if you built the feature and analyzed it (not suggesting that, but if you did), I am confident you would have a lot of people using it.

Also, it would not be cruel to let me waste time trying to add a new UI element if you would accept the PR, it would only be cruel if you would definitely not accept it. Unless you are adding UI elements via hand-coded assembly, I am sure I could add a UI element to Rufus in my sleep.

In any event, I hope you will at least consider what I wrote, before you dismiss it.

[xiaoxiao921]

→ Rejected. Please go through the Windows sleep setting when an operation is likely to take a long time, That's what everybody does.

Absolutely no one does that.

Like CookiePLMonster said there is no scenario where you want to keep the OS behavior of going to sleep while Rufus is copying data. This is simply a bug on the software and should be fixed. I can understand not wanting to do the PR yourself or reviewing any code related to this. You're the repo owner and ultimately decide what ends up in the main branch, but not recognizing that this is an actual bug is just bizarre.

[pbatard]

https://old.reddit.com/r/Windows10/comments/m1fzyx/its_2021_why_does_windows_sleephibernate_when/

Maybe there is also a bug in Windows File Explorer then. And that is what I am referring to when I say "That's what everybody does".

I believe that at least a couple of people commenting on that thread (and others) are disproving your "Absolutely no one does that." statement.

I also have to wonder, since a lot of people here are bound to argue that it is a mere overlook of Microsoft software, if Microsoft perhaps have data that made them keep with the conscious decision of not disabling sleep during long operations (though of course, one could also argue that you wouldn't see the same usage number in long file copy operations using File Explorer and long bad blocks check operations using Rufus, in which case, what might make sense from an environmental standpoint on one hand, and might actually be guiding a conscious decision by Microsoft, might not translate to other software).

If you want to go deeper, part of my concern is also that people are bound to run bad blocks check on very large disk, over ill suited USB 2.0 connections, and leave it run for days (in the same way I see tons of people try to use Windows To Go over drives that are completely ill suited for the task), where they really should use something like SMART or something else then. Plus, I have another concern that, if we are running a bad blocks check, i.e. with a device that is suspected to behave in an erratic manner, things may go as bad as causing a Rufus crash (because I've seen bad I/O cascading into application crashes), in which case I'd rather not leave the system in a power state that's different than how it was before they used Rufus.

So, I am hearing the arguments. But I still don't see it as black and white as it is being presented by some people here.

[missmah]

A start, seems like a tractable problem to get these translations, though they may not be perfectly idiomatic:

language,symbol,text
"English","en","Prevent system sleep during active device operations?"
"Dutch","nl","Systeemslaap voorkomen tijdens actieve apparaatbewerkingen?"
"Arabic","ar","منع سكون النظام أثناء عمليات الجهاز النشطة؟"
"Italian","it","Prevenire la sospensione del sistema durante le operazioni attive del dispositivo?"
"German","de","Systemschlaf während aktivem Gerätebetrieb verhindern?"
"French","fr","Empêcher la mise en veille du système pendant les opérations actives de l'appareil ?"
"Russian","ru","Запретить спящий режим системы во время активных операций устройства?"
"Spanish","es","¿Impedir la suspensión del sistema durante las operaciones del dispositivo activo?"
"Japanese","ja","アクティブなデバイスの動作中にシステムがスリープするのを防ぎますか?"

[missmah]

No. Having had ample time to consider it I don't see penalizing all users with an annoying prompt that is exceedingly unlikely to apply to them, just so that a few users who should know to disable sleep when an operation is clearly going to take a long time can avoid a few clicks in going to settings and disabling sleep, as something I want to add to Rufus.

Did you read? No prompt. A check box, which defaults to current behavior, which people can enable to have the sane behavior.

Plus, the number of requests I have received in 4 years for such a feature is exactly... 2, which doesn't strike me as high demand.

Because you close comments so nobody can just comment on the issue! You really do not think that has a cooling effect?

→ Rejected. Please go through the Windows sleep setting when an operation is likely to take a long time, That's what everybody does.

People should not change windows power settings to use a program. It is ridiculous to expect that.

I would write better code and handle things better in a proper PR, but here is an example of how it is done in pseudo code ish impl:

struct OSSleepState
{
  bool bPreventOSSleepDuringDeviceOperations { false };
  bool bIsCurrentlyPreventingOSSleep { false };
};

static OSSleepState s_OSSleepState; // integrate me into settings
if( s_OSSleepState.bPreventOSSleepDuringDeviceOperations && (!s_OSSleepState.bIsCurrentlyPreventingOSSleep) )
{
  // Rufus Device operation is beginning. Enable away mode and prevent
  // the sleep idle time-out.
  //
 
  EXECUTION_STATE es = SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED | ES_AWAYMODE_REQUIRED);
  s_OSSleepState.bIsCurrentlyPreventingOSSleep = ( es != NULL );
}

//
// Wait until recording is complete...
//

//
// Clear EXECUTION_STATE flags to disable away mode and allow the system to idle to sleep normally.
//
SetThreadExecutionState(ES_CONTINUOUS);

[pbatard]

A check box, which defaults to current behavior, which people can enable to have the sane behavior.

Not gonna alter the UI either for a feature that very few people will use either.

Because you close comments so nobody can just comment on the issue!

People can open new issues or e-mail. The closing comment on an issue is literally " Please open a new issue if you think you have a related problem or query." which you did, and which everyone can do. My e-mail is also plastered all over the place.

I would write better code and handle things better in a proper PR

And I could be cruel and let you waste a lot of time trying to figure out how to alter the Rufus UI to add a new element, because the hard part is not the code you provided. At any rate, considering how few people are going to use this, this would be better as a cheat mode, as I certainly do not see the need for a UI element that exceedingly few people will use. But. again, seeing how few requests I have had for this, and how non blocking it is, considering that anybody can go to their sleep setting, I'm not even considering adding it as a cheat mode.

[missmah]

#define IDC_PREVENT_SLEEP 1114

CONTROL         "Prevent system sleep during active device operations?",IDC_PREVENT_SLEEP,"Button",BS_AUTOCHECKBOX | WS_TABSTOP,8,251,112,10

Then bump ICD_PROGRESS to 264

es/loc/po/sr-RS.po

Add translations to all the files like this, one for each case where IDC_BAD_BLOCKS currently exists, to cover IDC_PREVENT_SLEEP

LOC_CTRL(IDC_PREVENT_SLEEP),

s_OSSleepState.bPreventOSSleepDuringDeviceOperations = IsChecked(IDC_PREVENT_SLEEP);

etc.... a bunch of other changes, but nothing I could not do pretty quickly, I think

[pbatard]

Unless you are adding UI elements via hand-coded assembly, I am sure I could add a UI element to Rufus in my sleep.

Well, I sure wish I could add or even simply alter an existing Rufus UI elements in my sleep, because dd8314b this is what it took to simply replace one.

But hey, if you have time to waste, by all mean create a PR...

[missmah]

I don't understand the addition of MSG_351 to MSG_399 - that seems like maybe it is a change you made for future-proofing so you would not need to add more for a while? - other than that, while I agree that it is a lot of lines of code to change a UI element, though it's tractable, and I might do it if you would accept the PR. Though I definitely do not want to waste the time if you would reject the PR on principle regardless of whether it's done well or not.

[missmah]

I guess I should not have said "I do not understand" - I should have just said, it seems like that was not required to be in that PR, it was an ancillary change to bump the limit for the future, because 349 was getting close to the limit?

[pbatard]

I will reject the PR since I disagree with your assumption that people who cared about this feature chose not to voice it. I just haven't seen enough of a demand for it in 4 years, and going on "Oh but there is a demand, it just wasn't voiced to you" from a party that has an obvious vested interest simply won't cut it.

And again, the settings to disable sleep is just a couple clicks away, so it's not like not having this feature in Rufus is a showstopper for anyone.

[missmah]

The OS setting is not intended to be (ab)used that way. I do not want my computer to not sleep for a week after I start a Rufus USB write operation and go on vacation. I want it to not sleep until that operation is done, and then sleep for the remainder of the week. Your opinion here is disregarding quality in this particular instance.

Also, you said only two people cared in all those years, but there was already a thumbs up on my post from someone I have never met within less than an hour (?) of me posting it? So that is a clear indication that you are wrong that there is virtually no demand and you would hear about it if there was demand.

You are right that I have a bias due to my vested interest and as such, I may overestimate how much interest, but you definitely also underestimate it.

Anyway, it is your project, so what can I do? Fork it, I guess. But your loss, I am darned good at this kind of thing, and you just kind of burned my care and affection for your project :/

[missmah]

I do still thank you for making Rufus, good software that I am grateful exists.

And, I even understand not wanting to do the work of reviewing a PR - it's all work, and reviewing code is not all that fun.

But just a bit disappointed that your response was to reject this on the premise of "not a useful feature" rather than "I do not really have the bandwidth to PR" - maybe those are the same thing in the end, but I think expressing that you are too busy would hit a lot better than that there is no value.

[pbatard]

I'm not too busy. From where I stand as the developer of the application I do not see adding an extra UI entry from a feature that I assure you will be of next to no use to 99.99% of people using Rufus, as something that will actually be beneficial.

My decision is based on more than 10 years of experience sieving through requests and comments from users (and no I don't wait for people to contact me -- I'm very much looking at social media and user forums as well) to derive features that I estimate will benefit more than a handful of users. And I believe the relative popularity of Rufus derives in part from the fact that I am very conscious about feature creep and make a very concerted effort to review features from a standpoint of the majority of users, rather than the minority that screams loudest.

All this to say that I do not see value for the vast majority of users in your proposal period. You are free to disagree with this as much as you want, but as long as I am the designer of the application, you're just going to have to accept it, or fork your own version.

[missmah]

If a cop runs a red light, that doesn't change a judge's opinion on whether to uphold a ticket when you or I run a red light.

Windows Shell and Windows File explorer have some obvious bugs and clearly wrong behavior. The answer is usually not because it's the right thing to do. The answer is usually a combination of legacy and other, often worse reasons (sometimes as bad as "if we even just recompile X, or change it by one byte, Y will break, so we are stuck supporting X forever.")

https://twitter.com/SheriefFYI/status/1778502664151539894?t=ND_vLWOBx5eEbebQdW9_0w&s=19