select lt.orphan.files overides cutoff:<|>ndays

[armsys]

#Sample script
load a: b:
expand all
# Exclude all files 3 days old
filter cutoff:<3days
select lt.new.files lt.orphan.files
copy lt->right

In this case, if the corresponding files in drive B: do not exist, all files will be copied from drive A: to B:, regardless of the age as imposed by filter cutoff:<3days.

Beyond Compare version 2.1.1 (Build 215)

Do you encounter the similar issue?
Is it an anomaly? Is it logically sound?
On the other hand, all previous version (1.x) worked as expected.

Armstrong
Hong Kong

[Pete]

Hmm, it seems like a bug to me.

[Craig]

I wasn't able to repeat this here. Using your sample, only files newer than 3 days old were copied.

The script you included in your support email was slightly different, and there was an issue there. That also had lt.orphan.folders included in the select command, and would cause the problem you're describing. If you select and copy folders all of it's contents are copied, regardless of any filters that may be in effect. Since you're using an expand all command too, the files in the subfolders will be copied anyway.

That's the intended behavior. If v2.0.x worked differently it was a bug in the older releases that has been fixed.

[armsys]

Craig,

You're right. select lt.newer.files lt.orphan.files lt.orphan.folders was stated in my email.

Nonetheless, it's more logical if the filter cutoff:[<|>]ndays is obeyed, regardless whether orphan.folders is asserted or otherwise. In case of an orphan folder, the folder date should be checked before being copied to the other side. It just doesn't make any sense if the folders older or newer than the asserted cutoff date are still copied to the other side.

What if the files inside the orphan folder? Well, in this scneario, if the file(s) meet(s) the cutoff date condition, the file(s) and the containing folder(s) should be copied to the other side.
Let's discuss an actual scenario. On my notebook, I have all articles of Scientific American stored in the following directory structure:
c:\Download>SciAm>196001
c:\Download>SciAm>196002
c:\Download>SciAm>196003
.
.
.
c:\Download>SciAm>196012
c:\Download>SciAm>196101
.
.
.
c:\Download\SciAm>200402
You can see that a new folder is created for every new issue of Scientific American. That's, it becomes so-called orphan folder. On my desktop, I keep 12 issues (months)of the magazine and older issues are deleted from the desktop during periodical maintenance. Logically, my copy rule would expect--only copying the current issue (orphan folder) from my notebook to the desktop.

The latest version of BC (2.1.1) fails the above rule, which was possible in version 1.x. Hope a fix will be released soon.

Armstrong
Hong Kong

[Craig]

Armstrong,

There are two commands that are equivalent to BC 1.9's /syncright command line switch:

select lt.newer.files lt.orphan.files
copy left->right
-or-
sync visible update:lt->rt

If you use either of those two commands, 2.x works exactly like BC 1 does. It's only when you add lt.orphan.folders to the selection that things work differently than you're expecting.

There are two things that are causing trouble: Copying, moving, or deleting a folder affects all of it's children, regardless of any filters. The Synchronize Folders commands do respect filters.
Folders are not affected by cutoff, size, or attribute filters. We may add a "filter hidden and system folders" setting, but I don't expect us to ever make the cuttoff filters affect them.
I understand your arguments, and we are consideringing changing (1) in a future release, but that would be an enhancement, not a bug fix. The current behavior was a concious design decision, and will likely stay through v2.x.