Device scanning fails to find USB drive

[jtwill]

Device scanning fails to find USB drive

[pbatard]

Thanks for the report, I'll look into it.

In the meantime, can you install DebugView from http://technet.microsoft.com/en-us/sysinternals/bb896647 and see if it reports anything suspicious? Please feel free to also e-mail me the log you get from DebugView, as it may tell what the issue is.

[jtwill]

On Fri, Jan 20, 2012 at 7:39 AM, Pete Batard
[email protected]
wrote:

Thanks for the report, I'll look into it.

In the meantime, can you install DebugView from http://technet.microsoft.com/en-us/sysinternals/bb896647 and see if it reports anything suspicious? Please feel free to also e-mail me the log you get from DebugView, as it may tell what the issue is.

I'll do that. In the meantime, can you add a checkbox "list all
drives" that will allow me to choose any drive on the system, instead
of trying to figure out which drives may be USB drives and just
listing those? That way maybe we can figure out what is wrong with
your technique for determining which drives are USB drives. Only your
program has this issue. All the other USB writing programs I have
tried work just fine.

[pbatard]

I've considered optionally listing all drives, but I think the option is too dangerous for regular joes, who may inadvertently end up formatting one of their HDD partitions, and will be a lot more annoyed with the loss of their data than people who don't see their drive listed. Therefore, I'd rather fix the USB detection instead.

Also, since Rufus follows very closely what the HP utility does for drive listing, can you tell me if the HPUSBFW executable has the same issue?
You can obtain a copy of HPUSBFW in: http://akeo.googlecode.com/files/USB_DOS.7z

[jtwill]

On Fri, Jan 20, 2012 at 8:05 AM, Pete Batard
[email protected]
wrote:

I've considered optionally listing all drives, but I think the option is too dangerous for regular joes, who may inadvertently end up formatting one of their HDD partitions, and will be a lot more annoyed with the loss of their data than people who don't see their drive listed. Therefore, I'd rather fix the USB detection instead.

That's a terrible attitude. The users are complete idiots and must be
protected from themselves, even at the expense of not allowing some
people to use the software at all. I'm reconsidering whether I want to
help you debug your software, or even use it at all.

The proper attitude is to provide functionality that allows users to
make use of the software, but insert adequate warnings where
necessary. Let me know if you ever come to understand this.

[pbatard]

Let us consider grandma Jones.

Lately, grandma, who has had her PC installed by her grandson, has been experiencing stability issues that seem to be tied to hardware incompatibility. As she mostly uses her computer for e-mail, the occasional browsing and to send/recieve photos of her grandsons and granddaughters, her machine is not one of the the latest PCs but secondhand machine. Her grandson looked into the issue and discovered that there exists a BIOS update from the manufacturer that seemed to be aimed exactly at fixing the symptoms she experiences. However, that BIOS update is delivered as a DOS program only (old machine) and since he's in college/at work at the other end of the country, he can't do the upgrade himself for some time.
Still, he's heard about this neat little program called Rufus, that should be able help grandma Jones create a DOS bootable US drive, and he knows she has an USB key, so he e-mails some instructions to her.

And there we have grandma Jones, running Rufus, with her USB drive plugged in, but for some reason (maybe she has two optical drives, who knows...) she can't see it. She's rather annoyed and confused, so she's looking around because her grandson implied it would be fairly easy. Maybe the checkbox that says "list all drives" will do it? Seems like it, because now she can see a "Data (D:)" entry in the GUI. Sure, she got warnings when checking the "list all drives" box, but her grandson said she would get warnings, so she didn't make much of anything about them. Besides, the USB drive is branded "ADATA" (which is a well known USB keys brand) and the list says "DATA", so how could that not be the same?

Of course, unbeknownst to grandma, the ADATA USB drive is not D: at all, but is listed further down in the list that she didn't open. Instead D: is the partition that stores some of her photos, documents and programs, because her grandson thought it may be safer to store data separately for OS reinstallation. But it's too late to worry about that now, because grandma Jones has just initiated the formatting, after dismissing the second warning ("He said there would be warnings, right?").

Congratulations, you've just caused grandma Jones to lose some very valuable data!

I hope, then, that you can understand that a developer's attitude is to envision the kind of scenarios above and consider not just the benefits but also the drawbacks a feature has across all users, and cater for more than a select group of individuals... As you indicated, it's very easy for an individual to indicate what they want. What's more difficult is to balance what a larger group of people will want, and I doubt grandma Jones would want the "list all drives" feature at all if she had any awareness of the risks it may put her data through. So, yes, sometimes developers have to make decisions that are for the benefit of more than just an individual, even if said individual thinks it as either a snotty attitude and blatant ignorance of their pleas.

Now, if you want to just brush off the scenario above as a remove fantasy, let me give you some more facts:

• Rufus aims at catering at USB drives only. The first U in its name stands for USB. If the plan was to handle fixed drive, it would use a different name and tagline, so, at least for me, the established objective of Rufus is pretty clear, and it does not encompass fixed drives at all.
• I have made absolutely no secret that Rufus was aimed tat filling the same function as the HPUSBFW utility. See http://pete.akeo.ie/2011/12/rufus-dos-bootable-usb-formatting.html. Seeing that The HPUSBFW only deals with USB drives, Rufus does exactly the same. It's not because it borrows the skin of the Windows formatting utility that it should behave the same. The reason the UI is similar is also because I thought it would be more familiar for inexperienced users.
• Finally, there is very little point in duplicating features, such as formatting fixed drives, that Windows already provides. The goal is to create bootable DOS drives, and I don't envision many scenarios where you'll want to format a fixed drive to make it DOS bootable. Therefore, if you want to work with fixed drives, it doesn't make sense to use Rufus and possibly put your data at risk as a result.

So there you have it. If seeing that a free program does not implement the feature you request angers you, because the developer considered not to be in the best interest of the program users as a whole, you're free to post all the negative reviews you want. But you should understand that developers have a whole community of users to consider, and that what benefits the many will always trump what benefits the one. I'd much rather deal with an angry user, but who hasn't lost any data because of my application, than one who has.

[jtwill]

[Long absurd justification for treating users like idiots snipped]

Wow, you are worse than I thought. Not only do you arrogantly believe
computer users are complete morons, you assume you have to take
responsibility for them and force them to do what you think they
should do.

If you ever grow up and realize that software should allow users
choices and provide warnings where necessary, then I might consider
helping you debug this piece of shit. Until then, I will continue
using software that actually works and does not treat users like
morons.

[AlessandroMenti]

Not sure if it's the same bug, although the symptoms are exactly the same.

Rufus does not detect my USB device as well. I ran DebugView and the HP USB Disk Storage Format Tool - this is the DebugView output:

[5068] *** RUFUS INIT *** 
[5068] SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E 
[5068] FreeDOS resources are embedded with this app 
[5068] Found drive 'SanDisk Cruzer USB Device' 
[5068] IOCTL_DISK_GET_DRIVE_GEOMETRY_EX failed: [0x00000015] Device not ready. 
[5068] SetLGP: Successfully removed NoDriveTypeAutorun policy key 
[5068] *** RUFUS EXIT *** 

The HP tool detects the USB drive, instead.

I suspect that the bug is caused by my unusual disk configuration:
Disk 0 (233 GiB)

• 207 GiB NTFS active primary partition (mounted as C:)
• 22 GiB Ext4 primary partition (not mounted)
• 4 GiB Linux swap logical partition (not mounted)
  Disk 1 (4 GiB, USB key)
• Single primary partition, mounted as G:
  CD-ROM 0 (empty, physical CD-ROM reader)
  CD-ROM 1 (empty, virtual CD-ROM reader created with Virtual CloneDrive, assigned letter: E:)

While running Rufus, I noticed that it detected the drive correctly (the DebugView output shows that), but it picks up the wrong physical device (in its main window, it shows "NO_LABEL (E:)" in the "Device" list box).

Let me know if I may be of further help.

[pbatard]

Thanks for the detailed report!

I have just installed Virtual CloneDrive and I am now able to reproduce the issue. I should be able to do something about it.

I'll provide an update on the fix when I have one. Thanks again for the report.

[pbatard]

Rufus v1.0.7, which I just made available at https://github.com/pbatard/rufus/downloads should fix the issue.
Can you please test it and let me know if you still encounter a problem?

Note that, due to the nature of github, the issue will be automatically closed when I push the fix in the source (which I will do in a few hours), so, you may have to open a new bug report if you find that it still doesn't work.

For a full technical explanation, the problem was due to the fact that, because we locate USB drives in 2 passes to be able to access all of its properties, Rufus has to invoke IOCTL_STORAGE_GET_DEVICE_NUMBER during the second pass to try to match a device number with the drive index that was identified with pass 1. However, the second pass is also a more generic one, and device numbers are not guaranteed to be unique. For instance a DVD drive may be listed with the same device number as an HDD (especially if multiple optical drives are available), which of course means that, unless we can differentiate between devices using the same number, we may pick up the wrong one.

The HPUSBFW utility does add a call to GetDriveType(), to eliminate optical drives and avoid this issue. Rufus is now using the same approach.

[AlessandroMenti]

Thanks for the quick reply!

The new versions seems to detect the device correctly (I did not try to format it yet, but I saw the right drive letter and characteristics show up).

[pbatard]

Great. Thanks again for the test and the previous report - it really helped!

I'm going to push the patch and close the issue now.

[AlessandroMenti]

I tested the formatting capabilities this morning and can confirm that the new release works fully.

Thanks for solving the issue!