I have this big folder where I dump a lot of things (let's call it root) and I have it sorted by date modified. I know by looking at the first two rows that these are fresh things I'm still working through, and whenever I'm done with them I'll put them in the correct place. However, sometimes the modifications I'm doing to something are 2 folders deep, and no modification is necessary 1 level deep, and that results in the folder not changing its sorting on the root folder, and me forgetting that I'm not done working on it. This seems to be because the date modified algorithm simply looks at the folders in the current directory, and doesn't account for anything that happens in their children. Is there a way to modify this behavior? Even accounting for 1 level deeper would be nice.
It's a limitation of the way Windows works unfortunately; file changes in a folder cause the folder's timestamp to be modified but the change doesn't "bubble up" to parent folders.
Dang, no way around it huh? Thanks for the reply.
This might be what you want:
Ooh it might. I'll definitely try it out! Thank you.
Hmm, it doesn't seem to cache results, so every time I go to root it tries to recalculate, and my root has tons of stuff, so it takes upwards of 20 seconds to finish its work and show the correct sorting. Unfortunately that makes it unusable for me.
You can get good speeds with this other one if you use Everything.
Hm, is one of these options equivalent to modified, but recursive? One that takes into account additions, changes, and deletions, all in one? The ones I've been trying don't seem to do all.
Yes...Have you tried it?
If I'm understanding correctly, you just need to use the Newest File Date Modified (Recursive) column at the root level.
The values are tied to Everything's index, so anything Everything picks up through its change tracking would be covered.
Obviously, you'd still need to do a manual refresh if you made (un)intentional changes since the last time the values were calculated (That is, it doesn't automatically detect if the value has changed if that's what you mean, and AFAIK no column could detect something like that in this context). But in a normal scenario (with the necessary content indexed), recalculation should happen in ms.
Yeah that doesn't seem to be working for me. I sorted by Newest File Date Modified (Recursive), deleted a folder 2 levels deep (root/child1/child1-1), and child1's position did not get sorted to the top on the root folder.
You just need to do a manual refresh 
I did hit F5 and waited for the load bar. ;w;
Ok. I've just tested it myself.
Note that to take folder properties into account, you need to set ignore folder properties to False in the script settings.
And there was indeed a bug (I'm not sure if this was already happening when I originally wrote the script or if it's a recent change in EV): when mixing folders and files and asking Opus/EV to return sorted results, folders and files were being sorted separately. Because of that, the first item isn't necessarily the one we actually want.
Please update to v2.1, where this issue is fixed.
Following your example:
Additionally (and this is not a script bug) when you delete a nested file, you'll notice that the containing folder doesn’t update its value. That's expected, since the script doesn't pull information from the folder itself.
However, at least in my case (with your example), the modification date of that folder does get updated to a recent date. To solve this, you could add this Evaluator column that takes the most recent value between the Everything column and the folder's modification date.
XML code
<?xml version="1.0"?>m = modified;
if (!is_dir || !IsSet("scp:EVDirRanges/newest_modified_recursive")) return m;
ev_val = Val("scp:EVDirRanges/newest_modified_recursive");
return ev_val >= m ? ev_val : m;