upload of file into dir doesn't appear on Recent Uploads and Downloads #1079
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
3 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#1079
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
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?
When I upload a file into a directory, such as this one:
http://pubgrid.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/ , which the timestamps show got linked into this directory at 2010-06-12_03:45:30.369968, the upload of the immutable file doesn't appear on the Recent Uploads and Downloads page:
Argh! These timestamps are in different timezones and neither of them have explicit timezone indicators. Grumble. Also they are of different and non-standard formatting. I just created #1077 (consistent timestamp format and timezone).
Anyway, making some educated guesses about what these timestamps mean, the upload that I completed at around 2010-06-12 03:45:30Z should have appeared in the list as "11-Jun-2010 21:45:30".
It seems like immutable file uploads into a directory never appear on Recent !Uploads/Downloads, but immutable file downloads and unlinked immutable file uploads do.
This shouldn't be hard to fix and it would be a big help with evaluating and improving Tahoe-LAFS performance if we could tell how fast uploads were.
Out of time for 1.8.
I did some digging. The problem is that we aren't being consistent in
passing the "History" object to all cases of file upload. (to get into
the "Recent Uploads and Downloads" RUaD page, the Uploader must be given
access to the History object, so it can call
History.add_upload
).Client.upload(uploadable)
does the right thing. The webapi hasseveral different code paths that result in an immutable upload:
PUTUnlinkedCHK
(unlinked.py#L11) which callsclient.upload
, okself.parentnode.add_file()
, which does not handle history/uri/DIRCAP/oldchildname?t=upload&replace=true : both hit
replace_me_with_a_formpost
(filenode.py#L86), usesself.parentnode.add_file()
, no historyThe root problem is that
DirectoryNode.add_file()
, whileconvenient, doesn't have access to the History object. The best fix is
probably to delete this method, and rewrite web/filenode.py to make two
separate calls:
client.upload
andself.parentnode.set_uri
.OTOH,
add_file()
is used in an awful lot of unit tests, becauseit's so darned convenient. It'd be easier to change
DirectoryNode.add_file
to useclient.upload
, since theclient knows about
History
, butDirectoryNode
doesn'tcurrently hold a reference to the client (just the nodemaker and the
uploader). Maybe we should move
client.upload
over to thenodemaker?
The SFTP and FTP frontends also use
add_file
.Replying to davidsarah:
As does the drop-upload frontend. All of these have access to the Client, so one possibility would be to add a
client=
argument toadd_file
. But since all uploads should be included in the history, I would think (without having looked in detail at the code) that the uploader should have (that is, be instantiated with) a reference to theHistory
.In changeset:fd676a5846fce5da:
excellent idea! Just landed it. I don't know why I didn't think of that before.. it might be that I've been hoping to get rid of the Uploader service (as we did with the old Downloader service), and so I didn't want to add anything extra to it. But that's a project for another day, and adding History to the Uploader is the perfect solution for this. Thanks!