I fear that with this aproach, you may have to "rollback" some of the files already scanned because you will detect a loop after you have already looped one or more time (including multiple time the same files).
This "rollback" will be required if you want to provide a "clean" fileset when the patterns (and file system) would give infinite loop. The other aproach might be to fail the build if an infinite loop is detected. What is wrong with the failing aproach? It is simpler to implement, will be faster to execute, don't requires an additional parameter and is I think easier to understand for the user (he don't need to understand what files are included if its pattern contains a loop). 2008/9/8 Stefan Bodewig <[EMAIL PROTECTED]>: > OK, combining suggestions by Gilles and Dominique here is what we > could do: > > * add a new sttribute for maxSymlinkRecursionDepth (better name > appreciated) and make it default to 5 (up for discussion as well). > This limits how many times the same symlink can be followed. > > * Keep a stack of simple directory names (only the file name portion, > no leading directory and certainly not the canonical path) that > holds the names of all directories traversed so far while doing the > traversal. > > * If the same simple name appears for the MAXth time, check whether > that directory is a symlink. If it is, check its canonical name and > the canonical names of all other occurances of directories with the > same name. If they all point to the same location, ignore the > directory. If they point to different locations recurse but revisit > things if the same name is encountered for the (MAX + 1)th time and > so on. > > This should address infinite loops and it should avoid > getCanonicalPath as much as possible. > > I first thought it would be enough to check whether the link pointed > to a parent directory but it is possible to create inifinte loops with > two "cooperating" symlinks where neither link would point to a parent > of its own. > > Does that sound OK? > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Gilles Scokart --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
