> We will most likely need pattern matching for my use case. Things > like "keep the files named *.log" or "keep everything in foo/bar/ > recursively". For this to work we'll need to more or less duplicate > what DirectoryScanner does but could be faster for all the constant > file names by using a set lookup. I'm absolutely willing to drop > selector support for files to keep. > > Hmm, maybe we can speed up DirectoryScanner to make it recognize > "constant patterns", store them in a set and consult this set before > doing a linear search on the real patterns? This would address your > concerns and provide an easy implementation for what I wanted to do > with <sync> and speed up DirectoryScanner for large-ish sets of > constant filenames at the same time.
If you can achieve that, then I don't have objections any more. A simpler approach is to keep the old removeOrphans method to be used when your new "don't touch some files from the dest. dir" feature is not used, and use the new DirectoryScanner-based one otherwise. This way we keep *speed* backward compatibility (which I believe we should be more careful of, as the recent slowdown of Zip reminds us), while still enabling the new use cases. But of course speeding up DirectoryScanner for 'constant' patterns would be better, since benefiting not just <sync>. It's more work than what the alternative I propose though, which could be used as a stop gap solution until DirectoryScanner is effectively made more efficient to better scale. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
