Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GET command not always working #9687

Open
borg1310 opened this issue Nov 29, 2024 · 4 comments
Open

GET command not always working #9687

borg1310 opened this issue Nov 29, 2024 · 4 comments
Labels
status: waiting-for-reporter Needs a feedback from the reporter type: bug

Comments

@borg1310
Copy link

hi,

The GET command of FtpOutboundGateway does not work on all FTP servers (e.g. vsftp) because the FTP protocol allows nothing (empty) to be returned when LS is performed on a file. This means that this line gets always an empty array.

best regrads,

juergen

@borg1310 borg1310 added status: waiting-for-triage The issue need to be evaluated and its future decided type: bug labels Nov 29, 2024
@artembilan
Copy link
Member

I don’t understand what is the question. What exactly is wrong and what is a suggestion for a fix?
Please, ellaborate.

@artembilan artembilan added status: waiting-for-reporter Needs a feedback from the reporter and removed status: waiting-for-triage The issue need to be evaluated and its future decided labels Nov 29, 2024
@artembilan
Copy link
Member

We just follow FTPClient.listFiles() JavaDocs:

Using the default system autodetect mechanism, obtain a list of file information for the current working directory or for just a single file.

So, that is unclear in what situation the file object might not be returned.
I see there is some FTPListParseEngine used internally in the client.
So, might be some option should be set for your specific FTP server:


parserKey – A string representing a designated code or fully-qualified class name of an FTPFileEntryParser that should be used to parse each server file listing. May be null, in which case the code checks first the system property FTP_SYSTEM_TYPE, and if that is not defined the SYST command is used to provide the value. To allow for arbitrary system types, the return from the SYST command is used to look up an alias for the type in the SYSTEM_TYPE_PROPERTIES properties file if it is available. pathname – the starting directory

@borg1310
Copy link
Author

hi @artembilan ,

sorry for my late response!
i think the problem described above has nothing to do with FtpOutboundGateway, but with the ftp server (vsftp) i have used. i will explain it below, but i think it is not of interest for you.

  1. i connect to the ftp server and do a ls to a directory
ftp> ls SFL/114928/Daten/SFLX1/2024/csv
229 Entering Extended Passive Mode (|||21007|)
150 Here comes the directory listing.
-rw-rw-r--    1 1000     1000       277766 Nov 22 11:35 SFLX1_B_2024_1.csv
-rw-rw-r--    1 1000     1000       282141 Nov 22 11:35 SFLX1_B_2024_10.csv
-rw-rw-r--    1 1000     1000       191473 Nov 22 11:35 SFLX1_B_2024_11.csv
-rw-rw-r--    1 1000     1000       601028 Nov 22 11:34 SFLX1_D_2024_9.csv
226 Directory send OK.
  1. then i do a ls to a specific file within the directory. as you can see the resulting directory listing is empty and there is no error occurred.
ftp> ls SFL/114928/Daten/SFLX1/2024/csv/SFLX1_D_2024_9.csv
229 Entering Extended Passive Mode (|||21002|)
150 Here comes the directory listing.
226 Directory send OK.
  1. in this line the FtpOutboundGateway do also a ls to a file, that should be downloaded via a get command. the response listing was also empty and therefore a execption was thrown (line 1127)
  2. when i created this issue i found some stackoverflow articles (i can not find them anymore) that described the same problem and they mentioned also that in the ftp standard it would not be specified how a server should react to a ls on a file (the server could response with an empty listing). i could not verify this. for me it is clearly specified that the server should return a listing with the file attributes (here is a excerpt from the ftp standard (RFC 959: File Transfer Protocol (W3C)):

LIST (LIST)
This command causes a list to be sent from the server to the
passive DTP. If the pathname specifies a directory or other
group of files, the server should transfer a list of files
in the specified directory. If the pathname specifies a
file then the server should send current information on the
file. A null argument implies the user's current working or
default directory. The data transfer is over the data
connection in type ASCII or type EBCDIC. (The user must
ensure that the TYPE is appropriately ASCII or EBCDIC).
Since the information on a file may vary widely from system
to system, this information may be hard to use automatically
in a program, but may be quite useful to a human user.

  1. there is also a ftp command STAT that can be used instead of the LIST command. i was wondering if this cmd is better suited for the implementation in the line above (RFC 959):

STATUS (STAT)
This command shall cause a status response to be sent over
the control connection in the form of a reply. The command
may be sent during a file transfer (along with the Telnet IP
and Synch signals--see the Section on FTP Commands) in which
case the server will respond with the status of the
operation in progress, or it may be sent between file
transfers. In the latter case, the command may have an
argument field. If the argument is a pathname, the command
is analogous to the "list" command except that data shall be
transferred over the control connection. If a partial
pathname is given, the server may respond with a list of
file names or attributes associated with that specification.
If no argument is given, the server should return general
status information about the server FTP process. This
should include current values of all transfer parameters and
the status of connections.

sorry for wasting your time

best regards,

juergen

@artembilan
Copy link
Member

Thanks for such a thorough investigation and explanation!
So, according to the mentioned RFC, the server must reply with file info for LS on the file.
You suggest to back up it with a STAT. However there is no guarantee that server won’t answer well even for that command .
what I mean that it might be better to move away from such a server which does not follow RFC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-reporter Needs a feedback from the reporter type: bug
Projects
None yet
Development

No branches or pull requests

2 participants