Rufus - USB Formatting Utility

[webfork]

First of all, thanks for the work you've done here for promoting the app and making it portable. It's always appreciated!

That's our aim and we're glad to cast whatever promotion we can. I've also used your program and really feel lucky to have it. Thanks for your work on this and for letting us know about the 1.4.0 issue.

[Midas]

Microsoft has changed its mind so many times on where on the filesystem application settings should be stored (I'm still not sure what the difference is between Local, LocalLow and Roaming) that, even today, using the registry looks like best way to future-proof your app. The current annoyance (Vista or later) about old apps storing their .ini in C:\Program Files only to find out that the .ini file in there is read-only and that the actual editable version resides somewhere you'd never guess on your own (I have to keep a blog post to remind me of that location), has left more than one developer worried about trusting the filesystem approach...

Like it or hate it then, and I'm not speaking just for Rufus, the registry is here to stay. And IMO, that's because it does serve its purpose rather well as a convenient centralized and compartmentalized placed for apps to store their settings.

• IMHO, you could have the best of both worlds if you allow the user the option to save registry settings to file at an arbitrary location (including relative paths and system variables); that way you can have program settings in the system's registry while Rufus is running, and a manageable file when it is not...

[Akeo]

Not sure if that works too well. If I let the user save registry settings to an arbitrary location, then I need to find out on the next run where that arbitrary location is... which I guess I'd have to pick up from the registry? Else, I guess the expectation would be to have a Rufus.ini in the same location as the app. But I really don't want to automatically create such a .ini file unless the user specifically indicate that they want one, especially as Rufus could be saved on the desktop, and the last thing you want is for a program to suddenly create yet another file on the desktop when you didn't ask for it (ugh!). Remember that Rufus was also designed to be used by non tech-savvy users...

Right now, the only realistic option I see to satisfy both school of thoughts would be to do something as follows:

• If a Rufus.ini exists in the same directory as the app, consider that the user wants to start it in portable mode
• On startup (if in portable mode), copy relevant data from the .ini, if any, into the registry.
• Run rufus as normal, using the registry settings.
• On exit (if in portable mode), copy the relevant data from the registry into the .ini.

This way, the only way a settings file gets created is if users indicated that they want one (by creating it in the first place - a blank one could be all it takes), and all the users who don't want to see their filesystem "polluted" with an extra file are left "unpolluted".

Or maybe I'm misunderstanding your suggestion, and this is also what you had in mind?

I may try to look into doing that when I get a chance, but, considering that John's solution works just as well for portability, and I'm pretty sure that portable-oriented users are more than happy with the work he's done, it'll be a low priority task for now.
I'm also open to other suggestions, if you think there's a better way to try to keep everybody happy!

[Akeo]

Just going to point out that Rufus 1.4.3 (which is a bugfix release of 1.4.2, due to an XP issue) has now been released.

• Version 1.4.3 (2014.01.21) [BUGFIX RELEASE]
  • Fix format operation not starting on Windows XP (reported by ank91)
• Version 1.4.2 (2014.01.18)
  • Add USB Attached SCSI (UAS) support (NEW)
  • Add ReactOS support (NEW)
  • Add NTFS UEFI support, for targets that can support it (NEW)
  • Add insertion detection for USB memory card readers (NEW)
  • Add retry when writing ISO files... again
  • Add Chinese (Simplified) translation, courtesy of 佚名
  • Add Indonesian translation, courtesy of Abe Akatsuki
  • Add Malay translation, courtesy of Muhammad Aman
  • Add Portuguese (Portugal) translation, courtesy of Fernando Baptista
  • Speed up boot record cleanup, for slow drives
  • Improve initial locale detection
  • Save user selected locale between sessions (NEW)
  • Always use English locale in the log, where possible
  • Fix detection for some SanDisk, Kingston, HP and Toshiba drives
  • Fix a potential issue with drive letter assignation
  • Various other fixes and improvements

[Midas]

maybe I'm misunderstanding your suggestion, and this is also what you had in mind?

Precisely. (Sorry for not answering sooner, but the question somehow slipped me by.)

To sum it up: 1. if Rufus is launched and there's no registry info or INI, prompt user; 2. if there's registry info, assume Rufus is installed (an extra option to remove it or move it to INI would be just golden); 3. if there's an INI at executable location, assume portable.

[Akeo]

To sum it up: 1. if Rufus is launched and there's no registry info or INI, prompt user;

I don't think I want to prompt the user about anything else but the check for update. If there is no registry and no .INI, then non-portable mode will be assumed always.
The thing is, even a blank .INI will be enough to enable portable mode, so if someone wants portable, they just have to right click, create a new text file and rename it to rufus.ini. From there on, Rufus will act in portable mode (and will populate the .ini as required, on exit).

This way, people who want portable (the minority) can easily state their preference, and people who don't want portable (the majority) won't have to be prompted about it.

My current plan is to continue to use the registry, even in portable mode, but move all data to/from the registry whenever there's a .ini.

Oh, and for the record, I logged an enhancement to do just that some time ago. Right now it's targeted at 1.6.0, as it's not very high on my priority list, but depending on how difficult I think it will be to implement, it may happen sooner.

[Checker]

Just going to point out that Rufus 1.4.3 (which is a bugfix release of 1.4.2, due to an XP issue) has now been released.

Thanks ... and updated

[Akeo]

Thank you!

[Midas]

I don't think I want to prompt the user about anything else but the check for update. If there is no registry and no .INI, then non-portable mode will be assumed always. [...]
This way, people who want portable (the minority) can easily state their preference, and people who don't want portable (the majority) won't have to be prompted about it.

Suits me fine, thank you.

Not to nitpick, but have you given any thought to instances where the registry is populated and then an INI sprouts at program location; what will happen then?

[Akeo]

have you given any thought to instances where the registry is populated and then an INI sprouts at program location; what will happen then?

Of course: it's a non-issue.

The INI is only checked when the program launches and IS overwritten regardless of what happened in between when the program exists.

And in case this is your actual question, no, I'm never going to add extra code to detect the one case in a million when someone created an INI in between. I'm not even going to bother warning user that the INI will be overwritten if one just appeared because, if you assume that a program will retroactively apply settings that you just copied over, you clearly need to be taught a valuable lesson...

[Akeo]

Rufus 1.4.5 (which is a bugfix release of 1.4.4) has now been released.

• Version 1.4.5 (2014.02.27) [BUGFIX RELEASE]
  • Fix detection of fixed drives (reported by dominiquesb)
• Version 1.4.4 (2014.02.26)
  • Add uncompressed Disk Image support (FreeBSD, FreeNAS, etc.) (NEW)
  • Add right-to-left language support (NEW)
  • Add an alert when multiple partitions are about to be erased (NEW)
  • Add (unofficial) NTFS Compression support (NEW)
  • Add Finnish translation, courtesy of Riku Brander
  • Ignore failure on ISO autorun.inf creation, to keep dumb security applications happy
  • Improve hotplug detection
  • Improve Syslinux v5+ support (requires an internet connection to download extra files)
  • Fix support for latest gparted, ArchLinux, and other Syslinux v5+ based ISOs
  • Fix detection for Toshiba drives (again)
  • Fix UDF Unicode support

[Checker]

@ Akeo: Thanks ... and updated

[Akeo]

@ Akeo: Thanks ... and updated

Actually, I just had to silently release 1.4.5.428 to fix a missing code line that broke 1.4.5.427.

If you picked 1.4.5 before seeing this post, you will have to download it again and make sure that you are using 1.4.5.428, else you probably won't be able to format anything. Very sorry about this!

The portable version is still 1.4.3, so hopefully the proper 1.4.5 will be used as its base when it is updated. And of course the links to 1.4.5 point to the right version on the Rufus homepage.

[Userfriendly]

Rufus 2.0 BETA (PLEASE REPORT ANY ISSUES - DO NOT USE AS A RELEASE)

• Version 2.0 (2015.03.??)
• Major UI improvements (improved font, new info field, no separate progress dialog, etc.)
• Add support for Windows To Go (when Rufus is running on Windows 8 or later)
• Add support for Grub4DOS and GRUB 2 based images (e.g. FreeNAS)
• Add portable application support, through a 'rufus.ini' file
• Add native decompression support for DD images (.Z, .gz, .lzma, .bz2 and .xz)
• Add seamless UEFI boot of NTFS partitions, for Windows ISOs with large files (>4GB)
• Add support for Windows multipart install.swm
• Add support for non Microsoft VHD drivers
• Add Norwegian translation, courtesy of JED
• Fix a crash on image selection when no device is present
• Fix broken VHD support for non-English version of Windows
• Fix write error for DD images that are not a multiple of the sector size
• Fix broken Unicode support
• Update Syslinux to 6.0.3
• Other improvements and fixes

Download: http://rufus.akeo.ie/downloads/
Changelog: https://github.com/pbatard/rufus/blob/m ... ngeLog.txt
FAQ: https://github.com/pbatard/rufus/wiki/FAQ

[Akeo]

• Add portable application support, through a 'rufus.ini' file

Yeah, I actually wanted to post in this forum about how the new portable feature of Rufus works:

• If you have a 'rufus.ini' in the directory where you are launching Rufus from (even if it's a blank one), Rufus will use this, instead of the registry, to store all its settings.
• Also, if any part of the executable name contains a 'p' (for portable), Rufus will create a 'rufus.ini' if one doesn't already exists, and use it. This means that if you call the executable "rufus_portable.exe" for instance, Rufus will automagically activate its portable mode.
• The format of 'rufus.ini' is documented here, but you should almost never have to modify this file manually.

Note however that portability does not equate unmodified registry, as Rufus will still apply LGP policies to temporarily avoid the annoying "Hey, I detected a new drive - do you want to format it?" messages that Windows would otherwise pop out. If you are that paranoid about registry changes (and I got some flak from people who definitely are...), you can however use portable mode and enable 'DisableLGP' in the INI, in which case registry changes originating from Rufus should be removed. But you will of course get the annoying popups from Windows then...

If you have any questions about portability support please let me know.