dupe: behavior changes ...
1.4.1.914
Oh, I think I caught something there, in that some operations caused the duplicated files to "vanish" - when the dupe: criteria no longer applied.
I believe that's what I saw.
Anyhow, thinking I actually liked the old behavior better, where the user had to actually affect an update, like minimally changing the search term, then immediately reverting that.
As it was, you may have been left with something "wrong", wrong in that it no longer belonged on the (dupe:) list, but by remaining it also left context as to what had happened. Now, that context just "vanishes", if you will. (And with brain cells fading , that context, even though "wrong", can be helpful .)
dupe: behavior changes
Re: dupe: behavior changes
Can you give an example of that?
Re: dupe: behavior changes
The behavior should be the same, that is dupe: does not update in real-time.
Perhaps the left over file changed in some way? Everything will recalculate if the file should be shown in the result list if any change is detected, such as
attributes changing, data being written to the file, the file being renamed etc..
Perhaps the left over file changed in some way? Everything will recalculate if the file should be shown in the result list if any change is detected, such as
attributes changing, data being written to the file, the file being renamed etc..