On Tue, Sep 02, 2014 at 09:41:41AM -0700, Joffrey F wrote:

Fixes #486

How does this fix 486? If it does fix it, I'm surprised that
‘store.list_directory(tag_path)’ is still listing tags. I still think
this sort of tag handling should be built into a generic Storage
class, since there's currently no filesystem-agnostic way I can think
of to list tags.

@wking I can't verify that the content of fname is what I expect it to be, but I can make sure that tag_path() will return the proper result when given the correct parameters. I'm pretty sure that fixes it, but even if it didn't, it's still a more sanitized way of doing things.

@shin- can we add tests (using STORAGE_PATH and not using it) that validate the fact this does fix #486 ? (eg: calling get_tag would fail without your patch and pass with it)

@dmp42 Added test

@shin- does it fail with the current master?

No, I'm not calling get_tags() directly because it's an S3-specific test and I don't want the imports to get crazy. Instead, I'm reproducing the current master's get_tags behavior and check that I get a FileNotFound error, then verify that I am able to access the data using the new get_tags behavior.

Ok, let's merge it.