Repository: boto/boto

Issue:
Invalid path check in euca-bundle-image
The -i option uses convert_file in boto/roboto/param.py to verify that the path passed is, indeed, a file. This fails unless the path specified is a boring old file which is not necessary. Indeed it not being necessary is sort of the whole point in unix having a /dev in the first place. Everything is a file.

The code calls os.path.isfile(value) in convert_file(). It should call os.path.exists(value) and not os.path.isdir(value). Directories are the only types of files which need to be considered special in the normal course of events.



Discussion:
What version of euca2ools are you using?

Is that a scripted response? Like when you phone up one of those cheap call centres and the first dozen questions are always exactly the same no matter what your issue?

The code has a function whose purpose is to check that a string refers to a valid, readable path. It additionally checks that the valid path is a particular type of file, against 40+ years of unix traditionally not caring, while not actually checking that the entry the path refers to is readable. Which might actually be useful.

The version number is irrelevant. params.py has not been touched in 2 years, only 6 diffs refer to it and all but 1 of them is superficial, the other being the one in which it was first written. The code I am referring to has not changed in any version of euca2ools, as any moron looking at it would have been able to guess, and this moron did, before I ACTUALLY CHECKED THE HISTORY to make certain. Did you really fire off a response without reading my email and/or YOUR OWN CODE?

Also: I spent fucking ages finding this bug (I don't know Python at all) in my own copy of the code, whatever version it is. Then I dug through github to compare my copy to the latest checkin to see if the bug had changed or been fixed. Then I hacked my own version to make sure my fix was, indeed, a fix. Then I wrote the email so that the boto developers and users could take advantage of my time.

And you can't be arsed to take a quick look at one file to see wtf my email is going on about? params.py is less than 150 lines. The broken function is in the top 3rd (actually lines 47-51). Why the fuck should I waste my time hunting down bugs in somebody else's god-awful code (command line parsing in a network library! Yes!) when the developers themselves don't seem to care?

@ChoHag Part of making changes to boto is being able to replicate the issue at hand & adding test coverage to ensure we don't regress in the future. The Eucalyptus folks have a toolset that has drifted from boto over the last couple years (in good ways), so we're strictly looking for a way to duplicate & properly fix. And they've made quite a large number of commits in the last two years (https://github.com/gholms/euca2ools/commits/master). Looking up a version number is not typically regarded as an unreasonable task (find the same `__init__.py` as this please - https://github.com/gholms/euca2ools/blob/master/euca2ools/__init__.py#L30) & is very helpful for maintainers.

I'm sorry you ran into this issue but your tone is pretty poor. All code has bugs & this part of boto isn't exactly a high-traffic area. If this code didn't exist, you'd have to do everything from scratch, rather than fixing one small portion of it, so the least you could do is not make unfounded accusations & swear at people who've freely volunteered countless hours of their time to help you.

Reading the bug report is not considered an unreasonable task. Having never been introduced to this code before, and being entirely unfamiliar with Python, I was still able to guess, and then confirm when provoked, that the version number was irrelevant.

Is it unreasonable to expect that a set of skilled developers understands their own code better than I do?

Is it unreasonable to expect that a bug report which not only refers directly to a particular file but to a very specific half a dozen lines of code within that (extremely short) file should be read by somebody with enough sense to _look in that file_?

And now to the irrelevancy of version numbers you have added the issue of a test suite. I ... don't care. At all. I have pointed out a mistake and how to fix it. If you wish to incorporate that into a test suite to protect against regressions (and you should) that is your lookout. Right now, it is just another thing to stir into this pointless conversation rather than _just fixing the damn code_.

Finally, my tone would be unnecessary if my original bug report, which was not only congenial but _included a fix_, had actually been read and considered. And perhaps developers could not make unfounded assumptions, including but not limited to "the bug reporter has not done any research", of people who've freely volunteered time and effort to locate and fix _their_ bugs.

@ChoHag - The reason I asked about what version of euca2ools you are using is because it was my understanding that euca2ools was no longer using roboto.  I just wanted to know which version of euca2ools you were using so I could try to find that version to reproduce the issue.

It wasn't an unreasonable question and, in asking it I didn't say anything about the quality of your pull request or about our willingess (or not) to merge your fix.

Your reaction is completely out of line and over the top.

Euca may or may not use roboto? Well that's alright, because the issue is not in euca. Euca is simply how I found it. I daresay the vast majority of consumers of boto, Euca apparently no longer among them, don't notice that the check for the existence of a path also incorrectly checks the format of the file at that path which is why it's lingered this long.

The problem is in boto, in the convert_file function in boto/roboto/param.py. You know this because within the first 7 words of the bug report I have said so. Also this is the boto repository's issue tracker, which one assumes tracks issues with boto, not random other projects.

This is the last I have to say on the matter. You have a bug wherein boto does not correctly interface with the system on which it is running. You know where it is and how to fix it. Do with it what you like, I don't care - people pay me to work around this kind of unfixable idiocy anyway.


Resolving patch:
diff --git a/boto/roboto/param.py b/boto/roboto/param.py
--- a/boto/roboto/param.py
+++ b/boto/roboto/param.py
@@ -46,7 +46,7 @@ def convert_boolean(cls, param, value):
 
     @classmethod
     def convert_file(cls, param, value):
-        if os.path.isfile(value):
+        if os.path.exists(value) and not os.path.isdir(value):
             return value
         raise ValueError
 


Test patch: