Attempting to call a constructed method name with a nil component (the checksum type in this case) causes an unhelpful error message in a case where either 1) the results were not needed anyway or 2) a more useful error message would otherwise be generated. It also opens (at least hypothetically) then possibility that some unrelated method (in this case "_file" would be called if it existed.
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account
Pushed in commit:"d1ff4b3fca31ee99276c26bc1df6391cfc79254a" in branch 0.25.x
Attempting to call a constructed method name with a nil component (the checksum type in this case) causes an unhelpful error message in a case where either 1) the results were not needed anyway or 2) a more useful error message would otherwise be generated. It also opens (at least hypothetically) then possibility that some unrelated method (in this case "_file" would be called if it existed.
The first change simply exposed an underlying problem; metadata for links does not contain the checksum, which is needed when links is set to follow.
Attempting to call a constructed method name with a nil component (the checksum type in this case) causes an unhelpful error message in a case where either 1) the results were not needed anyway or 2) a more useful error message would otherwise be generated. It also opens (at least hypothetically) then possibility that some unrelated method (in this case "_file" would be called if it existed.
Branch updated with additional fix.
Attempting to call a constructed method name with a nil component (the checksum type in this case) causes an unhelpful error message in a case where either 1) the results were not needed anyway or 2) a more useful error message would otherwise be generated. It also opens (at least hypothetically) then possibility that some unrelated method (in this case "_file" would be called if it existed.
The fix works as reported by the user, but I'm not satisfied with the error handling. Revised (and hopefully final) branch up shortly.
Attempting to call a constructed method name with a nil component (the checksum type in this case) causes an unhelpful error message in a case where either 1) the results were not needed anyway or 2) a more useful error message would otherwise be generated. It also opens (at least hypothetically) then possibility that some unrelated method (in this case "_file" would be called if it existed.
The branch has been updated with a version that has better tests and error handling (and still works at the user's site). It's good to go.
Attempting to call a constructed method name with a nil component (the checksum type in this case) causes an unhelpful error message in a case where either 1) the results were not needed anyway or 2) a more useful error message would otherwise be generated. It also opens (at least hypothetically) then possibility that some unrelated method (in this case "_file" would be called if it existed.
Pushed in commit:"7e64393dd10023d528d2fc21383ead30c9ee94dd" and d1ff4b3fca31ee99276c26bc1df6391cfc79254a in branch 0.25.x
Attempting to call a constructed method name with a nil component (the checksum type in this case) causes an unhelpful error message in a case where either 1) the results were not needed anyway or 2) a more useful error message would otherwise be generated. It also opens (at least hypothetically) then possibility that some unrelated method (in this case "_file" would be called if it existed.
I swear the fix tested just fine for me but the "unknown checksum" and filebucket-every-time problem is back for me on all of our OSes with 0.25.2rc3.
Attempting to call a constructed method name with a nil component (the checksum type in this case) causes an unhelpful error message in a case where either 1) the results were not needed anyway or 2) a more useful error message would otherwise be generated. It also opens (at least hypothetically) then possibility that some unrelated method (in this case "_file" would be called if it existed.
Mark --
I tested it on your box too, and just retested with the same results you saw; it worked before, but is not working in 0.25.x. I'm digging in to it now.
-- Markus
Attempting to call a constructed method name with a nil component (the checksum type in this case) causes an unhelpful error message in a case where either 1) the results were not needed anyway or 2) a more useful error message would otherwise be generated. It also opens (at least hypothetically) then possibility that some unrelated method (in this case "_file" would be called if it existed.
Branch updated with a version of the patch which always checksums links (going back to the earlier strategy) with tests adjusted to correspond.
This was needed to eliminate the partial reintroduction of the original bug in the case where the checksum of a followed link is being requested via rest from the client (which doesn't know that it's not just a regular file, and thus can't know to pass {links => follow} in the request).
Attempting to call a constructed method name with a nil component (the checksum type in this case) causes an unhelpful error message in a case where either 1) the results were not needed anyway or 2) a more useful error message would otherwise be generated. It also opens (at least hypothetically) then possibility that some unrelated method (in this case "_file" would be called if it existed.
Attempting to call a constructed method name with a nil component (the checksum type in this case) causes an unhelpful error message in a case where either 1) the results were not needed anyway or 2) a more useful error message would otherwise be generated. It also opens (at least hypothetically) then possibility that some unrelated method (in this case "_file" would be called if it existed.
Third time is the charm - pushed in commit:"cbc2ef003d93e5162979cebc927b5d9a69397439" in branch 0.25.x
Attempting to call a constructed method name with a nil component (the checksum type in this case) causes an unhelpful error message in a case where either 1) the results were not needed anyway or 2) a more useful error message would otherwise be generated. It also opens (at least hypothetically) then possibility that some unrelated method (in this case "_file" would be called if it existed.