HELP! Weird bug in commons.net.ftp

[Philippe Desrosiers]

I've been using commons.net.ftp.FTPClient for over a year now, without any problems. Suddenly, when calling FTPClient.listFiles(), some of the entries in the returned list are NULLs (ie: some of the files on the server are listed, and some result in NULLs). But FTPClient.listNames() returns the filenames correctly! I'm at my wits end. Has anyone else had this problem before?

Here's some sample code:

    import java.io.*;
import java.net.*;
 
import org.apache.commons.net.ftp.*;
 

public class FtpTest {
    private static final int CONN_TIMEOUT = 60000;
    private static final int DATA_TIMEOUT = 600000;
    private static final String HOST_NAME = "ftp.mydomain.com";
    private static final String PASSWORD = "password";
    private static final String USER_NAME = "login";
    private static final boolean PASSIVE_MODE = false;
    private static final String REMOTE_PATH = "/remote_path";
 
    public static void main(String... args) throws SocketException, UnknownHostException, IOException {
        /*
         * TODO: Use the FileTransport Pattern to multi-thread the transfer
         * process. Is this possible without multiple FTPClients?
         */
        FTPClient client = new FTPClient();
        
        client.setDefaultTimeout(CONN_TIMEOUT);
 
        System.out.println("connecting to " + HOST_NAME);
        client.connect(InetAddress.getByName(HOST_NAME));
        
        System.out.println("Connected. Authenticating user '" + USER_NAME + "' with password '" + PASSWORD + "'.");
        client.login(USER_NAME, PASSWORD);
        
        System.out.println("Authenticated");
        if (PASSIVE_MODE) {
            System.out.println("using passive mode...");
            client.enterLocalPassiveMode();
        }
        
        client.setDataTimeout(DATA_TIMEOUT);
        System.out.println("changing to REMOTE_PATH " + REMOTE_PATH);
 
        if (client.changeWorkingDirectory(REMOTE_PATH)) {
            System.out.println("getting file OBJECTS");
            FTPFile[] ftpFiles = client.listFiles();
            if (ftpFiles != null && ftpFiles.length > 0) {
                System.out.println("" + ftpFiles.length + " files available.");
                for (FTPFile remoteFile : ftpFiles) {
                    if (remoteFile != null) {
                        System.out.println(remoteFile.getRawListing());
                    } else {
                        System.out.println("<null>");
                    }
                }
            } else {
                // no files available.
                System.out.println("No files found at " + REMOTE_PATH + "");
            }
            
 
            System.out.println();
            System.out.println("getting file NAMES");
            String[] fileNames = client.listNames("*");
            if (fileNames != null && fileNames.length > 0) {
                System.out.println("" + fileNames.length + " files available.");
                for (String remoteFile : fileNames) {
                    if (remoteFile != null) {
                        System.out.println(remoteFile);
                    } else {
                        System.out.println("<null>");
                    }
                }
            } else {
                // no files available.
                System.out.println("No files found at " + REMOTE_PATH + "");
            }
        } else {
            System.out.println("unable to change remote directory to " + REMOTE_PATH);
        }
        client.disconnect();
    }
}

[Paul Clapham]

What changed on your server?

[Philippe Desrosiers]

nothing. But files that were uploaded before yesterday are working fine (they show up in the .listFiles() results), and files that were added since then are returning NULLs in the .listFiles() results (one NULL entry for each file). So I get a mix of normal FTPFile instances, and NULLs.

[Philippe Desrosiers]

update: If I call .listNames(), then cycle through the results, calling .listFiles for each filename, I get an empty array for each problem file...

so like:

String[] fileNames = client.listNames();
            if (fileNames != null && fileNames.length > 0) {
                System.out.println("" + fileNames.length + " files available.");
                for (String remoteFile : fileNames) {
                    if (remoteFile != null) {
                        System.out.println(remoteFile);
                        FTPFile[] fs = client.listFiles(remoteFile);
                    } else {
                        System.out.println("<null>");
                    }
                }
                
                for (String remoteFile : fileNames) {
                    if (remoteFile != null) {
                        FTPFile[] fs = client.listFiles(remoteFile);
                        for(FTPFile f : fs){
                            if (remoteFile != null) {
                                System.out.println(f.getRawListing());
                            } else {
                                System.out.println("<null>");
                            }
                        }
                    } else {
                        System.out.println("<null>");
                    }
                }
            } else {
                // no files available.
                System.out.println("No files found at " + REMOTE_PATH + "");
            }

[Paul Clapham]

Originally posted by Philippe Desrosiers:
nothing.

No, something changed on your server. For example, there are different files on the server today than were there yesterday. And for example today is February 29 and not February 28, although you wouldn't think that software would have leap-year problems after all these years. Something is different.

Have you tried connecting to the FTP server from the command line and doing a DIR command to see what you can see?

[David Sing]

I've just started using the commons net FTPClient in the past two days and today experienced this same problem with files that have a Feb 29 timestamp. Everything has pointed to a leap-year problem with commons.net.ftp.FTPClient.

All other FTP clients have no problems on the same server (not controlled by me but used by '00s of others).

At least it won't bother us again for another 4 years

Dave