Mget * does not work

[optima]

Client is running f-secure 4.3 for unix. If they mget "filename" it works fine. Mget with a * will return a generic access denied in our server log. Here are the client logs.

sftp> mget *.txt
File ``file1.txt'' not a regular file, directory or symlink.
File ``file2.txt'' not a regular file, directory or symlink.
File ``file3.txt'' not a regular file, directory or symlink.
File ``file4.txt'' not a regular file, directory or symlink.

The server log shows "access denied" for "file1.txt" and nothing for the other files.

If the client does an mget and specifies the file name, it works fine. Mget * or *.* or *.ext even for one file in the directory fails. I saw some other posts about mget not working. This is a pretty important feature especially for automated pickup scripts where the filename is unknown. As I understand it, mget is a client command, and then it's sent to the server in raw ftp commands. Somewhere, this translation isn't happening correctly.

[optima]

What is the actual Core FTP log showing? Is it possible that it is a accurate permission denied because the path is not specified?

I'll take a look and let you know what I find.

Also, are you running build 175 (or greater)? There were some compatibility issues fixed recently:
http://www.coreftp.com/forums/viewtopic.php?t=1205

It's the newest build.

The user logs in and cd's to the appropriate directory. Does an mget *.txt or *.* and recieves the error I pasted in the first post. If they do an mget "filename" or a get "filename" even with out the path, it works fine.
Here is what the server says for an mget with a *:

[#1] [20061128 17:51:48] [xxx.xxx.xxx.xxx] joeuser, download of /Usr/joeuser/download/file1.txt denied

Great product by the way, I hope you can figgure it out.

Thanks

[ForumAdmin]

build 234 and great will contain fixes related to mget and list wildcard issues.

[ECGrid]

I am having the exact same problem with Build 349 with my customer using SFTP from HP/UX using Tectia.

There is no problem downloading the files individually. Something in the MGET * is causing a path issue if I were to guess.

This is not in the root directory, but a sub directory.

A CD is performed first.

Then an MGET * is performed.

The account has its own home directory which it is locked in.

GET is no problem. MGET fails as above.

* Further information from the client, same failure if the full path is used in the MGET.

Thank you!