dir
200 PORT command succesful
150 Opening ASCII mode data connection for /bin/ls
I see some files and 1 directory
I digit: mget *
for each file I see:
mget .\nomefile? Y
200 PORT command succesful
125 Data connection open, transfer starting
226 Transfer complete
local: .\nomefile remore: .\nomefile
Is the backslash really part of the name? If what you wrote is what you actually typed
that is probably the reason you cannot see your file.
cd to the directory on the unix box where you were, try:
ls -la *omefile
the \ character is a special character to the unix shell. Do not use it in filenames.
I only typed: mget *
Then the output is:
mget .\nomefile? Y
200 PORT command succesful
125 Data connection open, transfer starting
226 Transfer complete
local: .\nomefile remore: .\nomefile
So the the \ character is on the output, i didn't type the \ I only typed mget *
Then, to reply to dennis.jacob i tryed to type: mget lcd *
and the result is the same
Further to Jim Mcnamara. The remote filenames appear to be invalid. To work out where they went you need to know the actual filename.
However: This might reveal them.
ls -la .??*
Can you get a a normal unix directory listing of the files on the remote server? I don't think that the "dir" in ftp is telling the whole story.
e.g. To show funny characters in filenames:
I think that the original files on the far server have very strange filenames.
It's actually quite difficult to guess the filename.
You need to find out the actual name of the files and then consider repairing the process which created the files.
A unix filename can contain virtually any character including shell special characters. It is never sensible to have shell special characters in a filename (e.g. backslash, dollar etc.).
Also if you want to transfer a file with ftp protocol the filename rules are much more restrictive than modern unix or Windows.
On a hunch, the files could have been created when someone typed ".\filename" instead of "./filename" in a non-shell context like a program.