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

New Issue

warner · 2010-01-15T02:46:51Z

warner commented

2010-01-15 02:46:51 +00:00

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?

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?

warner added the

labels 2010-01-15 02:46:51 +00:00

warner added this to the undecided milestone 2010-01-15 02:46:51 +00:00

imhavoc commented

2010-02-20 05:46:55 +00:00

"*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 commented

2010-02-20 05:51:36 +00:00

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.

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 commented

2010-02-22 20:10:11 +00:00

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.

Replying to [warner](/tahoe-lafs/trac-2024-07-25/issues/5966): > 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 commented

2010-02-22 20:18:46 +00:00

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?"

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?"

zooko modified the milestone from undecided to 1.7.0

2010-02-27 06:31:00 +00:00

zooko modified the milestone from 1.7.0 to eventually

2010-06-17 04:37:00 +00:00

Sign in to join this conversation.