Fix for mutable files with FTP #680
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
4 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#680
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?
FTP hangs when a directory list contains mutable files, as their filesize is the string "?", and Twisted's ftpd expects an integer.
This patch by warner should fix it.
For a different reason (comment:70648), mutable files cannot then be downloaded successfully over FTP.
Attachment ftp.patch (503 bytes) added
The patch, in diff/patch format
Actually it is the mutable files whose size shows up as "?". (This is because their size could change, and it would be expensive to examine each child to find out its current size when listing the parent directory.)
If only the code changed by this patch were covered by automated tests, I would consider including this patch in Tahoe-1.4.0. But in the interests of stability I don't want to apply patches to untested code just before the 1.4.0 release.
Fix for immutable files with FTPto Fix for mutable files with FTPI feel pretty comfortable about this patch. I'll try to apply it tonight. If 1.4.0 happens before then, I'd be ok with that too.
Hmm, this seems to misbehave with curlftpfs, will test with normal FTP client too.
With curlftpfs it simply sees them as files of zero length, as the FTP server says. So they're unusable there.
Unusable in normal FTP client too D=
Drat.. maybe the client is stubbornly remembering the "0" size, and refuses to download more than 0 bytes of it later on. A simple test of this would be to change that "if not a number, return 0" to "if not a number, return 1", and then see what the client does when you try to download the file.
Anyways, now I'm thinking we should not apply this patch before 1.4.0 .. better to keep the broken behavior the same, rather than switch it to a different broken behavior.
Should we add it to source:docs/known_issues.txt, with a suggested workaround saying "Don't use mutable files."?
FTP is a horrible protocol, and grokking its specification (RFC 959) is not helped by the fact that it has never been streamlined and updated for a world where bytes are always 8 bits and files are flat.
In any case, the relevant part of RFC 959 seems to be section 3.4, which says
It is very unlikely that the FTP server library is using anything other than STREAM transmission mode with a file structure ( http://cr.yp.to/ftp/type.html says the other options are all obsolete). If so, then the tested clients are nonconformant in treating anything other than a close of the data connection as end-of-file. http://cr.yp.to/ftp/browsing.html seems to suggest that browser ftp clients do actually look for connection close to signal EOF -- so I'm stumped.
SFTP has a similar problem -- just writing up a new ticket about that. I think blackmatch fuse also gets this wrong.
Replying to zooko:
Yes (more precisely, don't use mutable files with FTP). We should leave this ticket open since it might be fixable, even though I don't currently see how to do so reliably.
I guess this doesn't rise to the level of a Known Issue to be added to source:docs/known_issues.txt. (That file is more for things which might badly burn you if you don't know about them.) Let's add a note about this issue to the documentation of the (S)FTP interfaces.
Do we need to document this problem with mutable files in FTP? I don't think it is serious enough to deserve an entry in source:docs/known_issues.txt, but maybe in source:docs/frontends/FTP-and-SFTP.txt? Oh, I see there is already a note in there:
(from source:docs/frontends/FTP-and-SFTP.txt@4439#L201)
Hm, this documentation seems incomplete. What happens if I put a mutable file into a directory with
tahoe put
ortahoe ln
or the wui, and then I list that directory using my FTP client?Replying to zooko:
Well, according to the bug description it hangs (it's not clear whether the client hangs or the FTP server, probably the former).
The patch has not been applied because of the problem in comment:70621. On the other hand, hanging on a directory listing is a more serious problem than failing to download the file correctly in some (broken) clients, so perhaps the patch should be applied anyway. Not for 1.7.0, though.
This would be appropriate for 1.7.1 with the addition of a NEWS snippet and a patch to docs/frontends/FTP-and-SFTP.txt .
Out of time for 1.7.1.
Out of time for 1.8.
This ticket does not affect SFTP; that was fixed for mutable files in 1.7.0.
Note that in changeset:e05c6c2c7d25db66, source:docs/frontends/FTP-and-SFTP.txt was changed to say:
Well if I understand comment:14 correctly, this ticket merely needs NEWS and docs and can be merged for v1.9.0. If I understand correctly, this match makes it so that mutable files get a 0 size instead of a
'?'
size. A 0 size makes certain FTP clients (I don't know which) fail to download the mutable file. A'?'
size makes certain other ones (I don't know which) hang when listing the directory containing the file. I'm not 100% sure that the latter kind hang when listing the directory containing the file, or hang when trying to download the file.So I believe the next step is to update [NEWS]source:NEWS and [FTP-and-SFTP.rst]source:trunk/docs/frontends/FTP-and-SFTP.rst#known-issues.
Also we should commit it to trunk early in the v1.9.0 process and ask people to try it out with their favorite FTP client.
Replying to zooko:
+1. I'll do that.
Because we'll probably have a fairly long test cycle for 1.9, it seems like a good time to apply the fix to give the size as zero, and do interoperability testing with that.
I'll rebase the patch for trunk if needed.
This missed the 1.9 deadline.
(https://tahoe-lafs.org/trac/tahoe-lafs/attachment/ticket/1688/fix_ftpd_size_type.dpatch) has been committed (in changeset:7f6ee7e9180377bc) and makes a change equivalent to ftp.patch.
This doesn't necessarily make mutable files work with FTP. We should test interoperability with several FTP clients.
Oh, the reason it fails is that
ReadFile
in source:src/allmydata/frontends/ftpd.py calls theread
method of a filenode, which only exists for immutable filenodes. (It also exists onMutableFileVersion
, but notMutableFileNode
.)Replying to davidsarah:
To fix that, do something like:
in
ReadFile
. But we'd also need tests for FTP (#512).I think we ended up being deeply confused on this ticket by warner's speculation in comment:70623 :-)
In changeset:dde822e26d694ae6:
In changeset:f86a411928367998:
In changeset:f86a411928367998:
In changeset:5519/1.9.2:
In changeset:5869/cloud-backend:
Milestone renamed
renaming milestone
Moving open issues out of closed milestones.
The FTP frontend has been removed and according to https://tahoe-lafs.org/trac/tahoe-lafs/timeline?from=2010-09-11T01%3A05%3A36Z&precision=second this does not affect SFTP.