#757: rsync ignores .rsync.rules files in the Cactus ROOT directory ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- It seems that rsync, since simfactory never uses the Cactus root directory as a source, does not merge any .rsync.rules files in the root directory into filter.rules. .rysnc.rules files work fine in the sub-directories, eg. bin/ lib/ etc. Since I would like to have global .rsync.rules valid for all subdirectories, a workaround is to replicate the file .rsync.rules in all (top-level) subfolders via symbolic links.
#757: rsync ignores .rsync.rules files in the Cactus ROOT directory -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by hinder):
I recently added the ability to use simfactory/etc/filter.local.rules as a global rules file.
#757: rsync ignores .rsync.rules files in the Cactus ROOT directory -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by rhaas):
filter.local.rules is precisely what I was looking for, thank you. I wonder if it might be a good idea to (before the next release) rename simfactory/etc/filter.local.rules to $ROOT/.rsync.rules to use the same name as the per-directory merges in simfactory/etc/filter.rules. This would make .rsync.rules files work in the full tree rather than just the subdirectories and files listed in simfactory/etc/defs.ini/sync-sources.
#757: rsync ignores .rsync.rules files in the Cactus ROOT directory -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by hinder):
I don't really see the point of .rsync.rules files throughout the Cactus tree. Are these committed to the repositories of the respective thorns? Isn't the decision about what to sync something that is made by the individual user about their use of their particular Cactus tree with SimFactory, and hence should be kept along with the other SimFactory configuration files? Where do you use these .rsync.rules files? What happens when you change Cactus tree? Do you collect them all up and copy them to another tree? I think having these rules in a single place makes much more sense.
#757: rsync ignores .rsync.rules files in the Cactus ROOT directory -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by rhaas):
As far as I can tell they would not be part of thorns. They come about because filter.rules contains a like "{{{: .rsync.rules}}}" which apparently that rsync will merge in such a file in any directory is syncs (section PER-DIRECTORY FILTERS in rsync's manual, similar to what the -F option does). I believe (but the other of filter.rules would have to confirm) that these files are intended to serve the same purpose as filter.local.rules ie. to give the user the option to modify rsync's filter rules without having to modify version controlled files. I believe that rsync looks for such files in any directory it encounters. I fully agree that (at least having the option of) having all rules in a single file is desirable. Per directory files can be convenient of one eg. wants to exclude only tests in certain thorn (eg. because it contains large hdf5 data files) since these per-directory rules are automatically anchored in the containing directory. I don't really have a strong preference for one or the other and really only wanted to point out that right now there are two similar but not identical ways to have "local" filter rules.
trac@lists.einsteintoolkit.org
-
Einstein Toolkit