Bug 4411 - FTP task scandir method bug
Summary: FTP task scandir method bug
Status: CLOSED INVALID
Alias: None
Product: Ant
Classification: Unclassified
Component: Optional Tasks (show other bugs)
Version: 1.4.1
Hardware: All All
: P3 normal (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords: PatchAvailable
: 8434 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-10-25 00:26 UTC by Edouard Mercier
Modified: 2004-11-16 19:05 UTC (History)
3 users (show)



Attachments
The FTP.java source correcting the bug (30.55 KB, text/plain)
2001-11-09 04:38 UTC, Edouard Mercier
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Edouard Mercier 2001-10-25 00:26:50 UTC
Hi;

before all, thank you so much for the FTP task which makes my life easier.
I have an heavy use of this task, and I discovered some weird behavior when 
handling remote files within nested directory from the remoteDir.

I took a look a the code, and eventually discovered the bug in the
protected void scandir(String dir, String vpath, boolean fast)
method from class
org.apache.tools.ant.taskdefs.optional.net.FTP

The bug is due to a confusion between file name and relative path name. Here is 
the fix that I propose. I've tested it and it seems to be allright now.

Do not hesitate to ask for anything, but please fix the bug in the next release 
because I'm working with my own version of optional.jar and it's not very 
comfortable.

Bests regards,
Edouard Mercier



        protected void scandir(String dir, String vpath, boolean fast) {
            try {
                if (!ftp.changeWorkingDirectory(dir)) {
                    return;
                }

                FTPFile[] newfiles = ftp.listFiles();
                if (newfiles == null) {
                    ftp.changeToParentDirectory();
                    return;
                }

                for (int i = 0; i < newfiles.length; i++) {
                    FTPFile file = newfiles[i];
                    if (!file.getName().equals(".") && !file.getName().equals
("..")) {
                        if (file.isDirectory()) {
                            String name = vpath+file.getName();
							if (isIncluded(name)) {
								if (!isExcluded
(name)) {
								
	dirsIncluded.addElement(name);
									if 
(fast) {
									
	scandir(file.getName(), name+File.separator, fast);
									}
								} else {
								
	dirsExcluded.addElement(name);
									if 
(fast && couldHoldIncluded(name)) {
									
	scandir(file.getName(), name+File.separator, fast);
									}
								}
							} else {
							
	dirsNotIncluded.addElement(name);
								if (fast && 
couldHoldIncluded(name)) {
									scandir
(file.getName(), name+File.separator, fast);
								}
							}
							if (!fast) {
								scandir
(file.getName(), name+File.separator, fast);
							}
                        } else {
                            if (file.isFile()) {
                                String name = vpath + file.getName();
								if (isIncluded
(name)) {
									if (!
isExcluded(name)) {
									
	filesIncluded.addElement(name);
									} else {
									
	filesExcluded.addElement(name);
									}
								} else {
								
	filesNotIncluded.addElement(name);
								}
                            }
                        }
                    }
                }
                ftp.changeToParentDirectory();
            } catch (IOException e) {
                throw new BuildException("Error while communicating with FTP 
server: ", e);
            }
        }
    }
Comment 1 Stefan Bodewig 2001-10-29 07:21:34 UTC
Any chance you could provide the patch as an attachement using "cvs diff -u" or
similar?
Comment 2 Edouard Mercier 2001-11-09 04:38:55 UTC
Created attachment 778 [details]
The FTP.java source correcting the bug
Comment 3 Edouard Mercier 2001-11-09 04:42:00 UTC
What else should I say?
Yes, I have also developed an additional feature for this FTP task, which 
enables to create a Java property file listing all the remotely listed files on 
the server, instead of the default file when "listing" action is asked for.
I think this feature is really useful.
Comment 4 Stephane Bailliez 2001-11-16 15:09:21 UTC
Edouard, as Stefan says, the fact that you post the whole file or a simple 
snippet makes it difficult to see what are the real changes you did.

As we don't even know what is your reference source, it makes it even more 
difficult to do a diff. Plus in the whole file you added a loop to print out 
statements in french that you commented. statements are commented but the loop 
remains.

If you don't know how to deal with cvs, please identify *clearly* the lines you 
changed. As far as I can see the changes are related to the case "if 
(file.isDirectory())" where you moved up the vpath + file.getName() and you 
added a

if (fast && couldHoldIncluded(name)) {
  scandir(file.getName(), name+File.separator, fast);
}

you did a change in listFiles as well.

Please confirm this ASAP with the motivation.
Comment 5 Stefan Bodewig 2002-04-08 12:08:44 UTC
I don't think that a bug in an optional task should be a blocker, much less
if the original reporter has lost interest in it.
Comment 6 Edouard Mercier 2002-04-15 07:30:05 UTC
Hello to all;

I did not lose interest to that bug!
What do you expect me to do in order to fix that bug? By the way, I remind you 
that this is an actual bug at the beginning, even if I eventually talk about a 
possible extension of the ftp task...

Why did I not send just the CVS difference with the current 
org.apache.tools.ant.taskdefs.optional.net.FTP
 class? Because, I currently do not benefit from a connection to the CVS 
server, for I am behind a fierce firewall.

But, as you can see, I also sent an attachment which the complete class.

I am pretty interested in any Ant further development. Besides, I have 
developed a task that integrates Jindent. I am currently developing a task that 
generates AntDoc for an Ant script. I do not think I am lazy, so just tell me 
what to do in order to close that bug, and I will do my best !

Best regards,

Edouard
Comment 7 Stefan Bodewig 2002-04-15 09:59:01 UTC
I am glad you haven't lost interest, it just looked that way as you didn't respond
to Stephane's question.

You can easily download the latest CVS version from the webcvs frontend, patch it
so it does what you want and create a plain "diff -u".  The problem with
submitting the whole file is, that the change itself is rather difficult to track.

I've just diffed your file (ignoring whitespace changes) against the latest CVS
version and have found some changes that don't seem to be related to what you want
at all - so please help me understanding your changes.

The format of the listFile method is the way (some) people want it, so if you
want a different format, you should make that a new option.

If I understand your patch correctly, FTP right now will not look at the
directory part of a file name when matching includes/excludes, which you now
enable.  Correct?

You also add a new conditional scandir call inside the part that handles
excluded directories.

I think you are correct and have committed a change to that effect - could you
please see whether nightly build 2002-04-16 works as expected?
 
Comment 8 Edouard Mercier 2002-04-15 17:39:13 UTC
OK, after a close look at the org.apache.tools.ant.taskdefs.optional.net.FTP 
class, I come tot the conclusion that there is no more bug concerning the 
scandir method. The bug has been fixed meanwhile by someone who forgot to close 
that bug #4411.

Sorry for the disturbance. Thank you for your work.

Stephane, my error was to have forgotten to remove my specific listing format, 
so do not take this into account.

Edouard
Comment 9 Stefan Bodewig 2002-04-16 06:02:33 UTC
I was the one who fixed the bug just yesterday 8-)

I didn't close the report because I wanted you to verify I had fixed it.  Thanks.
Comment 10 Stefan Bodewig 2002-04-24 11:47:43 UTC
*** Bug 8434 has been marked as a duplicate of this bug. ***