Apply the same file filtering in both directions

[eblen]

See comments for bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=348939

This is non-trivial, because we need to refactor the code a little, separating out file matching and binary file filtering, and of course filtering binary files remotely is not easy.

[rolandschulz]

yes we should just ignore the binary issue remotely for now. Unless we have
some idea how we can do it. But I like that it is in the same function.
Maybe we can just let the function autodetect whether this is a remote or
local path and in one case just ignore the binary issue. I like that better
than that the caller has to have this logic (e.g. by calling only one or 2
functions depending on whether it is local or remote).

On Thu, Jun 9, 2011 at 5:20 PM, eblen <
reply@reply.github.com>wrote:

See comments for bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=348939

This is non-trivial, because we need to refactor the code a little,
separating out file matching and binary file filtering, and of course
filtering binary files remotely is not easy.

Reply to this email directly or view it on GitHub:
#45

ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
865-241-1537, ORNL PO BOX 2008 MS6309

[eblen]

Done in commit 21c6af7 We still use only one function, but now it is invoked for both directions. To solve the binary file issue, the filter returns false (do not filter) for files not recognized by CDT. Since the filter only inputs file names, it can only look at local files. Thus, remote files are not sync'ed if they have the same name as binary files filtered on the local side, which is fine.

This particular issue is resolved. A complete solution to file filtering, though, will be more complex and involve a mechanism for users to select/unselect files to be filtered.