exceptions when trying to use dirnode URIs #124
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#124
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
poor handling of user error: pasting a dirnode uri into the "get file" field of the wui
If you paste a dirnode uri into the "URI of file to download" field, you'll get:
The twistd.log contains:
and
Ah, the same thing happens when I paste the dirnode uri into the "URI of new child" field!
Here is the twistd.log from that:
poor handling of user error: pasting a dirnode uri into the "get file" field of the wuito exceptions when trying to use dirnode URIsThe first is a user error, but the error message obviously needs improvement.
The second ought to have worked. Odd, it worked for me just now..
I'll look at the error message more closely. BTW, what version of the node were you running?
Hooray for bindann!
well, ok, the extra quotes are weird, I don't know whether those are an artifact
or not, but the leading space is the problem. There must have been a space in
the text field when you pasted the URI in, or the cut target must have had a
space in it.
I'm going to change webish.py to do a
strip()
on all the arguments thatit receives. This is obviously correct for URIs. For filenames, it isn't, but
I think it is the least surprising approach (imagine adding a filename that
is all spaces, or a filename with a trailing space, and then trying to access
it via the CLI!).
That's easy! You just have to quote or escape it. :-)
true, but display is a problem: before I got into the habit of using
tab-completion everywhere, I'd spend entire minutes trying to figure out why
the file that 'ls' is showing me couldn't be deleted (because ls was unable
to tell me that there was a space at the end of the filename).
I've fixed these in changeset:5946985c0789ca5d and changeset:ed525f74780159c2 (separately in case we decide that
stripping filenames is a bad idea).
The first problem (pasting a dirnode URI into the 'download file' box)
suggests that maybe we should have a "View a directory" box on the front
page, that accepts a dirnode URI. Or maybe we should have a "do something
useful with a URI" box that accepts either, although the filename parameter
is still a nuisance.
Thinking about this more carefully, the real issue is one of typing. When a
user shares a file or directory, they're using an edge of their own vdrive
graph to identify it, so they have some idea in mind of how they want the
data (sequence of bytes) that they're sharing to be used. I see five cases:
sharing just bytes (with no type information), sharing bytes + mime-type,
sharing bytes + mime-type + suggested filename, sharing a directory, sharing
a directory + suggested dirname.
Our current URI syntax collapses the type information into one bit: filenode
or dirnode. Filenodes can be treated as a variety of mime-types, but that
information is in the edge (implied by the filename).
Hm, maybe the box on the front page should accept a "sharing link", which is
more than a URI, maybe a URI combined with some information about suggested
filename/dirname.
Anyways, I'm going to close this one out. Zooko, do you think the front-page
box I just described is useful? I'm not so sure. If you think it is, we can
open a new ticket for it.
I guess this means that "ls" ought to display the result in quotes, right?