Copy is ignoring Max File Size setting - BUG?

Get help for specific problems
User avatar
Posts: 15
Joined: 19 Feb 2023

justinhow

I have set a max file limit of 201Mbytes on a FFS config that was a Mirror.
I had source files that were between approx 2-3Gbytes and there was no matching destination file. As expected they were not copied.
However I found when the destination folder has files with matching names (names were the same but they were zero byte files) it then proceeds to copy the large source files over to the destination and completely ignores the size limit I had set. See screen shot.
Is this by design, because on the face of it it appears to be a bug?
I am running 12.0 donation edition.
Here is an extract of the FFS Config file and a screenshot:
Screenshot 2023-02-19 111338.jpg
Screenshot 2023-02-19 111338.jpg (201.12 KiB) Viewed 760 times
   <Filter>
        <Include>
            <Item>*</Item>
        </Include>
        <Exclude>
            <Item>*.log</Item>
            <Item>\System Volume Information\</Item>
            <Item>\$Recycle.Bin\</Item>
            .....
        </Exclude>
        <SizeMin Unit="None">0</SizeMin>
        <SizeMax Unit="MB">201</SizeMax>
        <TimeSpan Type="None">0</TimeSpan>
    </Filter>
    <FolderPairs>
        <Pair>
            <Left>H:\</Left>
            <Right>O:\WHS4_COPY\H</Right>
        </Pair>
    </FolderPairs>
Posts: 1037
Joined: 8 May 2006

therube

Unable to duplicate on my end.
No matter what I try, the size maximum is enforced.
If I change the max, the listing interactively updates to show the new files that would be copied - up to the new max.

Are you sure the names on the target end are in fact the same as on the source end?

As in, if you were to manually attempt a copy from one of the files on H: to O:, would you get an overwrite warning?
User avatar
Posts: 15
Joined: 19 Feb 2023

justinhow

You can see from the screen grab above that the files are identical and and that they are also matched by FFS.
I do indeed get an overwrite warning if I move via file explorer.
I have set up a fresh compare between a source and dest folders and get the same results shown here:
First screen grab is with no size limit and is as expected:
No Size Limit.jpg
No Size Limit.jpg (158.5 KiB) Viewed 726 times

Second screen grab is the same exact files with a 1GB MAX size limit and is incorrect as it still shows the 3 large files are to be copied (where a destination file of the same name exists), but the 2 files that have no matching destination file do correctly dissapear:
1GB Size Limit.jpg
1GB Size Limit.jpg (137.77 KiB) Viewed 726 times
Lastly screen grab of the filter:
Filter.jpg
Filter.jpg (119.49 KiB) Viewed 726 times
Posts: 1037
Joined: 8 May 2006

therube

Got me? Still working on my end.
install.wim is marked, displayed as, "won't copy"

And there is nothing "special" about I and O ?

Suppose I ought to test with only a single file or two in each directory?
.
FFS IS respecting Size Filter.png
FFS IS respecting Size Filter.png (57.11 KiB) Viewed 718 times
Still no difference:
.
FFS IS still respecting Size Filter.png
FFS IS still respecting Size Filter.png (43.33 KiB) Viewed 716 times
User avatar
Posts: 15
Joined: 19 Feb 2023

justinhow

I think I might have a clue as to why you are not seeing my problem.
Two differences between yours and mine:
1. You are doing an update and not a mirror (as I am doing)
2. From what I can see your destination install.wim is newer than the source install.wim so it would not want to update it.
This is what I am seeing when I have it set to "update" and a mix of older and newer on the right/destination:
Update.jpg
Update.jpg (156.97 KiB) Viewed 707 times
Posts: 1037
Joined: 8 May 2006

therube

your destination install.wim is newer than the source install.wim
There we go.
I think you've found a bug :-).
.
FFS Size Filter Bug.png
FFS Size Filter Bug.png (19.07 KiB) Viewed 683 times
.
33 should rightfully update, because it's bigger.
install.wim should not, because it does not pass the Size filter.
User avatar
Posts: 15
Joined: 19 Feb 2023

justinhow

Glad we got there - thanks!
Do you take it from here e.g. report it?
I am new at this site so I am not sure of the procedure.
Posts: 1037
Joined: 8 May 2006

therube

Oh, I'm sure Zenju will see this & tell us what we've done wrong ;-).
User avatar
Posts: 15
Joined: 19 Feb 2023

justinhow

I think there is another bug with maximum file size filter.
It appears to stop empty folders being copied to the destination.
See here with 200Mbyte Max Size Limit.
Next Test.jpg
Next Test.jpg (239.83 KiB) Viewed 664 times
Without Max Size Filter:
Next Test without filter.jpg
Next Test without filter.jpg (245.66 KiB) Viewed 663 times
User avatar
Site Admin
Posts: 7210
Joined: 9 Dec 2007

Zenju

This is a known TODO: FreeFileSync has a design problem with regards to the file size and time span filters. Unlike the file path filters, which always apply to both left and right sides of an item pair, these filters can apply to only one side. This raises the question: What should FFS do if e.g. the size filter matches left, but not right?

The current implementation uses the OR-relation: An item pair is included iff either left *or* right side matches the file size filter. Same for the time span filter.

This is obviously not ideal, when you want AND. Question is: How can FFS do better? Is there a design that is simple and avoids asking the user to decide between AND, and OR? Maybe the time span filter is useless and could/should be removed? Maybe even the file size filter should be removed (and integrated into a different concept?).
User avatar
Posts: 15
Joined: 19 Feb 2023

justinhow

Your have probabably thought about this a lot more than me but I would assume this is not an issue for mirror or update which are both unidirectional.
I can indeed see it is more complex when it is a bi-directional sync for example.
May be the filter options should change depending upon the update type (bi or uni).