https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42992 Bug ID: 42992 Summary: FTP file transport list_files() corrupts filenames Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs@lists.koha-community.org Reporter: martin.renvoize@openfifth.co.uk QA Contact: testopia@bugs.koha-community.org Target Milestone: --- Koha::File::Transport::FTP->_list_files parses the LIST / "ls -l" output returned by the FTP server. The date field in that output is three whitespace-separated tokens (Mon DD HH:MM, or Mon DD YYYY for older files), but the parse used a non-greedy capture that only consumed the first token (the month). The remaining two date tokens were left glued to the front of the filename, so every filename returned for an FTP transport was prefixed with the listing date, e.g. -rw-r--r-- 1 user group 1234 Jan 01 12:00 QUOTES_413514.CEQ becomes filename "01 12:00 QUOTES_413514.CEQ" Callers (Koha::Edifact::Transport and misc/cronjobs/marc_ordering_process.pl) then ask the server for a file that does not exist, so no files are downloaded, renamed or deleted over FTP. SFTP and Local transports are not affected. This regressed when EDI transport moved onto the file_transports system (bug 38489): the old Koha::Edifact::Transport::ftp_download listed files with Net::FTP->ls (NLST, bare names); the refactor switched to Net::FTP->dir (LIST) to return the richer hashref shape used by the SFTP and Local transports, but the parse was faulty. The fix consumes the date field explicitly as three tokens so the filename is captured cleanly (spaces preserved, directories still skipped). The LIST-based approach and the filename/longname/size/perms return shape are kept so the structure stays consistent across transport classes. Test plan: 1. prove t/db_dependent/Koha/File/Transport/FTP.t 2. Revert Koha/File/Transport/FTP.pm only and re-run: the list_files() subtest fails on the filename/size/perms assertions. 3. prove t/db_dependent/Koha/Edifact/Transport.t -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.