I'm running into an issue that's perplexing to me. I'm using LFTP as part of a nightly automated file transfer process, with the goal of collecting all of the .csv files on a site.
Generally, the mget command, coupled with a wildcard .csv is able to find and download the files I expect it to. However, I'm running into an interesting situation where I have a file, which is identified with ls as:
-rw------- 0 User Name - 6461 Oct 4 14:04 file name.csv
but when I run mget *.csv, I get the following error message:
mget: Access failed: 550 /path/to/file/4 14:04 file name.csv: No such file or directory.
It looks like it's appending the %d %h:%m portion of the file's metadata to the file name when trying to mget it. I've thought it might be due to spaces in the file name, but in a testing it it doesn't look like that's the case.
Summary
lsmget commandmget command because somewhere along the line between the search and get commands, additional characters get added to the front of the file name, causing it to try to get a file that doesn't existAny thoughts on what I am doing wrong?
The answer to this question ends up being server and version specific, but I'll share what ended up being the problem in case it leads to someone else not having a trove of problems in the future.
FTP servers have different mechanisms for escaping users' names. In this case, the operations user account had a two part first name, with space separation.
The way(s) in which the FTP server do (or do not) escape user names can lead to everything being thrown off a column by the regex parser for mget in lftp. Reducing the username to a value which was compliant with lftp's expectations (appears to be one word, can include _ and -) ended up resolving this problem.