Ticket UUID: | 478478 | |||
Title: | ftp::ModTimePostProcess fails | |||
Type: | Bug | Version: | None | |
Submitter: | mrfitz | Created on: | 2001-11-05 22:32:37 | |
Subsystem: | ftp | Assigned To: | andreas_kupries | |
Priority: | 5 Medium | Severity: | ||
Status: | Closed | Last Modified: | 2001-11-08 13:27:26 | |
Resolution: | Fixed | Closed By: | andreas_kupries | |
Closed on: | 2001-11-08 06:27:26 | |||
Description: |
Admittedly this is most likely due to a server-side problem, but I was unable to figure out which RFC covered the MDTM command/response definition. The server: (Version wu-2.4(4) Thu Jun 18 14:15:17 PDT 1998) returns from MDTM a string like: "213 191010831020526" instead of: "213 20010831020526" which cause the following code to fail at clock scan (the following lines are split for entry width): scan $clock "%4s%2s%2s%2s%2s%2s" \ year month day hour min sec set clock [clock scan \ "$month/$day/$year $hour:$min:$sec" -gmt 1] I do not know how widespread this response may be, but the code could be modified to handle it by replacing the "scan $clock ..." line with: if { [string length $clock] == 15 } { scan $clock "%2s%3s%2s%2s%2s%2s%2s" \ cent year month day hour min sec set year [expr ($cent * 100) + $year] } else { scan $clock "%4s%2s%2s%2s%2s%2s" \ year month day hour min sec } | |||
User Comments: |
andreas_kupries added on 2001-11-08 13:27:26:
Logged In: YES user_id=75003 Patch committed to head. andreas_kupries added on 2001-11-07 11:33:21: File Added - 12951: ftp_modtimepp.diff andreas_kupries added on 2001-11-07 11:33:20: Logged In: YES user_id=75003 Enclosed the final patch. andreas_kupries added on 2001-11-07 10:37:21: Logged In: YES user_id=75003 This is definitely a server problem. I have seen that in some RISKS digests as amusing examples of bad Y2K patches. Yeah, I guess we can accomodate the servers. And also a nice log message. |
Attachments:
- ftp_modtimepp.diff [download] added by andreas_kupries on 2001-11-07 11:33:20. [details]