tahoe get on DIR2 URIs fails with error message that is too terse #1414

New Issue

tahoe-lafs · 2011-06-04T14:28:49Z

gdt commented

2011-06-04 14:28:49 +00:00

When doing 'tahoe get' and giving a directory URI, I get "302 Found" instead of the bits. Changing DIR2 to SSK gets me bits. There's no good reason not to return the directory contents; 'cat .' on at least BSD shows the bits in the directory. While most people don't want to look ever, and the rest only want to look once in a while, being able to understand directories is key to a deep understanding of how access control works.

Further, the writecaps should be decrypted when the directory is fetched with a writecap.

When doing 'tahoe get' and giving a directory URI, I get "302 Found" instead of the bits. Changing DIR2 to SSK gets me bits. There's no good reason not to return the directory contents; 'cat .' on at least BSD shows the bits in the directory. While most people don't want to look ever, and the rest only want to look once in a while, being able to understand directories is key to a deep understanding of how access control works. Further, the writecaps should be decrypted when the directory is fetched with a writecap.

tahoe-lafs added the

labels 2011-06-04 14:28:49 +00:00

tahoe-lafs added this to the undecided milestone 2011-06-04 14:28:49 +00:00

davidsarah commented

2011-06-04 21:12:52 +00:00

I don't think that BSD cat showing the bits is a good argument for tahoe get (or the corresponding web-API request) to do so. Conceptually, the SSK URI refers to the bits, and the DIR2 URI refers to the directory interpretation. In Unix the same pathname is used to refer to both. So it makes sense that in Tahoe, a command that fetches file contents would succeed for the SSK URI and fail for the DIR2 URI.

Since you can see the bits by using the SSK URI, there's no loss of functionality in the current behaviour. So I'm inclined to "wontfix" this.

Further, the writecaps should be decrypted when the directory is fetched with a writecap.

I completely disagree; that would be effectively creating a new directory format that is not the stored format, which seems overcomplicated and unlikely to lead to better understanding.

I don't think that BSD `cat` showing the bits is a good argument for `tahoe get` (or the corresponding web-API request) to do so. Conceptually, the SSK URI refers to the bits, and the DIR2 URI refers to the directory interpretation. In Unix the same pathname is used to refer to both. So it makes sense that in Tahoe, a command that fetches file contents would succeed for the SSK URI and fail for the DIR2 URI. Since you *can* see the bits by using the SSK URI, there's no loss of functionality in the current behaviour. So I'm inclined to "wontfix" this. > Further, the writecaps should be decrypted when the directory is fetched with a writecap. I completely disagree; that would be effectively creating a new directory format that is not the stored format, which seems overcomplicated and unlikely to lead to better understanding.