(In reply to comment #0)
> invalid modifier sequence at 't' in filter rule: -/tmp

You'll note that rule is missing a space, so it was a fitler-rule syntax error.  Rsync treats a failure to parse filter rules as something that it should complain about in a fatal error so that you get a chance to fix it.

So, it seems to me that the issue here is that you're trusting user-generated filter rules in a backup situation, which may not be a good idea (e.g. consider the inclusion of a filter-rule import that references a secret file in order to try to sniff its contents).  What you could do instead is to do a pre-copy restrictive parse of all the filter files in the backup hierarchy and turn them into a single set of global rules, dropping any syntax error lines and ignoring any rules that shouldn't be trusted (you'd have to massage the paths and such).  Then, run rsync with that filtered global exclude list rather than the per-dir filter rules.

Another option is to mark the rules in the filter files as only hide rules (aka a server-side-only exclude) which avoids an unwanted protect-from-deletion effect of a normal exclude (thus users can specify things not to copy, but not prevent things from being removed on the backup server).  This also avoids any prefix/option interpretation in the per-dir files, so rsync won't generate an error reading when it is parsing the files.  e.g.:

--filter=':-s .rsync-exclude'

You'd need to filter all the .rsync-filter files, changing the "- foo" rules into just "foo" in the per-dir .rsync-exclude files for this to work, and let your users know about the new filename (if you indeed change it) and the new syntax.

Thx, for this detailed reply. After reading I think we have to 2 different issues here.


(In reply to comment #1)
> (In reply to comment #0)
> > invalid modifier sequence at 't' in filter rule: -/tmp
> 
> You'll note that rule is missing a space, so it was a fitler-rule syntax error.

1. I'am sure the there was never a syntax error in .rsync-filer. Instead the error occurred because the user added effectively a single character while rsync was reading it. (The same reason why bash scripts show syntax errors when editing them during execution).
So think it would be worth to improve rsync's way of reading the filter files all about because rsync is suppossed to run for hours to sync directories while they are used and it's able to handle vanished files etc.
I'd even wondered why rsync has read that particuar .rsync-filer again after being 10 hours inside that directory already. 
I haven't watched the source code but I guess it would help simply to avoid file operations like fseek on the filter files.



>  Rsync treats a failure to parse filter rules as something that it should
> complain about in a fatal error so that you get a chance to fix it.

2. So I this would put this on the wishlist:
 new option --ignore-broken-filters
 Behaves like in case of vanished files. Just print a warning but don't exit an ignore the broken filter. When sync is finished exit 2; 
 


> So, it seems to me that the issue here is that you're trusting user-generated
> filter rules in a backup situation, which may not be a good idea

Because all our users have to do with very large amount of data I want them to help me with the filter rules.


> (e.g. consider
> the inclusion of a filter-rule import that references a secret file in order to
> try to sniff its contents).

My users can only write the filter files into their own dirs. If they want to backup their own secrets then this is not my problem.


> What you could do instead is to do a pre-copy
> restrictive parse of all the filter files in the backup hierarchy and turn them
> into a single set of global rules, dropping any syntax error lines and ignoring
> any rules that shouldn't be trusted

This would be possible and I even though about this to implement more intelligent filters than simple in/exclude lists. But in practice
find /home -name ".rsync-filter"
takes about 1-2 hours here with high IO load on the file server and it would slow down the whole backup process about 20-30%.




> Another option is to mark the rules in the filter files as only hide rules 

A good idea regarding the security points above but regarding point 1 it woud be a fake. rsync would not exit with fatal error but would use a totally messed up filter if user changed it during backup process.


cu,
Rudi

(In reply to comment #2)

I have to admit that I was wrong about my point 1.
There was no error because the user changed the filter. It was another filter file from a different directory which was broken. All this together happened randomly within seconds so I got the wrong view on it.

Anyway point 2. is still on my wishlist and matches the subject of this enhancement request.