Rufus: [REQUEST] Add an option to automatically eject/"Safely remove" the USB stick immediately after completion.

[nnhck]

Checklist

• [x] I looked at https://github.com/pbatard/rufus/wiki/FAQ to see if my question has already been answered.
• [x] I performed a search in the issue tracker for similar issues, using keywords relevant to my problem.
• [ ] I clicked the Log button in Rufus and copy/pasted the log into the line that says <FULL LOG> below.
• [ ] The log I am copying is the FULL log, starting with the line Rufus version: x.y.z - I have NOT removed any part of it.

Additionally (if applicable):

• [ ] I ran a bad blocks check, by clicking the "bad blocks" check box in Rufus, and confirmed that my USB is not defective
• [ ] I also tried one or more of the following:
  
  
  
  • [ ] Using a different USB drive
  
  
  • [ ] Plugging the USB into a different port
  
  
  • [ ] Running Rufus on a different computer
  
  
• [ ] If using an ISO image, I clicked on the # button (at the bottom of the Rufus interface), to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.

Issue description

Add an option to automatically eject/"Safely remove" the USB stick immediately after completion.

Log

<FULL LOG>

[pbatard]

Rejected because it's not needed. After Rufus has completed its tasks, it closed all file/device access on the device, so you can remove it without going through safely eject. And if you really want, you have safely eject accessible on the taskbar. Duplicating features that are always available one click away, especially if few people are expected to have much use for it, is not a good investment of a developer's time.

[Sopor]

I was thinking this was a great idea to add a eject button into Rufus so it is possible to finish it all with one program instead of moving around to different places in Windows. If you have icons hidden in the notification bar you need to press the mouse a lot more at least 3 times to eject it. Same if you use This PC. So i think it would be great with an eject button in Rufus.
You are saying that you don't need to safely remove when you have used Rufus? What if i have enable write cache? It is also something i always do so i know i don't have to think if i'm doing it wrong or not. If i always safely remove my device i know i don't have done something that will corrupt my files.

[pbatard]

You are saying that you don't need to safely remove when you have used Rufus?

Exactly.

What if i have enable write cache?

Even then, there shouldn't be an issue (because Rufus does not simply wait to write the last file to declare that it is done, but for the volume to be closed, which makes a lot of difference in the Windows world). I have never ever received a report from anyone indicating that they got corrupted data from ejecting a drive after Rufus indicated all operations were complete, and I very much prefer to address issues that are __actually demonstrated__, rather than yet another _"I __feel__ that this may cause an issue"_. I'm sorry, but I don't address _alleged_ behaviours that people __feel__ might need to be addressed. I address real issues.

And please, be realistic:

1. If you really feel you need it, this is a feature that Windows __already__ provides. There's __very little point__ duplicating such a feature in Rufus.
2. It __is__ already easily accessible, and last time I checked, Windows did not hide the safely eject button (but regardless, it wouldn't matter). So please don't invent a false narrative to fit your request. Thank you.

[matcarfer]

You are saying that you don't need to safely remove when you have used Rufus?

Exactly.

What if i have enable write cache?

Even then, there shouldn't be an issue (because Rufus does not simply wait to write the last file to declare that it is done, but for the volume to be closed, which makes a lot of difference in the Windows world). I have never ever received a report from anyone indicating that they got corrupted data from ejecting a drive after Rufus indicated all operations were complete, and I very much prefer to address issues that are actually demonstrated, rather than yet another _"I feel that this may cause an issue"_. I'm sorry, but I don't address _alleged_ behaviours that people feel might need to be addressed. I address real issues.

And please, be realistic:

1. If you really feel you need it, this is a feature that Windows already provides. There's very little point duplicating such a feature in Rufus.
2. It is already easily accessible, and last time I checked, Windows did not hide the safely eject button (but regardless, it wouldn't matter). So please don't invent a false narrative to fit your request. Thank you.

Hi, I came here looking forward to this enhancement (to add as an toggle option), as I feel that some of us would need to get the drive automatically ejected after finalizing the drive.

The only reason I ask this is because some antivirus and audit programs start to scan the drive automatically inmediately after preparing the device, and sometimes interfering with the image in question (deleting false positives, slowing pc or blocking the drive in question). Also, I find that despite you "not having issues" disconnecting the drive without safely disconnecting, its not the correct procedure as 1 of 20 drives I prepare and take out without safely ejecting are reporting issues as in fact where used by some program on my company. Etcher for example, automatically ejects drive (not so good if you dont need it, it should be selectable) and I have no issues like described above.

And finally, ejecting the drive manually adds another step which (despite small and simple) takes more time to do it when doing a lot of drives and Windows, as for some reason takes some time to get the drive ready to detach.

Hope it gets reconsidered. Anyway, thanks for Rufus, I couldnt live without it ;)

[pbatard]

and sometimes interfering with the image in question (deleting false positives, slowing pc or blocking the drive in question)

Well, to be fair, then that is the issue of these applications, which you should report to their developers first.

Don't take it personally but, as an Open Source developer, I do get a fair share of requests for _"I have found that other software or application X (usually from a company that has A LOT of developers) is causing problem Y when it comes to my workflow, so could you please add a custom feature in Rufus to work around that problem?"_.

There are 2 major issues with that:

• Apart from very rare cases, those issues have nothing to do with the software I develop but everything to do with the other software, and also, if the user experiencing these issues was to made sure that they get reported to the developers of the software with the actual issues, then the benefit for both the person reporting them, as well as the community as a whole, is much greater than the benefit of applying a workaround in independent software. After all, Rufus is not the only bootable drive creator in town and every time someone asks me to a workaround for something external to Rufus in Rufus, I always have to wonder if that same person will also ask the win32diskimager, Win2USB and developers of all the other software that created bootable drive, for a similar feature (AFAIK, none of the software I mentioned have a "safe eject on done" feature either). I hope you can see the problem with this...
• I'm pretty confident that have A LOT fewer resources than the people who designed the other software you mention as problematic. So I'd rather if users didn't take the fact that, yes, I do try to respond to all requests being sent my way directly, possibly as opposed to the developers of that other software, as an indication that I might be more inclined to take on these kind of issues. For one thing, adding a feature is rarely "as simple" as people seem to think it is (See here) and I have no choice but to work in terms of cost/benefit. Thus, Even with what you relate above, I'm afraid that, unless someone sends me a patch with a cheat mode to safe eject a drive on done, that I can just test and apply, the cost/benefit (with the benefit aspect including the number of people that are likely to benefit) is still too high to make it worth it for the time being...

Of course, that's not to say that I may not look into adding this feature __eventually__, but I'm afraid that, even with what you describe, I can only still qualify it as "would be nice to have, even if most of it can be achieved through other means" rather than "should be added soonish".

Also, I find that despite you "not having issues" disconnecting the drive without safely disconnecting, its not the correct procedure as 1 of 20 drives I prepare and take out without safely ejecting are reporting issues as in fact where used by some program on my company.

Can you describe those issues? In case anyone wonders, I have described exactly what I experienced, and, in all my years in developing Rufus (where again, I tend to yank the drive as soon as Rufus says it's done, without going to safe eject), I can't remember a single instance where there appeared to be some corruption. Can you tell us what images you were writing? And how that corruption manifested itself?

Not that I doubt what you have seen (though I can't recall receiving e-mails or seeing issues opened for corruption due to unsafe eject... but one could probably argue that this might simply be due to people deciding that it was their fault for not using safe eject, rather than the application's). However, for me to raise the priority of that feature, then, as I mentioned above, I first need to see how beneficial it is likely to be, which means, I need to try to replicate the issue(s) if I can and get a proper idea of how frequently it is likely to be encountered by Rufus users.

[Sopor]

Etcher do have this function :)

[pbatard]

Yes, @matcarfer mentioned this explicitly and this is why I obviously didn't list Etcher in the utilities I pointed to. However, my goal is not to copy Etcher, and in this case Etcher is the exception as the point I was making was that it is realistically more costly for everyone, to ask all the boot creation utilities out there to include an "eject when done" option, rather than ask that the software that may make this option desirable in the first place to fix its problematic behaviour.

Once more, I am not saying "I'm not going to add that feature ever". However, because I must consider the cost/benefit ratio and rather than blindly copy features on account that some other software has it, I'd like to see some background with regards to the issues mentioned (so that I can evaluate them and in the process, evaluate the actual need for the workaround). And I also wouldn't mind seeing evidence that some effort was put into requesting fixes for software that interferes with safe ejection, since not having to have software interfere with Windows safe ejection when it shouldn't is the better way of dealing with those issues altogether.

[matcarfer]

Yes, @matcarfer mentioned this explicitly and this is why I obviously didn't list Etcher in the utilities I pointed to. However, my goal is not to copy Etcher, and in this case Etcher is the exception as the point I was making was that it is realistically more costly for everyone, to ask all the boot creation utilities out there to include an "eject when done" option, rather than ask that the software that may make this option desirable in the first place to fix its problematic behaviour.

Once more, I am not saying "I'm not going to add that feature ever". However, because I must consider the cost/benefit ratio and rather than blindly copy features on account that some other software has it, I'd like to see some background with regards to the issues mentioned (so that I can evaluate them and in the process, evaluate the actual need for the workaround). And I also wouldn't mind seeing evidence that some effort was put into requesting fixes for software that interferes with safe ejection, since not having to have software interfere with Windows safe ejection when it shouldn't is the better way of dealing with those issues altogether.

I fully understand everything you said. In fact, I consider this enhancement a minor treat to me and some of us, so please do not think this a demand nor soemthing that could take away time from fixing important stuff. As I said, I love Rufus, and I find it the BEST software for this type of work, period.

Etcher was just an example, and in fact only an example for ejecting after completing stuff. The size,slowness, lack of detail and bloat of the app is ridiculous and nothing like Rufus. Also we do not need to talk about Etcher at all.

Regarding the topic, two things basically: First, some software (like AV and Audit programs) love to scan and touch the drive as soon as its available, making the drive "busy" and unsafe to unplug inmediately after completing the task, even ejecting safely is slow. Of course this has nothing to do with Rufus, but it would be nice as also Second: when doing many pendrives I could "save" a little more time if the drive its already ejected.

As I said before (and I want it to make it really clear) is that it is a suggestion that I thought could take little time to implement (what do I know...I could be very wrong ;) !!!) and could help some of us. But I dont want you nor anybody to waste time on something that its time consuming nor helpfull for 99% of people.

Thanks for your very helpful posts and of course Rufus! :D

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.