tahoe ls -l: show "i"/"m" instead of useless "x"

[warner]

In our CLI directory listing, we make it vaguely look like regular unix ls by putting some pseudo-mode-bits on the left hand side:

% ./bin/tahoe ls -l testgrid:RSA
-r-- 6881 Jan 14 16:14 outline.org
drwx    - Jan 14 16:45       zooko

This is meant to tell you that outline.org is either immutable, or mutable and you only have a readcap. And also that zooko is a directory, and mutable, *and* you have a writecap.

But that leftover "x" is just taking up space. Tahoe has no concept of "execution", and certainly not a directory that you can read but not enter or list.

So I'll propose that we get rid of the "x", and use that column instead to indicate the mutability or immutability of the object in question. Then files will always be one of -r-i or -r-m or -rwm, and directories will be one of dr-i, dr-m, drwm.

It might be nice to provide a hint about the enclosing directory: a -r-i file inside a writeable mutable directory can still be replaced, even though it can't be modified in-place. But a -r-i file inside an unwriteable directory can't be replaced. I can't think of a good way to express these, though.. maybe a fifth column that indicates replaceability, relative to the directory that you passed as an argument?

[imhavoc]

"*nix eyes" will be looking for the 'x' field. It would be better to leave it in place, and simply report '-' for every file than to remove it.

[imhavoc]

Replacing 'x' with 'i/m' may lead to greater confusion that adding a fifth field.

Po: use M/I instead of m/i for the m/i field for clarity.

[davidsarah]

Replying to warner:

In our CLI directory listing, we make it vaguely look like regular unix ls by putting some pseudo-mode-bits on the left hand side:

% ./bin/tahoe ls -l testgrid:RSA
-r-- 6881 Jan 14 16:14 outline.org
drwx    - Jan 14 16:45       zooko

This is meant to tell you that outline.org is either immutable, or mutable and you only have a readcap. And also that zooko is a directory, and mutable, *and* you have a writecap.

Arguably the resemblance to Unix permission bits is more misleading than helpful. For example the outline.org file can be replaced (because testgrid:RSA is writeable), so the closest analogy to a Unix filesystem would have 'w' in its permission bits. When we have writeable filesystem frontends, this is probably what they will report for the permissions.

It might be better to replace this column with something that doesn't look like Unix permissions:

% ./bin/tahoe ls -l testgrid:RSA
f+I 6881 Jan 14 16:14 outline.org
d+W    - Jan 14 16:45       zooko

where

• f/d/? indicates file, directory or unknown
• +/- indicates replaceable or not
• I/R/W indicates immutable, read-only mutable, or writeable.

[imhavoc]

I think there are some very good reasons to go with warner's model.

If you break *completely* from the *nix system, you run a much lower risk of confusing users.

Concerns:

• +/- for "replaceable" flag is unclear.
• The meaning of "mutable/immutable" is not immediately obvious to new users.
• What's the difference between "mutable" and "replaceable?"