Rufus: Rufus killed my usb

[lectricas]

have no time to read like 1000 lines of explanation without any solution.
Tryied disk management, partition wizard, DISKPART, no damn luck!

[pbatard]

There's no solution. Flash memory has a limited number of read/write cycles. As you use it, it may fail, regardless of the application being used.

The FAQ explains this. But if you don't want to read it, so be it.

[lectricas]

I was angry writing this comment, although I will tell all my friends don't use your tool. TLDR what you've written. Just google Windows donwloading tool killed my usb, then google rufus damaged/killed my usb, count the answers. MATH!
Btw, windows download tool is much more popular than this tool.
I will also write to support to mark this repository as harmful. Thanks.

[pbatard]

1. If you can't calm down, then I will have no choice but to prevent you from posting further.
2. As explained in the FAQ, people who think that Rufus killed their drive don't appear to understand that, even if the application was buggy, it is next to impossible for it to kill a flash drive. That's just not how it works (but feel free to try to demonstrate otherwise with proof).
3. Rufus currently gets downloaded more than 3 million times each month. The amount of "Rufus killed my flash drive" posts (which actually has declined in recent months) is about just what you would expect from 3 million people happening to use an application, and experiencing an unrelated hardware failure, whilst wanting to blame the last application they were using. That's a bit too easy, don't you think? Especially as (if you read the FAQ), you will find out that some manufacturers do manage to screw up their USB Flash drive firmware in a manner that may render their drives inoperable (regardless of the application being used to access them).

You wanna blame something or someone, fine, that's understandable. And having someone who answers you is a lot easier to vent your frustration on than shake your fist at a mysterious hardware manufacturer or at something abstract like the limited life expectancy of a flash memory cell.

But once you've cooled down (and maybe spent some time reading the FAQ entry), you will realize that, no matter how much you (and a few others) would like to believe it, there is no verifiable evidence that Rufus actually damages flash drives. On the contrary, given its large number of users, the application appears to be statistically very safe to use, if anything.

[tuggerfub]

great, a hostile dev who won't take responsibility for breaking people's devices

acknowledge you've destroyed a lot of people's stuff instead of being a patronizing douche

the evidence is there, a lot of us use your program and immediately end up with broken drives

you are irresponsible and abhorrent and I will harshly discourage everyone I know from using rufus to create boot drives

[pbatard]

As I explained in the other issue you have opened, and despite what you would like to believe, we are not sitting on a a mountain of drives that we should be sitting on if Rufus was the great destroyer of drives people seem to assume it is, and neither seem to be people with enough expertise to demonstrate that there is an actual issue.

Also, I am actually the one who has repeatedly provided ample evidence that it is simply logically not possible for Rufus to systematically destroy drives, unless there exists a major bug in Microsoft Windows.

Either you believe that I am unable to fix the alleged issue, because myself or technical experts that I could rely on have never ever been able to replicate it, or you believe that I am lying. There just isn't any in between there. But if the latter, then I will have no choice to consider your comments as hostile, because, without the first shred of evidence, they are akin to plain defamation or FUD.

If you believe that Rufus damaged your drive, please contact your drive manufacturer to indicate what you did because, if they can replicate the issue (which they should have no trouble to if true), then they will be very eager to contact us, with verifiable expert evidence to support your claim.

As long as we cannot reproduce any of these alleged failures, __this__ is the only way you are going to make this alleged issue move forward.

[b4zz44]

I have exactly the same issue and I've done it twice in a row now, once with a used drive, once with a brand new one. It was easy to reproduce.
I used BalenaEtcher to put an image of Lakka Generic on a 32gb stick, on one machine. Then installed Lakka on another machine from that usb stick, to verify imaging worked. Put the usb stick back in first machine, started Rufus, selected a Windows 10 iso to burn, pressed start and Rufus presented a write error.
Same problem both times. Now neither drive can be accessed in any machine I have running Windows 7 or 10, or Ubuntu. Even diskpart won't touch them.

[pbatard]

It was easy to reproduce.

I'm afraid it isn't.

I have just tried writing Lakka-Generic.x86_64-2.1.1.img.gz repeatedly on various flash drives and SD cards, and could not replicate your issue.

Again, as much as I can understand that, if you appear to experience 2 drive failures in a row, you will be tempted to blame whatever software you were using for it, I simply cannot replicate these problems at all, and, by all accounts, neither can power users (people who use Rufus professionally to writes images to flash drives day in and day out, and would certainly make their voice heard if it was damaging drives in the manner that is alleged here) or flash drive manufacturers (who have a very vested interest of contacting the maker of software that might be damaging flash drives, to avoid spending money on RMA).

Therefore, even if this may infuriate you, I can only conclude that there is some environmental component to your issue, and that, despite what you assert, this is not a software bug.

For reference here's the log from one of my repeated attempts at replicating the issue:

Rufus x86 v3.4.1430
Windows version: Windows 10 64-bit (Build 17134)
Syslinux versions: 4.07/2013-07-25, 6.03/2014-10-06
Grub versions: 0.4.6a, 2.02
System locale ID: 0x0809
Will use default UI locale 0x0809
SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E
Localization set to 'en-US'
Found USB 3.0 device 'SanDisk Extreme USB Device' (0781:5580)
1 device found
Disk type: Removable, Disk size: 32 GB, Sector size: 512 bytes
Cylinders: 3818, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 2
Disk GUID: {5AD4B260-1FBD-4816-BC24-26EDEE3569E6}
Max parts: 128, Start Offset: 17408, Usable = 31406914048 bytes
Partition 1:
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'system'
  ID: {CF01BB68-7662-4AE5-B850-22EBCE51EAC1}
  Size: 512 MB (536870912 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000004
Partition 2:
  Type: {0FC63DAF-8483-4772-8E79-3D69D8477DE4}
  Name: 'storage'
  ID: {2AEA8620-1995-46D3-B345-468C31D3DD07}
  Size: 32 MB (33554432 bytes)
  Start Sector: 1050624, Attributes: 0x0000000000000000
Scanning image...
ISO analysis:
  'D:\Imgs\Lakka-Generic.x86_64-2.1.1.img.gz' doesn't look like an ISO image
Disk image analysis:
  Image is a compressed bootable disk image
Using image: Lakka-Generic.x86_64-2.1.1.img.gz (353.1 MB)

Computing checksum for 'D:\Imgs\Lakka-Generic.x86_64-2.1.1.img.gz'...
  MD5:   3956e26fecb2326ecad1891243f163fd
  SHA1:  30d65a20cc94c02a25bfb878ec581664b519d28f
  SHA256: c5b9f36edd32f25850e48dc5ab95c8d45daa2335f0910e525bf959581e40908b
Local time: 13189875589
Next update check in 30609 seconds.

Format operation started
Requesting disk access...
Will use 'G:' as volume mountpoint
Deleting partitions...
Deleting ALL partitions from disk '\\?\PhysicalDrive6':
● Partition 1 (offset: 1048576, size: 512 MB)
● Partition 2 (offset: 537919488, size: 32 MB)
Opened \\.\PhysicalDrive6 for exclusive write access
No logical drive found (unpartitioned?)
Drive does not appear to be partitioned
Writing compressed image...
Remounted \\?\Volume{ec24f8d9-0525-11e9-9812-fcaa14e7bd8e}\ on G:\

Found USB 3.0 device 'SanDisk Extreme USB Device' (0781:5580)
1 device found
Disk type: Removable, Disk size: 32 GB, Sector size: 512 bytes
Cylinders: 3818, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 2
Disk GUID: {5AD4B260-1FBD-4816-BC24-26EDEE3569E6}
Max parts: 128, Start Offset: 17408, Usable = 31406914048 bytes
Partition 1:
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'system'
  ID: {CF01BB68-7662-4AE5-B850-22EBCE51EAC1}
  Size: 512 MB (536870912 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000004
Partition 2:
  Type: {0FC63DAF-8483-4772-8E79-3D69D8477DE4}
  Name: 'storage'
  ID: {2AEA8620-1995-46D3-B345-468C31D3DD07}
  Size: 32 MB (33554432 bytes)
  Start Sector: 1050624, Attributes: 0x0000000000000000

[b4zz44]

And yet I've managed to do it two more times just now. 4 different brands of drives, 2 new, 2 used. From different suppliers. Using 3 different PCs. A colleague did it twice, when asked.

One of us knows what he's taking about and the other one is an arrogant twit. See if you can work out which is which.

Here I was expecting a request for further details, or suggestions on ways to assist in identifying catalysts, but Instead I get sarcastic condesention.

---

From: Pete Batard [e-mail]
Sent: Saturday, December 22, 2018 12:22:36 AM
To: pbatard/rufus
Cc: b4zz44; Comment
Subject: Re: [pbatard/rufus] Rufus killed my usb (#839)

It was easy to reproduce.

I'm afraid it isn't.

I have just tried writing Lakka-Generic.x86_64-2.1.1.img.gz repeatedly on various flash drives and SD cards, and could not replicate your issue.

Again, as much as I can understand that, if you appear to experience 2 drive failures in a row, you will be tempted to blame whatever software you were using for it, I simply cannot replicate these problems at all, and, by all accounts, neither can power users (people who use Rufus professionally to writes images to flash drives day in and day out, and would certainly make their voice heard if it was damaging drives in the manner that is alleged here) or flash drive manufacturers (who have a very vested interest of contacting the maker of software that might be damaging flash drives, to avoid spending money on RMA).

Therefore, even if this may infuriate you, I can only conclude that there is some environmental component to your issue, and that, despite what you assert, this is not a software bug.

For reference here's the log from one of my repeated attempts at replicating the issue:

Rufus x86 v3.4.1430

Windows version: Windows 10 64-bit (Build 17134)

Syslinux versions: 4.07/2013-07-25, 6.03/2014-10-06

Grub versions: 0.4.6a, 2.02

System locale ID: 0x0809

Will use default UI locale 0x0809

SetLGP: Successfully set NoDriveTypeAutorun policy to 0x0000009E

Localization set to 'en-US'

Found USB 3.0 device 'SanDisk Extreme USB Device' (0781:5580)

1 device found

Disk type: Removable, Disk size: 32 GB, Sector size: 512 bytes

Cylinders: 3818, Tracks per cylinder: 255, Sectors per track: 63

Partition type: GPT, NB Partitions: 2

Disk GUID: {5AD4B260-1FBD-4816-BC24-26EDEE3569E6}

Max parts: 128, Start Offset: 17408, Usable = 31406914048 bytes

Partition 1:

Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}

Name: 'system'

ID: {CF01BB68-7662-4AE5-B850-22EBCE51EAC1}

Size: 512 MB (536870912 bytes)

Start Sector: 2048, Attributes: 0x0000000000000004

Partition 2:

Type: {0FC63DAF-8483-4772-8E79-3D69D8477DE4}

Name: 'storage'

ID: {2AEA8620-1995-46D3-B345-468C31D3DD07}

Size: 32 MB (33554432 bytes)

Start Sector: 1050624, Attributes: 0x0000000000000000

Scanning image...

ISO analysis:

'D:\ImgsLakka-Generic.x86_64-2.1.1.img.gz' doesn't look like an ISO image

Disk image analysis:

Image is a compressed bootable disk image

Using image: Lakka-Generic.x86_64-2.1.1.img.gz (353.1 MB)

Computing checksum for 'D:\ImgsLakka-Generic.x86_64-2.1.1.img.gz'...

MD5: 3956e26fecb2326ecad1891243f163fd

SHA1: 30d65a20cc94c02a25bfb878ec581664b519d28f

SHA256: c5b9f36edd32f25850e48dc5ab95c8d45daa2335f0910e525bf959581e40908b

Local time: 13189875589

Next update check in 30609 seconds.

Format operation started

Requesting disk access...

Will use 'G:' as volume mountpoint

Deleting partitions...

Deleting ALL partitions from disk '\?\PhysicalDrive6':

● Partition 1 (offset: 1048576, size: 512 MB)

● Partition 2 (offset: 537919488, size: 32 MB)

Opened \.\PhysicalDrive6 for exclusive write access

No logical drive found (unpartitioned?)

Drive does not appear to be partitioned

Writing compressed image...

Remounted \?\Volume{ec24f8d9-0525-11e9-9812-fcaa14e7bd8e}\ on G:\

Found USB 3.0 device 'SanDisk Extreme USB Device' (0781:5580)

1 device found

Disk type: Removable, Disk size: 32 GB, Sector size: 512 bytes

Cylinders: 3818, Tracks per cylinder: 255, Sectors per track: 63

Partition type: GPT, NB Partitions: 2

Disk GUID: {5AD4B260-1FBD-4816-BC24-26EDEE3569E6}

Max parts: 128, Start Offset: 17408, Usable = 31406914048 bytes

Partition 1:

Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}

Name: 'system'

ID: {CF01BB68-7662-4AE5-B850-22EBCE51EAC1}

Size: 512 MB (536870912 bytes)

Start Sector: 2048, Attributes: 0x0000000000000004

Partition 2:

Type: {0FC63DAF-8483-4772-8E79-3D69D8477DE4}

Name: 'storage'

ID: {2AEA8620-1995-46D3-B345-468C31D3DD07}

Size: 32 MB (33554432 bytes)

Start Sector: 1050624, Attributes: 0x0000000000000000

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/pbatard/rufus/issues/839#issuecomment-449400867, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Ar582SIGteqCq3x11Aue_tvLxFgd5hsVks5u7O6sgaJpZM4KXL_N.

[pbatard]

One of us knows what he's taking about and the other one is an arrogant twit.

If you're going to start insulting people in this thread, you're not going to get anywhere.

Also, you seem to be implying that I lied with my testing, that indicates that I was unable to replicate your issue at all, which also is not going to get you anywhere.

The __fact__ remains that I have been unable to replicate your issue with at least 3 different types of drives, using 2 different PCs (one running Windows 10 x64, and another running Windows 7 x86 - these were not virtual machines).

The drives I used where:

• KingMax 32GB USB 3.0 (1687:0903)
• SanDisk Extreme USB 3.0 32GB (0781:5580)
• Samsung EVO Plus 128GB uSD card, through a Lexar USB 3.0 adapter (05DC:B051)

I tried writing various Windows 10 images (mostly the 1809 x64 en re-relase, SHA-1 bee211937f3ed11606590b541b2f5b97237ac09d since you chose not to disclose the actual one you used) after having also written Lakka images for good measure. I also tried to close & reopen Rufus, plug then unplug the drives. And yet, not a single time was I able to replicate your issue. For full disclosure, I will report that, on one occasion, with the KingMax drive, I got an transient error when repartitioning the drive, but that's just something that can occasionally happen on Windows 10, but when I tried writing the same image again everything was fine, and that drive certainly did not exhibit any issue when I ran additional tests.

Also, if you want to provide details, then I will expect you to provide them from the get go. When you report an issue, then, even if it sounds condescending, of course you are expected to provide as much data as you can. For instance, you chose not to disclose the brands and types of the drives that failed, or the actual ISO you used (there are tons of Windows 10 ISOs), but mistakenly assumed that everybody would be able to replicate the issue, which is not helpful at all. You should also be aware that Rufus can produce an exhaustive log (last small button left of the _START_ button), which does wonder in making sure whoever is trying to replicate your issue can do it in the conditions that are as similar as possible. Yet, even when your second drive failed, or the subsequent ones, you still haven't produced a log that provides the complete details on how you created the alleged failed drives.

If you want this issue to be investigated, and understand that:

1. When someone disputes one of the point you made (easy to reproduce) with the evidence of the contrary, there may be a very good explanation for it, and it doesn't mean that, even if they might have a vested interest in doing so, they are lying about it
2. Insulting the people you are trying to report the issue to is definitely not a mature way to try to have it addressed,

Then I am happy to get more details from you, and especially complete logs that may give some details about the environment, ISO and drive you used, as well as how you created the drive.

But if all I am going to get is further abuse, then, in return, the only thing you are going to earn is a ban as well as an abuse report to github support.

Also, please understand that Rufus is downloaded more than 3 million times each month, with a large number of these downloads being used to create bootable USBs from recent Windows ISO (especially Windows 10 images). Yet reports of the software destroying drives in the manner you assume must be the case __clearly__ do not correlate with the number of entries one would expect if your assertion that this is a generalized issue was true. So, logically, there has to be some alternate explanation.

For instance, maybe your environments are being thrown off by the UEFI:NTFS partition that Rufus must write when creating a recent Windows 10 1809 image in GPT mode, since it contains an install.wim that is larger than 4GB?

But, feel free to assert that a factual rebuttal of your evidence, with counter evidence, is _"sarcastic condescension"_, and that there can only be one explanation to the problems you appear to have experienced: the one of Rufus having a major bug, that has gone undetected for years and that, strangely, has never managed to be replicated by people such as flash drive manufacturers, developers who understand the workings of Windows and could easily pinpoint the issue to a software bug, especially if that software is 100% Open Source, or power users who create Windows drives using Rufus day in and day out.

[pbatard]

I'll also add, if you feel like trying to demonstrate further that Rufus is indeed the killer of USB drives you allege, that you should make sure that you run a complete bad blocks check on the drive before you write the Window 10 image, and especially a bad block check that is designed to detect fake drives (i.e. drives that report more capacity than what they really have, say 16GB instead of an actual 2 GB for instance, which is yet another thing that could explain why writing a <1GB image shows no issue, and why writing a > 4GB ISO would render the drive inoperable).

Rufus does include such a bad blocks check, which you can activate under _Advanced format options_. I guess 2 passes should be fine, but, if you know the actual type of NAND used in your flash drive, you can of course select one of the last 3 options. But of course, if you don't trust Rufus, feel free to use a different bad blocks checker, as long as it is one that is also designed to check for fake drives.

[blackcrack]

pete, there gives peoples where want other Products destroy to make self the business ,
it is not reproducible, with all love, exist it not, should close this tread and make ro.
And he should make it in real Official way with real writes and proves, to usb-sticks kill's.

Your Rufus be in the last years so very high developed.. and nobody other say,
your Rufus kills USB-Sticks, only this .....beep.... want that put you to the load/burden ..
and there is no other "kill-feedback"
it will give ever peoples or a group of peoples who want be bad..
must be there something wrong.. so close and readonly this f... Tread
is there a possible to hold out and blacklisting peoples on this project ?

Pete, your Rufus is a really one of the bests cool tools for USB-Sticks in the whole entire Net ,
and this say an German.. where was the last more as 20 Years in the Net...
so, close this f.. tread and forget it ..

best regards
Blacky

[pbatard]

@blackcrack, I appreciate the support, thanks.

However, I don't want to prevent people from voicing their opinion (as long as they don't go around throwing insults and whatnot instead of realizing that there are plenty of ways USB Flash drive(s) could appear damaged, without the software being used at the time having anything to do with it), because the minute I do that, these same people will start screaming _"You see: the developer is trying to SILENCE people who want to report drive failures! That can only mean the software is at fault!"_, once again failing to realize that the only reason the developer might want to close a thread off is because they are getting tired of trying to explain how the Windows Abstraction Layer and the fact that, as opposed to what many people seem to believe, Rufus does not send straight USB commands to the USB bus, means that, no, even if Rufus had a major bug, it is still impossible that it could destroy a drive. I mean, there are only so many times I can repeat that _"If you are familiar with the way an OS works with Mass Storage devices, such as USB Flash Drives, and also understand that Rufus does not send straight USB commands on the bus, but instead just uses the OS abstraction layer to write sectors, then there is simply no logic that would allow Rufus to damage a drive unless Windows has a massive bug that has gone undetected for years. That's just the ways Windows and Mass Storage devices work: The worst you can ever accomplish, even if your software is buggy, is write garbage data onto a sector... which is not an operation that could even remotely damage a drive (a drive should accept writing any random data into any sector — that's the whole point of a storage device!)"_ before it becomes a bore for everyone...

But of course, there exist some people who will always prefer putting their finger in their ears and prefer to simply blame the software or its developer, because it's oh-so-much easier to __assume__ that a random developer has no clue what they're doing (even if that same developer happens to have more than 30 years experience doing software development for various well known companies, and, because they have been a prominent developer of libusb for instance, does have some insight into how Windows, USB and Mass Storage work in order to allow them to state, objectively and with authority, whether it is possible for this or that application to damage drives), and it also so much easier to pretend that the person you are talking to can only be biased and that whatever facts they throw at you, to back up their arguments, can be dismissed, because, even you haven't literally spent __years__ dealing with USB, Windows and flash based Mass Storage devices, or haven't bothered to try to look at the very public code for the application, you just happen to "know better" what can and cannot happen between an (allegedly) buggy application and a USB device.

But I guess getting abuse, inaccurate claims (again, please understand that here I am not dismissing the idea that some people may have seen drives failed while using Rufus, the "inaccurate" part is simply about Rufus being the only element that could ever be blamed for these failures) as well as angry tantrums is the ransom of having one's software being used by hundreds of millions people, so I can continue to live with that without having to resort to closing threads. In fact, I'd much rather have people piggyback on a thread, where they can plainly see how infrequent (in comparison to the rate at which Rufus is being used) these reports of _"Rufus killed my flash drive"_ really are, so that they might get a slight hint that, possibly, the reason the developer may seem "condescending" or dismissive of these issues is because they happen to fall exactly within the range of the coincidental failures (due to various factors such a fake drives, poor environment, misunderstanding from the user part, Windows bugs such as the ones that occur when trying to write some Chromium images, hardware bugs such as the ones that are present in some PNY drives, etc.) that are expected to be reported against an application that is used by millions and millions of people.

However, I will conclude with this: Considering that fake drives are a reality (I actually ended up unknowingly purchasing one myself, some years ago so I do have punctual evidence that this is a real issue) and, I would expect, it is __more than likely__ than a few of the various people who ever reported drive(s) failure while using Rufus while trying to pin the blame on the application were in fact using fake drives, I can't help to find it strange that not one of these same persons have ever had the decency to post a follow up, to indicate that they ended up figuring that their issue was caused by a fake drive. Statistically, this is what I expect to have happened to quite a few of the people who have been screaming at me or at Rufus for destroying drives. Yet, I have never gotten even a single _"Sorry for the noise, it simply turns out I had been using a (bunch of) fake drive(s)"_, which I can't help but find a bit strange...

[hobbysaukhi]

guys.. i have the same disaster.. spend 3 flshdisks .. thx to you :( :-1:

[blackcrack]

ah.. no try Problem/issue resolving and to giveing a helping hand, easy denigrate .. shame on you.. !

[hobbysaukhi]

i just found this...
use "RMPREPUSB 2.x"

*choose your usb
*file system fat32
*click green "button" on the upright
let it begin... n
there.. i have my USB back to alive..

[pbatard]

@hobbysaukhi, you probably thought your flash drives were dead because they were formatted to a file system that Windows does not recognize (which will happen when you write some images such as FreeBSD and such). So let me make that clear: __It is not because your drive does not appear in File Explorer that you should assume that it is dead__

Oh, and Rufus can easily restore the drive for you in the same manner as RMPrepUSB, if you chose _Non bootable_ in the _Boot selection_ dropdown. Did you try that?

At any rate, if you were able to restore your drive by simply reformatting it (which is what RMPrepUSB did), then, __clearly__ your flash drive was NOT dead, and your report to this thread is irrelevant, because it has nothing to do with the alleged issue of Rufus damaging flash drives in a manner that makes them unusable afterwards. Your drive was not killed.

So, once again, I have to advise __anybody__ wishing to add their report to this thread: If you want to be taken seriously, you might want to make sure that your drive is actually dead, and that you have confirmed this from multiple Operating Systems. And once again, a report of a drive being "dead" goes much better if you provide the brand and model of your drives, where and when you purchased them, as well as the enumeration report from Rufus (make sure that your drive is plugged, launch Rufus, press Alt-. and __POST THE LOG__).

[ghost]

What the person in this post is looking for is a fix to his problem. To him your fucked up his USB drive, he doesn't know to use the Windows Disk Manager to reformat it the USB drive so it's readable again. You could of just told him to do that instead of defending the fact your software failed to preform necessary checks before operating on the drive

[pbatard]

your software failed to preform necessary checks before operating on the drive

Contrary to what you assert, Rufus __does__ check if there are other processes using the drive before formatting. The first thing you should see after you press _START_ is an info message telling you _Checking for conflicting processes..._ and this whole source is about checking for other processes that may be accessing the drive and reporting them. For instance, if you open a mere command prompt to the USB drive you are trying to format you will see this:

And in the log you will see this:

Found potentially blocking process(es) against G:
● [000864] C:\Windows\System32\cmd.exe (x)

Also as opposed to other software that formats or creates bootable USB Flash Drives on Windows, and much to the chagrin of many users (who think that Rufus seems to refuse to format their drive for no valid reason), Rufus requires an exclusive lock on the drive before it repartitions or formats it, meaning that it tries to ensures that no other application can issue writes to the device that might conflict with its operation.

So, next time you want to accuse software of _"fail(ing) to preform necessary checks before operating on the drive"_, you may want to do your research instead of flinging baseless accusations that make you look like a person who clearly has no idea what they are talking about.

Look, you are annoyed that your device seems to have failed, and you want to point the finger at someone.

__I get it.__

However, you should know better than to want to kick the developer and accuse them of incompetence, __simply because it's easy to assume, without checking for evidence, that the dev is incompetent__. So let me return your proposal to you:

You should avoid failing to perform necessary checks about asserting that an application does not perform necessary check before posting about it in an issue tracker.

Now, a couple of things you and everybody else who might be tempted to believe your bullshit might need to know about:

• Two conflicting applications writing to a device at the same time cannot cause that device to fail. Hardware issues, such as drive failures, occur because of hardware, not software.
• If the drive can be reformatted in Windows Disk Manager then it can be reformatted in Rufus. Also, if the hardware has failed, which is what this thread is all about ("Rufus killed my USB drive"), then neither Disk Manager or Rufus would be able to format it again. Thus, if you were able to recover your drive using Disk Manager then your drive wasn't "killed" at all and you are clearly posting about the wrong issue.

If your USB has been killed, which is all this issue is about, then there is no __fix__ for it outside of RMA'ing it to the manufacturer. If, on the other hand, you are looking for ways to repartition an USB Flash Drive that hasn't been killed, but for which Windows does not see a partition with a file system it can mount (therefore making it look like it is not accessible, __which is VERY DIFFERENT from a killed drive_), then, instead of assuming that the last application that was used _"fucked up his USB drive"_ you should do your research and look elsewhere than a thread in an issue tracker that is not relevant.

[ghost]

Wow,

This email is not appretiated at all. I understand you may of placed text stating that at execution time, and even preformed checks to see id the drive is in use.
However that does not change the fact a message box flashed up saying the drive was in use by another program and all i could do was click "ok". I clicked okay as it was the only option and what happened is it turned the drive in to a RAW format and i need to use the window "Disk Managment" tool to assign a FAT32 file system to it in order for the drive to be picked up by windows in windows explorer and your application.
I did just that and preformed the checks that nothing else was accessing the drive for use with your application. This worked and your application was able to write the image to drive and i have Ubuntu running on laptop for development.
I advise you to not tell people what their experience was with your software, you were not their and it is their experience for them to share.
I also advise checking your code and ensuring it does what you expect, after all as a developed myself i'm used to code not working as intended and revising it to work correctly.
Last thing i advise is stop getting angry, after all myself and the others on the thread we're helping you identify an issue with your software to fix which in turn gives you a better reputation. Try getting laid once in a while too cause you come off as a prick.
All the best do not contact me again!

[pbatard]

However that does not change the fact a message box flashed up saying the drive was in use by another program and all i could do was click "ok".

Well, first of all, __as I explained__, having conflicting processes accessing a drive will __NOT__ kill it, so continuing on that operation is not a major issue.

Also, the screenshot I attached literally shows that you can choose either _Yes_ or _No_ when Rufus asks you if you want to proceed.

So, once again, your _all i could do was click "ok"_ assertion can be demonstrated as __complete bullshit__. If you don't want developers to reply to your statements in a disparaging manner, I strongly suggest that you stop spewing easily disprovable bullshit about the behaviour of the software you want to accuse of not performing as it should.

what happened is it turned the drive in to a RAW format

So your drive wasn't killed at all, and you are misusing an issue about killed drives to vent some frustration.

I advise you to not tell people what their experience was with your software, you were not their and it is their experience for them to share.

Then do it in a __relevant__ thread, instead of hijacking an old thread that has nothing to do with your issue.

I also advise checking your code and ensuring it does what you expect

This is yet another baseless accusation. __Where exactly__ do you think I am not doing just that?
You do understand that, if you want to assert that I have code that is not doing what __I__ am expecting, then you should be able to point to it. No, if that is code that is not doing what __YOU__ are expecting (whereas it does exactly what I am expecting, such as letting users continue on conflicting processes __if they choose so__, because it's not going to damage their drive and __many__ users prefer to have a choice rather than get stuck), that's another story. But, until proven otherwise, I think my code does pretty much what I expect it to do.

we're helping you identify an issue with your software to fix

I'm afraid you aren't. You (aggressively, as per your edit) made a baseless accusation that Rufus was not checking for conflicting processes, whereas it can be __easily demonstrated__ that it does, and that the only way to restore a drive, that wasn't actually killed, was to use Disk Manager, whereas, if you had opened a new issue instead of piggybacking on one that is irrelevant to you, you would have been pointed to the FAQ, which contains this entry explaining how you can restore a drive when Windows doesn't seem to report anything on it, which, I assert, it all the help you really needed.

So, as far as I'm concerned, I see no issue here apart from someone who seems a bit to eager to want to point the finger at a developer because they have already decided where the blame should lie, regardless of facts.