Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test475: verify a 72K ASCII FTP upload #14717

Closed
wants to merge 7 commits into from
Closed

test475: verify a 72K ASCII FTP upload #14717

wants to merge 7 commits into from

Conversation

bagder
Copy link
Member

@bagder bagder commented Aug 29, 2024

Extended the test format and runtest.pl so that the verify/upload part can be marked using crlf newlines even when the client/file does not have it.

@dfandrich
Copy link
Contributor

Analysis of PR #14717 at 7cfd648b:

Test 340 failed, which has NOT been flaky recently, so there could be a real issue in the PR.

Test 475 failed, which has NOT been flaky recently, so there could be a real issue in the PR. Note that this test has failed in 9 different CI jobs (the link just goes to one of them).

Generated by Testclutch

@bagder
Copy link
Member Author

bagder commented Aug 29, 2024

Currently ASCII transfer code for FTP simply assumes that the source file is CRLF on Windows and makes no attempt at fixing this. Thus, this test now fails on Windows.

This assumption seems odd, and I think we should consider dropping this "exception" done for Windows and instead always change LF line endings to CRLF line endings for FTP ASCII transfers.

@icing
Copy link
Contributor

icing commented Aug 29, 2024

Currently ASCII transfer code for FTP simply assumes that the source file is CRLF on Windows and makes no attempt at fixing this. Thus, this test now fails on Windows.

This assumption seems odd, and I think we should consider dropping this "exception" done for Windows and instead always change LF line endings to CRLF line endings for FTP ASCII transfers.

I agree, but then we'd also need to change the code to not convert existing CRLF, I think.

@icing
Copy link
Contributor

icing commented Aug 29, 2024

And think what this all has to do with "ascii"...🤔

@bagder
Copy link
Member Author

bagder commented Aug 29, 2024

RFC 959 defines a TYPE A transfer like this:

         3.1.1.1.  ASCII TYPE

            This is the default type and must be accepted by all FTP
            implementations.  It is intended primarily for the transfer
            of text files, except when both hosts would find the EBCDIC
            type more convenient.

            The sender converts the data from an internal character
            representation to the standard 8-bit NVT-ASCII
            representation (see the Telnet specification).  The receiver
            will convert the data from the standard form to his own
            internal form.

            In accordance with the NVT standard, the <CRLF> sequence
            should be used where necessary to denote the end of a line
            of text.  (See the discussion of file structure at the end
            of the Section on Data Representation and Storage.)

            Using the standard NVT-ASCII representation means that data
            must be interpreted as 8-bit bytes.

@bagder
Copy link
Member Author

bagder commented Aug 29, 2024

the CRLF sequence should be used where necessary to denote the end of a line of text.

Is the key sentence I guess.

@bagder
Copy link
Member Author

bagder commented Aug 29, 2024

I'll first merge #14709, then rebase this PR on top of that and figure out the next step.

Extended the test format and runtest.pl so that the verify/upload part
can be marked using crlf newlines even when the client/file does not
have it.
Previously this functionality was limited to platforms that not already
use CRLF as native line endings.
All sections defined with the mode="text" attribute now get line endings
normalized so that comparisons become line ending agnostic.
@bagder
Copy link
Member Author

bagder commented Aug 29, 2024

With this, one of the Windows CI builds reports this quite cool output:

IGNORED: passed tests: 79 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 161 182 190 191 195 196 208 210 211 212 215 216 225 226 227 228 229 235 236 237 238 244 247 248 250 251 252 253 254 255 261 270 271 272 280 283 284 285 286 289 290 291 294 295 296 297 298 299 332 336 337 340 348 350 351 352 353 354 362 380 381 390 400 401 402 403 404 405 406 407 408 409 416 475 476 494 505 511 520 521 524 525 526 527 529 531 532 533 534 538 539 541 542 546 549 550 561 562 563 564 573 574 575 576 586 587 588 591 592 593 595 596 597 661 706 707 711 712 713 714 715 973 975 983 986 1000 1003 1005 1006 1007 1009 1010 1028 1036 1037 1038 1039 1044 1047 1048 1049 1050 1055 1057 1059 1062 1077 1086 1091 1092 1093 1094 1096 1098 1099 1102 1103 1106 1107 1108 1112 1113 1114 1120 1137 1149 1152 1153 1162 1163 1190 1191 1192 1193 1194 1195 1196 1198 1199 1206 1207 1208 1217 1219 1224 1225 1226 1227 1233 1238 1242 1243 1245 1262 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1405 1414 1444 1449 1469 1501 1569 1570 1592 1631 1632 1913 1914 1916 1917 2000 2001 2002 2003 2039 2045 2083 2200 2201 2202 2203 2204 2205 2300 2301 2303 2304 2305 2307 3017 3018

@bagder bagder closed this in ee17f35 Aug 29, 2024
bagder added a commit that referenced this pull request Aug 29, 2024
bagder added a commit that referenced this pull request Aug 29, 2024
Previously this functionality was limited to platforms that not already
use CRLF as native line endings.

TODO: 4.5 ASCII support now considered fixed

Closes #14717
bagder added a commit that referenced this pull request Aug 29, 2024
All sections defined with the mode="text" attribute now get line endings
normalized so that comparisons become line ending agnostic. Removes the
previous problem of figuring out how exactly different Windows
environments should be treated in this regard.

Closes #14717
@bagder bagder deleted the bagder/test475 branch August 29, 2024 18:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

3 participants