Downloading an Update - Githubissues

Just a tiny issue... When the portable version checks for and downloads an update, it grabs the non-portable update, not the portable one.

Which doesn't matter, since the non-portable version will check if there exists a rufus.ini present in the same directory and run in portable mode if that is the case. So, here's what will happen:

User has downloaded and runs rufus-2.6p.exe
Because it has a p in its name (that's the only difference between the portable and non-portabl;e version by the way - they are actually binary identical and only the name changes) rufus-2.6p.exe starts in portable mode and creates a rufus.ini in the same directory.
Rufus notifies the user that the 2.7 update is available and prompts the user to download it.
User downloads rufus-2.7.exe (which is binary identical to rufus-2.7p.exe , except for the name) in the same directory.
When rufus-2.7.exe starts, it checks whether a rufus.ini exists in the same directory, and starts in portable mode if it does.

In other words, there are no differences between the portable and non portable version - they are exactly the same application. It's only when the application starts that it will checks for the following 2 conditions:

Does the executable contain a p in its name?
Does a rufus.ini exist in the same directory?

To decide whether it should start in portable mode or not.

This means that, unless someone saves the updated version in a different directory from the one they have the .ini file (which I consider unlikely), they will continue to run in portable mode no matter what version they download.

If that doesn't answer your question, feel free to reopen this issue.

This means that, unless someone saves the updated version in a different directory from the one they have the .ini file (which I consider unlikely), they will continue to run in portable mode no matter what version they download.

Actually, that IS the issue... I downloaded the portable version for a reason - It'll live in my Dropbox folder along with a few other little gems like Putty, I probably won't use it for a couple years, and the next time I do want this program, I likely won't remember what it's called, let alone that I can change a p in its name to flip it between portable or not.

An appropriately pre-checked option you can change before clicking the Download button might be better, but just keeping the same portability would be nice.

In any case, perhaps mentioning this a little more prominently on the homepage, might be in order - would have saved me the bother going back to the site to download the newer portable version, if I'd known I could just rename it.

But... Still. Not a big issue. Just makes it look a little, amateurish, and less trust-worthy, I guess is how I'd describe it.

let alone that I can change a p in its name to flip it between portable or not.

I don't think you quite understood what I said above. You don't need to change the name if you save it in the same folder where you have a rufus.ini file. If Rufus sees a rufus.ini in the same directory (even an empty one), it starts in portable mode, regardless of whether the application name contains a p or not.

and the next time I do want this program, I likely won't remember what it's called

That doesn't make sense. The update check only runs when Rufus runs. So the only way you will get an update for Rufus is if you are already running Rufus, in which case you should have no trouble figuring its name, since it's written on the title bar...

Just makes it look a little, amateurish, and less trust-worthy

Nice try, but, no, I don't seem much of a reason to do anything about this. The only users it will affect are people who, despite having just launched the app from a specific folder (which they should be able to remember), decide that they want to save the new Rufus in a different folder, especially as Rufus should prompt to save in the original folder by default... So I fail to see how it will affect that many users, and it looks like you had to put forward a convoluted reason like use with dropbox (even as the rufus.ini should live in the same dropbox folder, which should be the default place the update check should ask you to download the new file). Moreover, there are very few settings that Rufus saves, the most important of which being the language... which, in 99% of the case, will be the same as the one you are running Windows in.

Okay... One last shot at getting my perspective across. Feel free not to respond...

Clarification: It will be in Dropbox/public/utils, where I keep a whole bunch of portable (or at least minimally invasive) little tidbits that I've stumbled across and like. And the most common use the collection of stuff in that folder, is to do something while on a machine other than my own - where I really would like portability, and most certainly won't have my Dropbox account actively mirrored. And when done, I'll typically leave the folder I downloaded them into, for whomever to keep or delete as they choose. Plus there's the reference to my public Dropbox folder in their browser history, which they can use to go remind themselves what tool it was that I'd used. So if I tell them it's a portable program, I'd like it to stay that way.

My issue, is with programs that change the rules like this behind the scenes. Kind of gotten used to the Browsers doing it, but a small utility like rufus, really shouldn't. And while yes, as much as phrasing it that way does come across as a 'try', it's also not far from the truth: it really does give me a somewhat uncomfortable feeling, made significantly worse by how trivial I perceive it should be to fix and be done with -- considering the presence of that p is already being checked for if no rufus.ini file is found -- and I really don't comprehend the rationale for rejecting what I personally view as trivial and obvious expected behaviour. I'll admit, when I first opened this topic, the response I expected was more like, "oh, yeah, not sure how we missed that one...", and what I got back sounded to me more like, "who cares, I can't be bothered", which sort of caught me off-guard.

But you're probably right, it won't affect many users at all. Just brand new ones who see there's a portable version, and don't expect it to magically become non-portable when they do something with it that you consider to be 'unlikely' -- which somehow tends to end up being precisely how any given product WILL be used, far more often than we'd ever have imagined (fwiw, my background is in Embedded Systems firmware, where updates are problematic, bootable USB drives irrelevant, and expected and reliable behaviour pretty much mandatory).

where I really would like portability, and most certainly won't have my Dropbox account actively mirrored

You do realize that if you work in this fashion, even if Rufus was downloading the p version, you'd lose the whole point of portability (because you don't keep your settings when switching computer). Despite what many people believe, the ONE goal of portability is NOT that an application should be prevented to write in the registry (which is a ridiculous reason to want a portable app) but that, if you switch from one machine to another, the application settings are preserved.

Therefore, if you don't actively mirror your dropbox account then, congratulations, you have just defeated the whole point of using a portable app in the first place, and I have to ask: Why then do you want to use the portable version of Rufus?

But of course, if you do mirror your dropbox account to work in actual portable mode, then you will also mirror the rufus.ini (a.k.a. the place where Rufus stores its portable settings), which means that, as I tried to explain previously, ANY version of Rufus that you run from that folder, including versions that don't have p in their name, will still run in portable mode. The only way you will end up with an updated version of Rufus that does not start in portable mode is if, for some weird reason, you choose not to save that update in your Dropbox/public/utils/ directory (or Dropbox/public/utils/rufus/ directory if you decide to have Rufus in its own directory), which I see unlikely to achieve unintentionally, as Rufus should prompt you to download an update in the same directory you launched the app from. In other words, you really need to go out of your way to end up in a situation where Rufus will not start in portable mode, and I'd really like to hear a rational scenario where you think you will actually end up in such a situation.

Oh, and you also didn't answer my question about which settings you feel are that important to preserve in Rufus...

My issue, is with programs that change the rules like this behind the scenes.

And now, since you still haven't been able to prove your point with a relevant example of how exactly the very corner case where Rufus will not start in portable mode will affect you, you are trying to use philosophical arguments, and "feelings". You do realize that the only consideration I take into account when trying to fix an issue is not how a user "feels" about it, but a real-life, reproducible example, of how the issue is actually affecting them.

what I got back sounded to me more like, "who cares, I can't be bothered"

That's not what you got. What you got is: "I still don't see how exactly this affects you, and I surmise that this is a preemptive request (i.e. one that is not attached to a real-life scenario), because you probably erroneously thought that a version of Rufus that doesn't contain a p in it's name cannot run in portable mode, whereas it only takes a rufus.ini in the same directory for any version of Rufus to start in portable mode. So I will explain this to you, and, if you are still convinced that you will end up in a situation where the updated version will not start in portable mode, wait for you to provide a real-life scenario that clarifies why you would download the updated version in a directory that doesn't contain the existing rufus.ini (which again is the only way Rufus will not start in portable mode)".

by how trivial I perceive it should be to fix and be done with

Ah, the good old _Why can't you just add the feature I want? I mean, you're a developer - it shouldn't be that hard!_

I'm afraid it's not that trivial, because one thing you don't realize is that the download link is hardcoded on the update notice on the server, so now, either I have to create different update notices for the portable and non portable versions, or, more realistically, modify the download URL and insert a p. But then what if someone is using the non p version of Rufus, but with an ini file in the same directory, and relying on that feature to be able to share the regular version (because while that person knows they have a need for portable, whereas most of the users they'll be sharing Rufus with won't). For what is worth, while unlikely, this is still a more probable scenario than anything I've heard from you on why you think you MUST have a p version downloaded. So now, I have to do add more fine grained description of the level of portability I currently set, to figure out when I should really change the name. Still not that big a deal. However, and this is actually the important part I consider when deciding to add a feature, which is also the one most people who request such features tend to overlook, any feature needs to be regularly tested for breakage. So now that's another minor feature I need to keep track of, and, ideally, on every new version of Rufus I release, I need to test that the portable and non-portable downloads work. Well, considering that I still haven't seen any good justification as to why that feature should be added, and I'm already busy as it is on release days, I'd rather go for more stability with one less feature (especially as I already carefully considered why there wasn't much point adding it), than add a feature that might be used by one guy (who still hasn't been able to properly justify why he actually needs it).

But you're probably right, it won't affect many users at all. Just brand new ones who see there's a portable version, and don't expect it to magically become non-portable when they do something with it that you consider to be 'unlikely' -- which somehow tends to end up being precisely how any given product WILL be used, far more often than we'd ever have imagined

Please provide me a valid scenario of that then, which is what I've been asking all along (a vague "that will happen" is hard to take seriously). I have no problems reconsidering the inclusion of a feature when I see hard evidence for it. But as long as you, or anyone else, is unable to provide a good reason as to why they will be likely to save the updated Rufus in a directory that is different from the one they are running the existing one from, I really don't see any reason to change the current application behaviour for update downloads.

It's a nice little utility. So much so, that I don't see much in the way of settings that need preserving - that's why I was talking about a scenario in which settings explicitly wouldn't be preserved, including, surprisingly, its portability! Having what settings it does decide to save, saved into an .ini file, means delete two files and it's gone without a trace. That's exactly what I want, and why I prefer portable apps for things like this - it really is that simple.

I started this as a first-time user of the product, with a circumstance in which it behaved surprisingly and contrary to expectation - as a first time user, not as a developer or as someone already familiar with the product. It's that insight which is why developers get other people to test their products, and why companies have entire departments devoted to user interaction. The perspective of a first-time user is an all too rare thing, so when I came across a situation which I felt goes aɡainst fair expected behaviour, and seemed to me like something particularly readily overlooked by established users and potentially especially the developer, I made it a point to mention it. Again, it's that simple.

This is probably a matter of personal opinion to some degree, but while my use case which brought this to light might be odd and unusual, I can guarantee I won't be the only person doing this - there's always an order of magnitude more people who put up with an issue silently, than who actually say something. And as developers, it's often easy to loose sight of the regular person using a product, who just wants it to work in a nice obvious and consistent way. I put in the time to sort through three or four applications that seem to do the same thing, and so I don't forget about the one I ended up settling on, I'll be storing it away for future reuse. Part of that process, was deciding whether to download the portable or non-portable version. When I go to use it again, likely a good while from now, and decide to accept the upgrade suggestion, it'll have silently changed an aspect of it's default behaviour, and an aspect that was specifically part of my choice to download this version (and to some degree, this application) to begin with. It's that silently part with which I have the greatest issue - if you can't preserve the default behaviour over an upgrade, then I'd rather it just send me to the change notes page with the download links so I can decide for myself.

To be clear, I'll explain my expectation of a portable application: The portable version of the application (especially being a single-file application), and without any further direction (as in from an .ini file the application itself generates), will run portably.

And to re-iterate my issue: The rules of portability, from the perspective of someone not familiar with the application, are changed by upgrading the application, using the built in upgrade functionality. At it's most basic, if I download the portable version, I rather expect it to remain the portable version - your opinion of how or why I use it is mostly irrelevant. I'm not trying to be rude there, it merely goes back to fair expectation of someone using your product, having chosen which version to download for reasons you're not expected (and perhaps even wanted) to know.

You are right, I wasn't aware how the update is driven, but I did have a suspicion it would be something like that. Personally, I feel that hacking in that p is a little... unclean. It would be preferable if the name or url of the portable version could be included in the notice, or even that a second notice channel exist in parallel (either generated with the original, or from it), but if neither of those are a possibility... But in either case, the upgrade should be consistent with the version that was running, or a means provided to change that.

And for the record, due to the infrequency with which I deal with USB drives, it took me a few moments to figure out which settings I needed to change. For my wife, children, and a good number of friends I know, many of whom call those devices "giggi sticks", they'd be simply doing what they were told or read, with no idea what many of those options do. But even many of them would recognise that the ini file means it saves it's setting there, and would fairly expect that copying the application to another directory (or even several other directories) would allow for different configurations. Most such people do it regularly with games, and I've done it myself with programs in the past. Your upgrade policy breaks that, and worse still, it'll work a few times, and then mysteriously stop working, and even I would have been hard-pressed to figure out why without at least a couple minutes of frowning and frustration.

In terms of solutions... I would recommend, starting with most preferred:

A small check-box next to the download button (even hidden within an 'options' drop-down), pre-loaded with the current portability of the application.
A message pop-up warning that the version being downloaded will be the non-portable version, and offering a link to the download (or update notes) page instead.
Or a pop up a quick dialog with radio buttons for the two versions, and the appropriate one pre-selected (though personally I'd only go that route if there were more than two options, and you have the means to provide a list of available options through the upgrade notice).

Again, I fix real-life issues, when someone provides me with a real-life scenario, and not philosophical aspects such as "but the app silently changed an aspect of it's default behaviour!". Despite what you'd like to believe, your perspective on that issue is not representative, and, unless there's a real-life scenario with verifiable drawback involved, software companies do not modify features according to a single person's specific likes or dislikes. Considering that about 2 million people download Rufus each month, that the update process has been here for some time, and that people who care about portability are VERY VOCAL about it (I got asked to provide a portable version of Rufus a lot before there was one), the fact that yours is the first report to complain about it, moreover, with a complaint that was based on an erroneous assertion, provides me with better information with regards to the importance of this non-issue than your "I can guarantee I won't be the only one".

Also, you confirmed my initial assertion that you erroneously thought that the update process would break portability, and went into reporting this issue with the idea that you were reporting a glaring bug, so I also have to consider that your insisting might simply be trying to save face after being proved wrong.

Finally, FYI, Rufus does have a "remove all traces" mechanism even when not running portable (Alt-R). Granted, it may not be as convenient as removing 2 files, but it is there.

Oh please... Download counts are meaningless here - unless you have the data to isolate a relevant sample for counting, and you haven't even hinted that that is the case, plus the very issue we're discussing will skew such data anyhow. As you have confirmed, only people copying the executable without the ini file, since upgrading, will have even had a chance to notice. Can you tell me how many of them are among that 2 million downloads? And how about how many of them just shrugged and either decided not being portable any more didn't matter, or like me, straight away went back to the site to get the updated portable version? That's going to skew your download count either way, particularly with relevance to this issue.

And no, this thread was always about that one thing: transferring the post-upgrade executable alone to another location, will cause it to run non-portably!. And that fact has been confirmed by you!

I'll repeat that, because if anyone is making erroneous assertions here, and has reason to be concerned with being proven wrong, it's You. I asserted, and you've confirmed, that the version downloaded by the upgrade feature has the default state of being non-portable, regardless of which version was originally downloaded. And I also never said it was a "glaring bug", I said it was a small issue, and my increased insistence isn't a result of any concern about saving face, I've already pointed out I considered your response rather, undue (trying to keep things civil).

At the very least, I'm sure you can see the appropriateness of showing a quick warning dialog indicating the upgrade version will not default to being portable, and provide a clickable link to the downloads webpage. And perhaps while you're at it, have a think if maybe there's some way you can find out for certain if, just perhaps, it IS a bigger issue than you realise - I know I would.

Now, please stop trying to distort my intentions. I believe I made my issues very clear in the last post, and you have done nothing at all to address them, beyond once again stating - using seriously flawed statistics and an "erroneous" attack on my quite accurate assertions - that you don't think it's worth the effort. The application did "silently change an aspect of it's default behaviour", and I do consider that to be a significant issue for reasons I've already stated both practically and personally.

Further, since you appear to have made your mind up regardless at least one reply ago, and considering you are the all-knowing developer, I am merely a user who went to the effort of posting a bug report, yet despite that you've gone to such an awful lot to trouble to argue your point while repeatedly ignoring and attacking both me and mine... I really do believe that in fact it is YOU who are trying to "save face" - quite honestly, I really don't have any face to save. It's up to you in the end, as the developer, but do at least try to be honest about it - I have a minor but valid issue, and you simply don't think it's worth bothering about.

Sorry, but you posted a flawed bug report for an issue that didn't exist, and then you had to completely change course about what the "actual" issue was in an attempt to try to make it relevant. You tried (and failed) to bring in dropbox in the equation and then tried to bring more irrelevant elements in an attempt to prove a point that was never there.

So, please consider that 2 very specific conditions need to happen for this to qualify as an inconvenience for a Rufus user ("inconvenience" because it will NEVER prevent Rufus from performing its job equally well in either case):

Someone, who knows about portability (since they were using the portable version in the first place), has to forget to copy the obvious .ini file that resides in the same directory, when they copy the executable.
Even if the above was intentional, the receiving person (which is likely to be different from the first one, as it makes little sense to me for the originator to want to copy their portable settings if they plan to use Rufus elsewhere) has to care very strongly about portability.

Then, and only then, might the person who got the copy get slightly inconvenienced...

If you still want to try to pass a mild inconvenience which, as I stated in my second reply "I fail to see how it will affect that many users" (since I have never shied away from mentioning that, in some corner cases, it is possible that it will indeed affect some users), as some kind of critical bug that needs fixing and that I have no excuse for not wanting to address, be my guest.

But don't be surprised if I no longer bother trying to explain to you why this minor inconvenience doesn't actually deserve a fix, because it'll only potentially affect users who both copy Rufus in a manner where the .ini file won't be preserved and are paranoid about portability (and those people will probably be annoyed either way anyway, when they realize that, no matter if you run it in portable mode, Rufus still indirectly modifies registry keys).

Mate, this is getting rediculous. First up, about erroneous assertions:

Seems to me the very first mistake, was in your reading of my very first post. Although I didn't say it in such precise terms initially, my assertion was then and is now, that "the upgrade function silently changes the default portability of the application".

So where exactly did I "completely change course"? I'm STILL saying that the default portability of the application changes on upgrade, and it was what I was saying from the very first post. The only thing that has changed, is that I'm saying it BETTER, now, than I was then. And I never said it would inconvenience current users, or users taking their configuration with them (because quite frankly I didn't know, and assumed that would be a little too obvious to go unnoticed).

And what's this "some kind of critical bug" business? My very first words were, "Just a tiny issue". We've no doubt spend longer debating the issue, than it would have taken you to check whether the executable had a p in it, and download the same version to replace it, or as I suggested more recently, put up a small notice dialog indicating that the version being downloaded isn't the [defaulting] portable version.

Now on with the meat of the real issue:

Again, my issue is the surprise factor: it should never surprise its users by silently changing an initial choice that they made when choosing which version to download - put really simply, if you offer a choice of version, you should respect that choice through upgrades, not decide to just change the users mind for them! That fact right there is why I made the crack about having doubts as to the trustability of the development - I chose to download the portable version, it should be upgrading to the portable version in keeping with that choice, regardless of what you think of it, or at least inform me when the transition happens! It's the silent changing of MY choices that is so very wrong - and yes, I get that that is a little philosophical, but it's also very much practical since you have no way (nor need to) of knowing WHY I made those choices.

And on the note of Rufus installing registry keys regardless of its portability - which I do actually consider to be "some kind of critical bug" - makes me wonder if you shouldn't just ditch the Portable version anyhow. (You appear to have a measure of contempt for it.) Of the two points made there, #2 is fine, though one has to wonder about #1. These would seem to be entirely your keys, in your control, for your use - what exactly prevents you from storing those keys in the ini flle?

the very first mistake, was in your reading of my very first post

You mean, the one where you stated that "it grabs the non-portable update", which is 100% wrong (since any Rufus executable is both portable and non portable)?

So where exactly did I "completely change course"?

Obviously, your second post, and then once more, after you indicate that you will keep Rufus in a dropbox folder, and do care about portability, only to retcon your usage scenario into one that doesn't seem to make much sense, and where you are not going to copy the ini file...

The only thing that has changed, is that I'm saying it BETTER, now

No, the only thing that has changed is that I helped you latch on the only scenario where someone might be slightly inconvenienced, but now you're too far in this to acknowledge that, at worst, this will be a minor inconvenience for the handful of people who may copy an updated version of Rufus without an ini, yet care that much about portability, and are still trying to make a HUGE DEAL about what I have correctly anticipated (due to the zero actual reports of people complaining about that corner case) is essentially a non-issue.

And what's this "some kind of critical bug" business?

The criticality is with how you are still trying to push for this non-issue to be fixed. All your recent posts have been with trying to convince people that, unlike what you might have been saying earlier, this is a big deal. You can't really go around stating that something is "very wrong" and then pretend that it's minor, can you?

my issue is the surprise factor

And here we go again, in trying to change the angle and morph the issue into something it's not.

It's the silent changing of MY choices that is so very wrong

Yes, it's very clear to me at this stage that the issue is how you believe that YOU may be affected in the future, by something that, as I stated many times, is actually unlikely to affect you if you do care about portability (because then you will keep an app's ini file), and are therefore trying to make it look like it's one of the worst thing that a Rufus user could experience (again: "so very wrong"...).

you have no way (nor need to) of knowing WHY I made those choices

Precisely why I try not to let a single user report decide whether something warrants a fix, but will instead consider the likelihood that others will be affected by a similar "issue", especially when that user's report morphed into something quite different from their original entry along the way, and they tried to justify the importance of the "issue" with scenarios that either were unrealistic, made little sense, or tried to go with such arguments as "Well, I'm sure if you had user panels, they'd think just like me, because I'm representative!" or "Your 2 million downloads/month, with nobody complaining about this except me, don't mean anything".

what exactly prevents you from storing those keys in the ini flle?

Point 1. is about what happens when using the default version (i.e. "non-portable" though this is actually a misnomer -- but one I don't have a problem using), because even people who use the non portable version might want to know whether a small application, that they probably think doesn't really need to do anything with the registry, may still end up modifying the registry. Please do realize that not everything is aimed at discussing the portable version. So, of course, the settings highlighted in 1 are written to the ini and not the registry if you use the portable version. Besides, I was hoping that the "even if you use the portable version" from point 2. would give a hint that point 1. did not apply to the portable version.

So, once again, you are wrongly assuming that a problem exists where there isn't one, which, in essence, is the one major issue I've had with your entries all along, even more so as you also indicated in one of your posts above (I quote) "You are right, I wasn't aware how the update is driven" (even if, in that same sentence you try to reduce the weight of this statement with "but I did have a suspicion that...").

Maybe then you'll finally start to understand then that, because you have repeatedly provided hints that you didn't really understand how Rufus actually works, and are now trying to twist a minor potential corner case inconvenience into something that it isn't, I am having trouble taking your insisting that, what is a very deliberate design decision, "is so very wrong", seriously

At the very least, I expect it to be exceedingly obvious that, NO, I'm not going to do anything to address a corner case behaviour that I have been fully aware from the day I added portability, and that I consider a complete non-issue, mostly because portability in Rufus was designed in such a way that there is actually no such thing as a "portable" or "non-portable" version in the first place.

You mean, the one where you stated that "it grabs the non-portable update", which is 100% wrong (since any Rufus executable is both portable and non portable)?

It is the non-portable update in that if I run it without any configuration in the system, it will behave non-portably. How it is written, is irrelevant - how it behaves, is everything.

Obviously, your second post, and then once more, after you indicate that you will keep Rufus in a dropbox folder, and do care about portability, only to retcon your usage scenario into one that doesn't seem to make much sense, and where you are not going to copy the ini file...

It was in my Dropbox folder before I made my first post, and I have used that folder exactly the way I described on several occasions. I've been doing basically what I described since 1997, with a webpage on my University account, then a USB drive for a few years, now Dropbox. One of the best things about using Dropbox, is that it's non-writable when accessed over the webpage from a foreign machine. My typical usage, was sitting at a friends computer fetching and running Putty to "call home" (even had PAM configured for one-time use passwords). You can't know that, but I did point out that also in that folder is Putty, which should have indicated this is something I've been doing for a while, not just a scenario I'd dreamt up on the spot as you seem to be implying.

However, when running it on my home system, it will have its ini file, and I will have to remember to portabalize it... not that it apparently actually matters... Perhaps another idea, would be simply to not save ANY settings, registery or ini, unless told to do so. I think in your shoes, with a tool like this, I'd probably go that way - choose good defaults and don't save anything unless there were settings already present at start-up.

The criticality is with how you are still trying to push for this non-issue to be fixed. All your recent posts have been with trying to convince people that, unlike what you might have been saying earlier, this is a big deal. You can't really go around stating that something is "very wrong" and then pretend that it's minor, can you?

The interesting thing, is you've convinced me that there's more of a big deal going on here than I'd originally thought, and most of this conversation has been trying to get you to understand my point of view - it's your product, and you will answer it as you deem appropriate, but independent of whether you agree and actually make any changes, you simply can't adequately answer an issue you don't understand. And your accusations of erroneous assertions and assumptions, and use of dodgy statistics and other obvious tactics, tell me that you don't understand what it is I've been trying to express.

Some things you have confirmed, are also rather, troubling. The contempt you seem to have towards the portable mode, and those of your users who wish to run it that way. This reeks of a "I don't want to do portable, but I was badgered into it, so I'll do it, but I'm going to make it a little broken and inconvenient, fob it off as how things are in the fine print, and just wait for them to get over it and stop bothering me about portability".

And here we go again, in trying to change the angle and morph the issue into something it's not.

Yes, there has been a shift in focus, I agree... But the issue is still the same as specified in the original post - I expect that, if I download the portable version, for it to STAY the portable version. And yes, so long as it retains it's existing configuration, it will do so. But the updated application will not set itself up portably like the original did, and I was not given ANY notification of this fact. That IS an issue.

I don't care if you fix it to download the portable version, or just display a notice that this is the portable version, but it's about to upgrade to a non-portable one (and provide a clickable link to the download page), as long as you don't simply silently change the users choices. Again, that IS an issue!

Yes, it's very clear to me at this stage that the issue is how you believe that YOU may be affected in the future, by something that, as I stated many times, is actually unlikely to affect you if you do care about portability (because then you will keep an app's ini file), and are therefore trying to make it look like it's one of the worst thing that a Rufus user could experience (again: "so very wrong"...).

Well of course it's about how it effects me... I don't know the actual number of people who do the same thing as I do, any more than you do. It just so happens that I can guarantee there'll be at least a few of your users doing the same thing, who've probably either moved on to other products, or just shrugged and always go back to the download page to get the portable one instead of using the built-in upgrade functionality, just like I did, and would have continued to do had you not mentioned it's simply a naming convention. THAT is why I consider it a bug that needs to be addressed.

Precisely why I try not to let a single user report decide whether something warrants a fix, but will instead consider the likelihood that others will be affected by a similar "issue", especially when that user's report morphed into something quite different from their original entry along the way, and they tried to justify the importance of the "issue" with scenarios that either were unrealistic, made little sense, or tried to go with such arguments as "Well, I'm sure if you had user panels, they'd think just like me, because I'm representative!" or "Your 2 million downloads/month, with nobody complaining about this except me, don't mean anything".

I'm sorry if I somehow confused you, but the only morphing of the issue has been a direct result of you trying to corrupt and debunk my issue as frivolous and not worthy of consideration. My scenario is two decades old, maybe closer to three if you count floppy disks before that... I view my folder in Dropbox, no different to the multi-tool I keep in my pocket. Here, it's for when I need to do something on someone else's computer, and wish to leave a minimal amount of residue behind when I'm done. If I run rufus on a friends computer, they should not need not know anything about hitting Alt-R while running the program to remove its configuration. They should be able to delete the directory it's in, and have it just be gone. And yes, as the most computer-literate of my friends, I do actually find myself doing these things.

Please do realize that not everything is aimed at discussing the portable version. So, of course, the settings highlighted in 1 are written to the ini and not the registry if you use the portable version. Besides, I was hoping that the "even if you use the portable version" from point 2. would give a hint that point 1. did not apply to the portable version.

I am only interested in the portable version, this entire discussion has been about the portable version, so it was perfectly fair to assume that link was with reference to the portable version also! I am deeply gratified to hear that is not the case. But you may perhaps want to make it a little clearer... And if point 1 ISN'T applicable, I really don't see why you bothered with the link - of course it may need to make temporary changes in its operation, and of course Windows has a tendency to do other things behind the scenes that affect registry changes, there's nothing you can or should be expected to do about that, so long as it IS temporary (does it handle crashes cleanly? backing up the original settings to a file which it deletes when it's done, for example).

I would be perfectly happy if it stored absolutely no configuration what so ever, anywhere, until told to do so - that would totally remove the entire issue once and for all. I'm not even at all certain that I'll ever use it in the same configuration twice.

In the meantime, the core issue, once again, is that I downloaded the portable version, and I want it to stay that way - but in the context within which I am most likely to use it, it will not do so without extra work and inconvenience. The next time I use rufus, there will most likely be an updated version, and if that happens to be on my own machine, then I will need to remember that it's updating to the non-portable version, and take steps one way or the other to keep it portable.

Further, I am representative of a likely mostly silent group for whom rufus is a handy little tool to toss in the back pocket and pull out once in a distant while, and would probably never bother to update at all if it did the job and wasn't pushing the update itself. Those people, won't remember about that p, or the Alt-R thing, assuming they ever knew about them to begin with. Again, you're stance on those implies familiarity - which you have in abundance - where mine is of someone who rarely uses a tool like this at all, and would never have developed a familiarity. For such tools I prefer the portable version simply because it leaves less crud behind, particularly when one of my friends asks me to help them do something or other.

And I'd like one last time to re-iterate, even if you don't wish to actually change anything, then simply present a dialog if you're upgrading a p version, as a reminder that the new executable won't be portable by default - it'll only come up once an update, and will be beneficial to people who DO want to keep their version defaulting to portable.

How it is written, is irrelevant - how it behaves, is everything.

And how it is likely to be used is the most crucial. I can go about using superlatives too.

And yes, so long as it retains it's existing configuration, it will do so.

Which, no matter how you want to turn it, pretty much equates to "And yes, so long as someone cares about portability it will remain portable", which has always been my point. For the inconvenience to arise, one has to stop caring about portability by choosing not to copy their portable settings.

One of the best things about using Dropbox, is that it's non-writable when accessed over the webpage from a foreign machine.

Still don't see how that prevents you from accessing the ini. You do use dropbox in RW mode when you're not at a friend's, in which case the ini will be there.

Once again, you're trying to justify your usage scenario with another "Okay, you may have debunked the usage scenario I described earlier, but one very important thing I failed to mention then, that actually makes it relevant, is that...".

I'm sorry, I can only let that kind of reframing of a scenario slide once or twice before I call bullshit. If you use Rufus on a friend's computer and care about portability, you will of course download your ini file from dropbox. If you don't, then clearly you don't care about whether the app is portable or not, in which case you're clearly trying to pull everybody's leg with regards to this pseudo issue.

Oh, and spare me another trying to refine of your scenario with "But it's still possible that I might get the non-p version from dropbox, and no ini, because it got upgraded there", since:

If there is a non p version in your read-only dropbox folder, then clearly you had write access to that folder when the auto-update was running, which means that there must also be an ini file (as the autoupdate only runs while rufus runs, which means that a ini would have been created before the update could have been written, unless, and regardless of how many updates intervened, the very first version you had was actually the non-p version... which is contradictory to what we established was the premise for this whole thing)
You'd have to deliberately delete the ini from one of your home computer(s) even though you indicate that you care about portability (and are computer literate enough to know where that this is the place where a portable app will most likely store its settings).

If, as you state, you wish to leave the minimal residue on someone's computer, then you will download the app and it's ini file, which will reside in your dropbox folder, even if an update was downloaded, and it won't matter whether it contains a "p" in its name or not. Or, if you don't download the ini, then I will assume that you either don't care about leaving residuals, or are explicitly trying to create a non-realistic scenario for the sole purpose of trying to prove a point that has ceased to have much to stand on a long time ago.

tell me that you don't understand what it is I've been trying to express.

You're free to believe what you want (even if it's wrong).

However, please allow me to allow state that I have actually called you out, with proof, on actual elements which you did not understand, the last of which was your belief that point 1 from the description of registry changes applied to the portable version (again, if you are assuming that a general FAQ is going to specialise only in dealing with a portable version, you don't understand what the purpose of a FAQ is, or failed to try to get the context of what you are reading, and you therefore failed to understand that the reason I pointed to the specific FAQ entry was only because of point 2).

I don't know the actual number of people who do the same thing as I do, any more than you do.

I'm afraid that, as the developer of an application used by millions of people, with plenty of means of receiving input from users of said application, I can actually get a pretty good estimate of the number of people who do the same thing as you pretend you are going to do and are inconvenienced by it.

Regardless of what you want to believe, my inbox does show that there are some serious portability zealots out there (like the ones who complain that even in portable mode, Rufus may still modify the registry), so, if your best argument is "trust me on that", then I'll retort "trust me on this: if these portability zealots that I know do exist were doing what you are asserting you are planning to do, or if they were inconvenienced by it, I'd have had quite a few vocal complains by now"...

the core issue, once again, is that I downloaded the portable version, and I want it to stay that way - but in the context within which I am most likely to use it, it will not do so without extra work and inconvenience.

Bullshit. Even in your read-only dropbox scenario, it will stay that way, unless you actually stop to care about portability by deliberately choosing not to download the ini (which will definitely exist if you also have a non "p" version there).

Please stop embarrassing yourself by trying to come up with more implausible scenarios — you're not helping your "cause"...

The contempt you seem to have towards the portable mode

Don't conflate not giving in to your wish, because you still haven't been able to come up with a single realistic scenario to demonstrate that the current behaviour of Rufus will actually be an inconvenience for your usage, and being in contempt of portable users.

As I expressed above, I do have an issue with what I call "portable zealots", who are people who appear to completely miss the point of portability, some of which seem to treat any app that directly or indirectly modifies to the registry as if it was a virus. I really don't see how calling out a subset of people who are trying to use portability to push a completely different agenda qualifies as being in contempt of portable users. It's also a slap in my face with regards to the amount of time and effort I spent trying to devise the best possible solution for portable users (which doesn't stop with the code that was added, but also increased the amount of testing I need to perform with each release).

If your argument is going to devolve in trying to pretend that, rather than me having rationally analysed the likelihood of a corner case and concluded that an unlikely annoyance didn't need to be addressed, the only reason I will not give in to your wish is out of spite, I'm going to have to either respectfully ask you to stop this charade and finally accept a choice that, as far as I am concerned, I feel I have backed up in a rational manner every step of the way by asking for real-life scenarios (and then dismantling each one you proposed), or face getting banned from the Rufus issue tracker (which of course, if you want to continue in a childish direction, you may try to turn as an "I am being threatened of a ban because I speak the truth!").

Again, you're stance on those implies familiarity

On the contrary - I am also relying on the fact that a person who is unaware or forgets about the "p" vs "non-p" thing will not bat an eyelid at seeing a version of Rufus that doesn't contain a "p", therefore (rightfully) assume that the "non-p" version is as portable as the "p" one, and go about their portable business, by copying both the ini and the app if they need to use it elsewhere.

The more problematic people are the ones who are a bit more familiar with Rufus and think (wrongly) that having an update that doesn't contain a "p" spells trouble...

I am representative of a likely mostly silent group

Please wake me up when your group stops being silent then.

No developer, especially the ones that provide clear means of getting in direct contact with them, is going to address anything that involves people who keep silent about it. This is another non-receivable point.

even if you don't wish to actually change anything, then simply present a dialog

I'm afraid you fail to understand that modifying a dialog is, first, a change (so it doesn't qualify as "[not] chang[ing] anything"), and second, that it would actually be a major change in term of effort, as any new UI text means rallying 35 translators, some of which (as appreciative of their voluntary work as I am), I have been waiting for minor translation updates for more than 6 months now... Of course, that last part might not be something you may easily have guessed, but in terms of changes, anything that doesn't involve new translations is usually a lot less work than adding a new user-facing messages, and these days, I really try to avoid anything that requires new translation work, if I can.

Also, you clearly fail to understand that whatever new message I add about this would likely be super confusing for people who are not familiar with "p" vs "non p" thing, as I can't exactly state "what you're about to download is the non-portable version", because it would be completely incorrect, and adding something that states "Please be mindful that if you download this version, copy it elsewhere and don't copy your ini file, it will revert to portable mode (that is assuming you didn't create a blank .ini file or renamed it to something that contains a 'p')" is, in my view, pretty much the same as introducing a message that states "If you are running Rufus on Windows XP, and leave it open for more than 48 days, you may experience some strange behaviour due to timer limitations on that platform". Is that something that a limited set of users may run into? Absolutely. Is that something that enough users are likely to run into and that actually warrants a message? NO.

Any application out there does have many not so obvious limitations, or annoyances, or even straight up possible breaking behaviour, that developers are well aware of, and that, will get triggered in very specific circumstances. However, despite what many users seem to think, the job of a developer is also to estimate how likely said issue is likely to arise, and decide whether it warrants being addressed in one way or another. I do get that you may get annoyed when a developer chooses not to address the issue you feel might affect you some day, and therefore are trying to champion. But when the only elements you have to show for it are philosophical considerations, after every single scenario you put forward has been demonstrated to be either flawed from the onset, or so limited in its scope that it is unlikely to apply to anybody else but you, you might want to use your common sense and realise that it's probably time to let it go.

Which, no matter how you want to turn it, pretty much equates to "And yes, so long as someone cares about portability it will remain portable", which has always been my point. For the inconvenience to arise, one has to stop caring about portability by choosing not to copy their portable settings.

Seemingly contrary to your oppinion, minimal cruft left behind is also a valid use of portable applications - and the only one I'm particularly interested in where rufus is concerned.

Still don't see how that prevents you from accessing the ini. You do use dropbox in RW mode when you're not at a friend's, in which case the ini will be there.

That is my point - I don't want to access the ini. There's nothing in it that I need or want to take with me in such circumstances, I want a nice fresh instance, with all its usual defaults, and downloading both just to keep it in portable mode, means I'd actually want to keep a clean ini separate from my own, if for no reason than simply to be certain you haven't tossed some cached information into the ini that I'd rather wasn't being shared. Unlikely in the case of rufus, but you think this situation is irrelevant - who knows what issue you'll decide is irrelevant in the future.

Is it really so hard to comprehend that respecting the choice we make when we originally chose which version to download, is important to some people?

I'm sorry, I can only let that kind of reframing of a scenario slide once or twice before I call bullshit. If you use Rufus on a friend's computer and care about portability, you will of course download your ini file from dropbox. If you don't, then clearly you don't care about whether the app is portable or not, in which case you're clearly trying to pull everybody's leg with regards to this pseudo issue.

You're talking about portability of configuration, I'm talking about portability of the application (with containment of configuration). Different objectives, but the exact same mechanism - store any configuration in an ini file, if at all. And why? Because I have two basic uses for tools like these - one personal, one otherwise. There's no reframing going on, other than to expand on my usage scenario as you raised specific arguments. Simply put, I've needed to go hunt for tools to help out a friend often enough over the decades, that I've been keeping around handy little tools I've found and liked for ages now. I usually don't know when or what form that will take in advance, and the promise that I won't leave any undue crap behind is typically even more important to them - having a portable app makes it much easier because I can point at the ini, and say delete that and the application, and it's all gone. No Alt-R fuss to try and remember. I also make a point of explaining what I'm doing as I go, so having a fresh config also means there's no "and magic happens" section in between, which means there's a better chance that next time they won't bug me to help.

So again, as for reframing... No. My reasons were omitted initially to keep the bug report brief - it was never meant to expand into a 100 page essay. But the more we go through this, the more issues you drag up to explain why it's not worth bothering, and where that relates to my usage of rufus, I expand my explanation appropriately. I'm not going to write the story of my life as seen from portable apps, and I'm pretty sure you don't want me to either. But the base issue that prompted this whole thing, was to start with, and has continued to be, the fact that I want to be able to bring up Dropbox (currently) in a browser, download the executable (and ONLY the executable), and have it run in as minimal-residual mode as possible. The rest, has mostly been responding to your counter-arguments with discussion on how those issues would effect me and others using portability in the same way. As I said, I consider that Dropbox folder to be no different to the multi-tool I carry in my pocket - you take out the tool you want, do what you need to do, and try not to leave a mess behind when you're done.

In hindsight, the more optimal solution would likely be a dialog up font if it's operating in a mode contrary to its default (as specified by its naming), with one of those "click this to hide this message" check boxes, backed with a command-line option to force the portability one way or another. I've never needed to do portability, but I spend some time thinking it through earlier, and I'm pretty certain that's how I'd do it. It's a common enough pattern, and with good reason.

Oh, and spare me another trying to refine of your scenario with "But it's still possible that I might get the non-p version from dropbox, and no ini, because it got upgraded there", since:

If there is a non p version in your read-only dropbox folder, then clearly you had write access to that folder when the auto-update was running, which means that there must also be an ini file (as the autoupdate only runs while rufus runs, which means that a ini would have been created before the update could have been written, unless, and regardless of how many updates intervened, the very first version you had was actually the non-p version... which is contradictory to what we established was the premise for this whole thing)

What "read-only drobbox folder"? You do realise Dropbox lets you access your files through a standard web browser, right? And that your folder can be accessed thus without any need of an account. I can also (and have done) simply email someone a link to a file there. I can't imagine using rufus that way, but it's an available option. (I have told friends to "go to my public toolbox folder, get such-and-such, and just use that" before, when I've been speaking to them on the phone while I'mout - even from the waiting room of a medical clinic, for example. There's a good chance I won't even remember what the saved configuration is, let along want them to use it.

None of this has anything to do with how I use it on my own machine. As it is, I can take advantage of the auto-update functionality because I can't imagine there being anything in the ini that I wouldn't want shared, so next time I use it I'll probably link it from there back into a more practical folder, so that it's easier for me to get to, and will (hopefully) update in-place. (You can probably answer that for me now.)

But I'll restate, one more time, any "reframing" or "redefining" of my scenario, are merely parts of the same original whole - as I've already stated I tend to end up being the local computer problem helper / fixer upper for a bunch of friends (and occasionally family, friends of friends, etc.), and I've been doing this over three different mediums just recently. The exact specifics vary from occasion to occasion, but they're all the same - and when I found portable apps for the first time, I realised their applicability to that role, and ever since then whenever I find a nice small useful tool with a portable version, I prefer prefer it over non-portable ones.

You'd have to deliberately delete the ini from one of your home computer(s) even though you indicate that you care about portability (and are computer literate enough to know where that this is the place where a portable app will most likely store its settings).

... or just not download it to start with - the preferred situation.

If, as you state, you wish to leave the minimal residue on someone's computer, then you will download the app and it's ini file, which will reside in your dropbox folder, even if an update was downloaded, and it won't matter whether it contains a "p" in its name or not. Or, if you don't download the ini, then I will assume that you either don't care about leaving residuals, or are explicitly trying to create a non-realistic scenario for the sole purpose of trying to prove a point that has ceased to have much to stand on a long time ago.

... or just want a fresh install without any hang-over configuration.

However, please allow me to allow state that I have actually called you out, with proof, on actual elements which you did not understand, the last of which was your belief that point 1 from the description of registry changes applied to the portable version (again, if you are assuming that a general FAQ is going to specialise only in dealing with a portable version, you don't understand what the purpose of a FAQ is, or failed to try to get the context of what you are reading, and you therefore failed to understand that the reason I pointed to the specific FAQ entry was only because of point 2).

Oh give me a break. You presented a specific FAQ entry, in circumstances that only partially apply, without stating that fact. I wasn't about to read the entire thing, and I already conceded that misunderstanding. It was also very recent, and has almost no bearing on the entire remainder of this conversation, except as another attempt to undermine my argument through personal attack. The way you've clung to and twisted that rather tenuous success, makes it sound like you expected me to not read further into the FAQ (which I actually did do a few hours later when I had more time), which I could well imagine of someone who presumably wrote the FAQ and has certainly dealt with this issue previously (despite your protests to the contrary). When providing a reference, it is bad behaviour to not express the limits of that reference: I count that further evidence of my own towards your character as a trustworthy developer, on top of your rather flaky regard your users choices. Success by trickery is not success worthy of the trust users of your product are putting in you.

Regardless of what you want to believe, my inbox does show that there are some serious portability zealots out there (like the ones who complain that even in portable mode, Rufus may still modify the registry), so, if your best argument is "trust me on that", then I'll retort "trust me on this: if these portability zealots that I know do exist were doing what you are asserting you are planning to do, or if they were inconvenienced by it, I'd have had quite a few vocal complains by now"...

It's taken you this long, and you still haven't figured out what I am doing, so ghod knows what you think they're wanting. Going on about "read-only dropbox folders", half of them could be calling for exactly this, and I'm not convinced you'd know it. You might be able to write a decent tool, but your communication comprehension skills seem to be significantly weaker than mine, and I'll be the first to admit mine aren't too flash.

Bullshit. Even in your read-only dropbox scenario, it will stay that way, unless you actually stop to care about portability by deliberately choosing not to download the ini (which will definitely exist if you also have a non "p" version there). Please stop embarrassing yourself by trying to come up with more implausible scenarios — you're not helping your "cause"...

I'm not sure Dropbox even does read-only... The local filesystem might, if Dropbox doesn't go and reset it on you. Can't say I've ever cared to look. But I did mention previously, I was talking about read-only due to the Dropbox webpage interface, not mounted on a local file system - mounting my Dropbox on a friends computer is a positively insane idea, how can you possibly imagine I'd have even contemplated doing that?!? Or did you miss that bit too?

Don't conflate not giving in to your wish, because you still haven't been able to come up with a single realistic scenario to demonstrate that the current behaviour of Rufus will actually be an inconvenience for your usage, and being in contempt of portable users.

No, it's your use of personal attacks, dodgy statistics, you're inability to comprehend what I've been expressing, insane refusal to accept anything I present as reasonable despite my repeated stating that it's all still the same issue.

As I expressed above, I do have an issue with what I call "portable zealots", who are people who appear to completely miss the point of portability, some of which seem to treat any app that directly or indirectly modifies to the registry as if it was a virus. I really don't see how calling out a subset of people who are trying to use portability to push a completely different agenda qualifies as being in contempt of portable users.

Who, prey-tell, are you to tell me what portability means? To me, it means keeping your configuration contained within an ini file alongside the executable. Whether that gets used to take your configuration with you, or to contain your configuration while travelling, is irrelevant. It's not your place to judge how the program will be used, or you'd have to start checking images for pornography and all the rest. That's why your part ends at implementing a useful feature in a way which is effective and consistent with expectations - what happens from there isn't, and shouldn't be, your concern.

It's also a slap in my face with regards to the amount of time and effort I spent trying to devise the best possible solution for portable users (which doesn't stop with the code that was added, but also increased the amount of testing I need to perform with each release).

The slap in your face, is your own stubborn pig-headded response and egotistical abusive attitude. I have tried to respond to all your concerns thoughtfully and with further explanation when and where it seems necessary - while you take every opportunity to twist (and seemingly manufacture) ways to attack my sincerity, and simultaneously in a couple cases ignoring fair responses until I bring your attention back to it again in a later post.

If your argument is going to devolve in trying to pretend that, rather than me having rationally analysed the likelihood of a corner case and concluded that an unlikely annoyance didn't need to be addressed, the only reason I will not give in to your wish is out of spite, I'm going to have to either respectfully ask you to stop this charade and finally accept a choice that, as far as I am concerned, I feel I have backed up in a rational manner every step of the way by asking for real-life scenarios (and then dismantling each one you proposed), or face getting banned from the Rufus issue tracker (which of course, if you want to continue in a childish direction, you may try to turn as an "I am being threatened of a ban because I speak the truth!").

I'd say ego, rather than spite -- you've backed yourself into quite a corner here, much more so than you accused me of earlier... And dismantling might have occurred if you'd demonstrated solid comprehension of what I've been stating, and the same reference awareness that you expected of me regarding the FAQ. Plus, I'm quite aware, and have already stated, his is your product, your choice, and you've seemingly already made up your mind, with a product that I probably won't use more than once every couple years. Practically speaking, it's no skin off my nose whether you adopt my case or not, but I do happen to consider it relevant and significant enough to put in the effort to at least know that you understand the points I'm trying to express. All the side issues, your trustworthiness, user expectations of how the application will work with regards to portability, are things that I consider important enough to stand on their own - and as a bonus, I'll certainly appreciate them when they're there.

On the contrary - I am also relying on the fact that a person who is unaware or forgets about the "p" vs "non-p" thing will not bat an eyelid at seeing a version of Rufus that doesn't contain a "p", therefore (rightfully) assume that the "non-p" version is as portable as the "p" one, and go about their portable business, by copying both the ini and the app if they need to use it elsewhere.

... and utterly ignoring the question of whether they'll even notice the difference to begin with (either in the naming or the portability), until it does become an issue for them - and having participated in informal tech support enough so to greatly feel sorry for a few friends who've done it more formally (one relative included), I'd say you've got a fair few more people in that boat than you'd imagine. Secondly, when you're stressed and dealing with at least one issue already, you're not likely to notice a little thing like the absence of a p - if you're used to it being portable, and stressed at another issue, you're very likely to forget an issue like this and just run with the upgraded version and keep going, with the issue turning up some time later when you've long since forgotten that you even had done an upgrade. Like I said, you're assuming familiarity - even long-term users who are all into portability, quite possibly because they too find themselves doing impromptu tech support, could fall prey to something like this without realising until after they have set it loose on someone else's system.

Again, it's the silence of it that bothers me more than anything. I didn't state that initially because I was trying to be brief, and if I didn't state it immediately following, it was because I was a little startled and distracted, as I've also acknowledged and apologised for already.

The more problematic people are the ones who are a bit more familiar with Rufus and think (wrongly) that having an update that doesn't contain a "p" spells trouble...

I'm hoping once you stop being defensive long enough to actually get a solid grasp of what it is I'm actually trying to get across - all of what I'm trying to get across - you may re-evaluate your perspective on that. And to that end, I am willing to hash this out as far as it goes, and work through each and every issue you raise with you, even though my gain from this will be minimal at best

I am representative of a likely mostly silent group Please wake me up when your group stops being silent then.

That'll probably happen when they realise there's something to not be silent about, and that it's not their fault. Everyone gets so used to computers playing up, that there's a tendency to assume they've done something wrong, or that it's just another piece of the usual state-of-the-crappy software.

I'm not a portability zealot, but I am a bit of a quality zealot, I'll admit, and I detest the state of software quality these days - too many people slapping together half-baked products and pushing them out as finished. (Probably, and why I made that disclaimer fairly early on in the conversation, at least partly because I'm used to an environment where small mistakes become very big problems.) But mostly, I want to be able to trust YOU as a developer, when I'm running your product on my system… Being a responsive developer is encouraging, but I have to say, I'm not reassured by that continent-sized chip you seem to have on your shoulder there. Still, programmers tend to get shoved in cubicle's and back rooms for a reason, I guess... (That last was humour, by the way.)

No developer, especially the ones that provide clear means of getting in direct contact with them, is going to address anything that involves people who keep silent about it. This is another non-receivable point.

Now that's not exactly true, either - it's also called anticipating your users needs, and a regular part of growing any product's market. Maybe not so much a little niche tool like this, and at this end of the products lifetime, but definitely earlier on, and every time you do add a new feature or some new UI, or if you happen to see a potential issue before someone gets around to mentioning it to you. But that's getting a bit philosophical again...

I'm afraid you fail to understand that modifying a dialog is, first, a change (so it doesn't qualify as "[not] chang[ing] anything"), and second, that it would actually be a major change in term of effort, as any new UI text means rallying 35 translators, some of which (as appreciative of their voluntary work as I am), I have been waiting for minor translation updates for more than 6 months now... Of course, that last part might not be something you may easily have guessed, but in terms of changes, anything that doesn't involve new translations is usually a lot less work than adding a new user-facing messages, and these days, I really try to avoid anything that requires new translation work, if I can.

Now who's getting philosophical... I meant - and I'm pretty sure you do know - a change to existing behaviour with respect to the upgrade functionality. But since it is a full message, not just a short UI element fragment, the precise accuracy isn't quite so important, so you can get away in the meantime with putting in the English version, alongside a Google Translate-ism, and a small note at the bottom identifying it as such pending the proper translation.

But then with all the people you apparently communicate with, you could also crowd-source it - ask them how best to phrase it if you're unsure, and to validate your Google Translate-ism's. Or failing even that, and particularly in the case of my most recent (and simplest of all) suggestion, stick it on the translation queue and simply only present the dialog if there is a translation available. It'll take little more than checking if a translation exists, and if so, launching the standard Yes/No question dialog to decide whether to continue with initial configuration or just exit immediately - testing included, unless there's something very wrong with your testing framework.

Any application out there does have many not so obvious limitations, or annoyances, or even straight up possible breaking behaviour, that developers are well aware of, and that, will get triggered in very specific circumstances. However, despite what many users seem to think, the job of a developer is also to estimate how likely said issue is likely to arise, and decide whether it warrants being addressed in one way or another.

Of course they do, there are occasions when the fix causes more issues than it solves. But this isn't such a case. With such a trivial fix as this latest suggestion - and it's been a while since i looked at the Windows standard dialog API, but I can't imagine it being much more than trivial, especially before the application has even gotten started yet - I'd consider this more in the realms of being conscientious.

Heck, I'd offer to do it myself, but the last time I wrote anything significant that ran on Windows, I couldn't afford 32 bits, let alone one with a math coprocessor. So I imagine it'd be more work for you checking - and probably rewriting - my submission. And the couple occasions I have written anything like an application of my own on a PC, it used the GTK library, .so's, and not a .exe in sight. (Although there was the odd .ini here and there..)

I do get that you may get annoyed when a developer chooses not to address the issue you feel might affect you some day, and therefore are trying to champion. But when the only elements you have to show for it are philosophical considerations, after every single scenario you put forward has been demonstrated to be either flawed from the onset, or so limited in its scope that it is unlikely to apply to anybody else but you, you might want to use your common sense and realise that it's probably time to let it go.

Again, I'm not annoyed that you're not putting in my pet feature request. I'd love to see the ability to explore the Image/ISO to ditch files I don't need, massage features and filenames that might have gone wonky, and so forth. (As it turns out, something had in fact gone wonky, and I ended up using a bare bootable format and putting the needed files on myself after the fact.)

However, I am dismayed that you consider it of so little relevance as to put more effort into such aggressive dismissal of it - and me - rather than at least making certain understand WHAT I am asking for enough to so much as state it correctly. Now, on the way other side of the field, if you'd instead made a closest-to-acceptable suggestion of your own, and then provided reasons not to go ahead with it, I'd have tried to reason through those issues as I have done, and/or find an alternative without those issues, but then I'd have been inclined to let it go at that - at least I'd know I've been heard, and feeling a heck of a lot more comfortable with you as a developer - with or without a resolution in my favour.

That is my point - I don't want to access the ini.

I know.

And I've been trying to tell you that, even if you seem to think that it's your God given right to DEMAND that, should you use Rufus in that very specific scenario, it should somehow try to twist the meaning of "portability" into something that the term was never meant to convey (I'll come to that), it doesn't make much sense for anyone who actually understands what the term "portable" means to do what you will be doing. THEREFORE, because I have to consider that the majority of Rufus users will actually be more sensible than that when it comes to the only contract of "portability" implies in an application, between the developer and its users, I do not think you have much if a case, if the only basis for your case is "I should be able to skip the ini".

Let me repeat that again, so that it's abundantly clear: Considering that, as we have previously established, there should always be an ini displayed at the same location where one user gets the updated version of Rufus, I do not see ANY reason for anyone to not want to pick that ini file unless:

They wrongfully believe that the term "portable" implies/implied something different than "the ability to have both the application and its settings in a location that is portable (so that things can be preserved when switching computers)"
They understand the semantic meaning of the term "portable" and are interested in using the application in a portable fashion (since that's the one they originally picked in this scenario), but fail to grasp that one needs to copy the readily available ini to do so.

Well, none of these reasons are anything close to something I would ever consider as warranting developer action, because, as I stated many many times before, and regardless of whether you disagree with my assessment or not (but if you do, then you'd better have something better than "I'm sure you're wrong" to prove it), they are VERY UNLIKELY to negatively affect many users, if any at all.

Now, since the first item seems to be the basis of your point for deciding not to copy the ini, I'm sure you'll find reputable sources that may state that, as opposed to its actual dictionary definition, "portable" is meant to imply not touching the registry ever on Windows, or leaving the computer in the exact same state as you found it once you're done (after deleting the app/config file). However, as you should realize, if that's the definition you want to go with, then even the portable version of Rufus is most certainly NOT "portable", because of the whole Local Group Policy business, which by the way can have very undesirable side effects (#711 that, as opposed to this issue, I actually looked into finding a non detrimental way to fix, but decided against when it turned out the fix would likely negatively affect more people than it would help).

So I guess what's left to do then is redefine one of these many "portable" definition to mean something like "minimal cruft left behind" as you stated (instead of "no cruft left behind"). But now what you're essentially saying is "My definition of "portable", even if it contradicts others, is the one everybody should go with, and especially developers". To which you may understand me replying "Or, how about we go with the definition of portable the developer settles on, especially if they tried to base it purely on semantics?"

In other words, I don't know where you got the idea that Rufus made any promise that its portability feature meant more than being able to move settings from one computer to another, but if your assertion is that it implies not reverting to non portable mode, should you deliberately choose not to duplicate the settings files, when you copy the app from a directory where the settings file most definitely exists (which I went the trouble of establishing), then your assertion is wrong.

This is all the more concerning if you say you are computer-savvy or concerned about app quality, as I would venture there exists a lot of apps that don't even bother checking their name for something like a 'p' but simply check the presence of a settings file in the same directory to decide whether they should run in portable or non-portable mode.

Ergo, by choosing not to the copy the ini file, you are actually taking a gamble based purely on a flawed definition of portability. Don't expect/assume others to follow you there.

There's nothing in it that I need or want to take with me in such circumstances

Oh really? That's quite a bold statement to make.

How can you assert that you won't need something if either:

You don't know what's in there?
You know what's in there, but you can't tell how it's used (because some settings, such as Commcheck are likely to be obtuse for anybody but the developer)?

For instance, if you're going to use Rufus on multiple computers in a row, you're probably going to start getting annoyed by being prompted for the dialog that asks you whether you want to enable the check for updates or not everytime you switch machine... which you'll only be able to avoid if you copy an ini file. And if you are maniac about the registry not being written into, I can certainly see a bunch of settings that, if you are aware of them, you might also want to be maniac about carrying over, such as display units, dual BIOS+UEFI boot, and other stuff that Rufus will store in the ini/registry.

But hey, you're going to say, I'd just like to reset the app to its default settings, and I don't care about those initial prompts... which is what you'll get regardless, as long as you understand that nowehere in the initial portable app you downloaded was it ever implied that the app would remain portable if you choose not to copy settings (that are definitely available for you to copy).

I have also been wondering for some time how leaving a handful of registry settings behind would even remotely qualify as worthy of consideration (since you need to run Rufus with admin rights anyway, so it's not like you're going to be running in a hardened environment that may prevent registry writes... and apart from that, I don't see ANY scenario where this will have any potential negative impact on the computer, its app, or its user...).

But what do I know, me and my apparently flawed definition of portability...

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.

pbatard / rufus

Downloading an Update #701