https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43092 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 202019 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202019&action=edit Bug 43092: Stop Local transport falling back to the Koha process's own cwd Koha::File::Transport's three backends disagree on what change_directory(undef) means: FTP navigates to the server root, SFTP falls back to the SFTP session's own home directory, and Local fell back to the configured download_directory or, if that's also unset, silently to '.' - the Koha process's own working directory, which has no relation to any configured transport location. test_connection() calls change_directory(undef) unconditionally for both the download and upload directory checks on every config save (via the auto-enqueued TestTransport background job). For a Local transport configured with only one of download_directory/ upload_directory, the untested direction's list_files() call would silently list the Koha process's own cwd (e.g. the Koha install root) instead of failing cleanly. Add a private _working_directory($configured_field) helper that returns the tracked change_directory() override or the given configured field, but never falls back to '.'. _upload_file, _download_file, _list_files and _rename_file now use it and record a clear "not configured" error instead of silently acting on an unrelated directory when neither is set. FTP's root and SFTP's home-directory fallbacks are left as-is: unlike Local's '.', they navigate to a real, meaningful location for that specific connection rather than leaking unrelated filesystem content, so they aren't part of this fix. Test plan: 1. prove t/db_dependent/Koha/File/Transport/Local.t => All tests successful, including the new subtest proving that list_files()/rename_file()/download_file() fail cleanly (with a "not configured" error) rather than falling back to '.' when their respective directory isn't configured, while the configured direction (upload, in the test) still works. 2. prove -r t/db_dependent/Koha/File/ t/db_dependent/Koha/Edifact/Transport.t t/db_dependent/api/v1/file_transports.t => All tests successful (43 tests total), no regressions. 3. koha-qa.pl -v 2 --more-tests => [PASS], no critic/pod warnings. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43092 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43092 --- Comment #2 from David Nind <david@davidnind.com> --- Created attachment 202126 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202126&action=edit Bug 43092: Stop Local transport falling back to the Koha process's own cwd Koha::File::Transport's three backends disagree on what change_directory(undef) means: FTP navigates to the server root, SFTP falls back to the SFTP session's own home directory, and Local fell back to the configured download_directory or, if that's also unset, silently to '.' - the Koha process's own working directory, which has no relation to any configured transport location. test_connection() calls change_directory(undef) unconditionally for both the download and upload directory checks on every config save (via the auto-enqueued TestTransport background job). For a Local transport configured with only one of download_directory/ upload_directory, the untested direction's list_files() call would silently list the Koha process's own cwd (e.g. the Koha install root) instead of failing cleanly. Add a private _working_directory($configured_field) helper that returns the tracked change_directory() override or the given configured field, but never falls back to '.'. _upload_file, _download_file, _list_files and _rename_file now use it and record a clear "not configured" error instead of silently acting on an unrelated directory when neither is set. FTP's root and SFTP's home-directory fallbacks are left as-is: unlike Local's '.', they navigate to a real, meaningful location for that specific connection rather than leaking unrelated filesystem content, so they aren't part of this fix. Test plan: 1. prove t/db_dependent/Koha/File/Transport/Local.t => All tests successful, including the new subtest proving that list_files()/rename_file()/download_file() fail cleanly (with a "not configured" error) rather than falling back to '.' when their respective directory isn't configured, while the configured direction (upload, in the test) still works. 2. prove -r t/db_dependent/Koha/File/ t/db_dependent/Koha/Edifact/Transport.t t/db_dependent/api/v1/file_transports.t => All tests successful (43 tests total), no regressions. 3. koha-qa.pl -v 2 --more-tests => [PASS], no critic/pod warnings. Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43092 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43092 --- Comment #3 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 202839 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202839&action=edit Bug 43092: Stop Local transport falling back to the Koha process's own cwd Koha::File::Transport's three backends disagree on what change_directory(undef) means: FTP navigates to the server root, SFTP falls back to the SFTP session's own home directory, and Local fell back to the configured download_directory or, if that's also unset, silently to '.' - the Koha process's own working directory, which has no relation to any configured transport location. test_connection() calls change_directory(undef) unconditionally for both the download and upload directory checks on every config save (via the auto-enqueued TestTransport background job). For a Local transport configured with only one of download_directory/ upload_directory, the untested direction's list_files() call would silently list the Koha process's own cwd (e.g. the Koha install root) instead of failing cleanly. Add a private _working_directory($configured_field) helper that returns the tracked change_directory() override or the given configured field, but never falls back to '.'. _upload_file, _download_file, _list_files and _rename_file now use it and record a clear "not configured" error instead of silently acting on an unrelated directory when neither is set. FTP's root and SFTP's home-directory fallbacks are left as-is: unlike Local's '.', they navigate to a real, meaningful location for that specific connection rather than leaking unrelated filesystem content, so they aren't part of this fix. Test plan: 1. prove t/db_dependent/Koha/File/Transport/Local.t => All tests successful, including the new subtest proving that list_files()/rename_file()/download_file() fail cleanly (with a "not configured" error) rather than falling back to '.' when their respective directory isn't configured, while the configured direction (upload, in the test) still works. 2. prove -r t/db_dependent/Koha/File/ t/db_dependent/Koha/Edifact/Transport.t t/db_dependent/api/v1/file_transports.t => All tests successful (43 tests total), no regressions. 3. koha-qa.pl -v 2 --more-tests => [PASS], no critic/pod warnings. Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43092 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |43088 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43088 [Bug 43088] Koha::File::Transport lacks a consistent current_directory() accessor across FTP/SFTP/Local -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43092 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch Status|Patch doesn't apply |Passed QA Sponsorship status|--- |Unsponsored -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43092 --- Comment #5 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 202924 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202924&action=edit Bug 43092: Stop Local transport falling back to the Koha process's own cwd Koha::File::Transport's three backends disagree on what change_directory(undef) means: FTP navigates to the server root, SFTP falls back to the SFTP session's own home directory, and Local fell back to the configured download_directory or, if that's also unset, silently to '.' - the Koha process's own working directory, which has no relation to any configured transport location. test_connection() calls change_directory(undef) unconditionally for both the download and upload directory checks on every config save (via the auto-enqueued TestTransport background job). For a Local transport configured with only one of download_directory/ upload_directory, the untested direction's list_files() call would silently list the Koha process's own cwd (e.g. the Koha install root) instead of failing cleanly. Add a private _working_directory($configured_field) helper that returns the tracked change_directory() override or the given configured field, but never falls back to '.'. _upload_file, _download_file, _list_files and _rename_file now use it and record a clear "not configured" error instead of silently acting on an unrelated directory when neither is set. FTP's root and SFTP's home-directory fallbacks are left as-is: unlike Local's '.', they navigate to a real, meaningful location for that specific connection rather than leaking unrelated filesystem content, so they aren't part of this fix. Test plan: 1. prove t/db_dependent/Koha/File/Transport/Local.t => All tests successful, including the new subtest proving that list_files()/rename_file()/download_file() fail cleanly (with a "not configured" error) rather than falling back to '.' when their respective directory isn't configured, while the configured direction (upload, in the test) still works. 2. prove -r t/db_dependent/Koha/File/ t/db_dependent/Koha/Edifact/Transport.t t/db_dependent/api/v1/file_transports.t => All tests successful (43 tests total), no regressions. 3. koha-qa.pl -v 2 --more-tests => [PASS], no critic/pod warnings. Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.