Columns: Newest/Oldest filedate columns with filtering

This script provides columns which show the filedate of the newest/oldest file below each folder.
The scripts works properly on my computer, but no guarantees are given.

This adds the following columns:

  • Newest (Create)
  • Newest (Modified)
  • Oldest (Create)
  • Oldest (Modified)
  • Days Ago (Create)
  • Days Ago (Modified)

You can exclude filespecs from being considered when it determines oldes/newest file.
Each exclusion must be on its own line.
You can enable/disable recursion in options.

You can also enable/disable recursion in a button:

@toggle if $src:FolderDateInvertRecursive

Example: You want to get show the newest filedate, but you want to exclude *.txt then you'll
just add *.txt on a line in the exclusionFilter option, and the columns won't consider them when calculating the newest/oldest date.

This script doesn't provide filenames and so on, just filedates. Instead it allows you to exclude files you don't want to consider.


Requires Directory Opus 11.5.2 or above.

  • ColFolderDate.js.txt (9.6 KB)
  • Download the file and then drag it to the list under Preferences / Toolbars / Scripts.


If you don't need exclusions, but you want filenames etc you might want to use this script:

Suggestion: col.justify = "right";

Just tried it just for fun, it works! o)
For a recursive column I expected things to be quite slow, but once it did all folders, another refresh the root of my 100gb C:\ bootpartition e.g., took only about 30 seconds to get all folders fully refreshed (c:\windows taking the most time of course o).

Thanks for sharing! o)

Good :slight_smile:

If you only need to sort the folders based on the files inside the subfolders (excluding folders inside them) you can use the non-recursive columns.
They're obviously alot faster.

I use the script that has the recursive option rather than columns myself..
If I need recursion I can just enable it in options without fiddling with showing/hiding different columns.
Others might want to have both recursive and non-recursive columns available at all times, which is why there's two different scripts.

Idea: What about checking/setting a global DO variable, like "Scripts.FolderDateColumns.Recursive" to toggle recursive mode?
That script setting still can be used if that variable has not been set. That way you could toggle recursiveness even quicker from a button! o)

The same button could turn off the recursive columns and turn on the other columns in their place (or vice versa), without the need for a variable.

Idea: What about checking/setting a global DO variable, like "Scripts.FolderDateColumns.Recursive" to toggle recursive mode?
That script setting still can be used if that variable has not been set. That way you could toggle recursiveness even quicker from a button! o)[/quote]
Well, I guess you could (although I didn't find the object Scripts in the documentation), but then comes the issue with having to provide
both a button and the script..and/or finding some way to keep the config and the global in sync.

If the script configuration isn't read/writable by SET, and the global isn't read/writable through the scriptconfig page they have to be kept in sync somehow.

@leo, This is why the FolderDateColumns has an option that allows to turn recursion on/off in the scriptconfig. It doesn't need to replace columns and such.
It would be preferable if I could enable/disable recursion through a button OR in the scriptconfig though. Implementing it is another thing.

What if someone wants recursive columns in one folder, and non-recursive in another? A global option doesn't make as much sense to me as separate columns which people can toggle on and off as they wish.

After thinking a fraction of second.. I think you're right Leo. Having something to toggle the column behaviour globally is kind of nonsense if you can toggle columns by some button and by using standard DO functionality many users already know about. A tab-scoped variable instead of a global one, would get close to this, but still has some little drawbacks, so really no usecase for rather non-obvious variables here. That said, exchanging a column for another can be a bit tricky regarding its position, as well as it carries potential to flicker and alter the display a bit each time.

There is no object "Scripts", sorry If i mislead you. "Scripts.FolderDateColumns.Recursive" was meant to be the name of the variable (with some kind of namespacing in the front, to avoid a loose global variable like "Recursive", which you cannot connect to your columns in any way). To check for a global var, you would use "DOpus.vars" and that's to be found in the documentation of course.

Not necessarily I think. Now first of all, let's forget about using variables for switching column-behaviour, I think we learned something here? o) But when thinking of a globally running script, like the Tab-Labelizer (which relabels all DO tabs dynamically), a tab or lister scoped variable to override its prefs-defaults does make sense indeed (I think at least). There's no other way right now for such a globally working script to be altered in behaviour for a specific tab or lister.

Using a small script is probably best. Then it can use the Format object to get the column positions.

Removing a column and adding another doesn't usually flicker much, and will be less visual change than doing a full folder refresh (which is what you'd need for the variable or similar methods).

That required folder refresh is a valid point!
So great, we have another command to do, which smoothly switches between a set of columns. o)

The Set command can do that already.

I quickly browsed the docs, to me it still looks like there's no way to replace a column with another, so that position and width will be kept absolutely the same for the old/new column.
I may assume that's also why Leo suggested doing it with a script, but in case we're wrong, pls let us know how to do it with SET. o)

In case you're wondering..I'm working on the FolderDateColumns script.
The other one allows you to change columns and whatever through buttons already (by adding/removing columns in said button).

I wonder how to get @toggle to work properly based on the value of a tabscoped variable..
A line such as this above the script doesn't seem to work:

@toggle if $src:FolderDateColumns_recursive=true

instead the above will be in the down state no matter what value it has, or what it is compared to (right side of the equal sign) as long as the variable is set.

Basically, the =value part appears to work only with internal variables such as this:

@toggle:if !VIEW=Details

A tabscoped override that simply inverts the scriptconfig's setting seems to work..

Btw, GO REFRESH=SOURCE seems to deselect selected items whether it is used in a button or through a script even if @nodeselect is used in the button and/or .command.deselect=false is used in the script.

New version uploaded.

With the displayForAll option enabled I guess it is possible to replace the create/modified column with the
corresponding column(s) from these scripts. The downside is that the scripted column is slower than the
original created/modified columns.

When displayForAll is enabled

  • if the folder is empty, or contains only excluded files it displays the regular created/modified filedate.
  • if it is a file, it displays the regular created/modified filedate.
  • otherwise it displays the calculated date according to the column.

When disabled:

  • if the folder is empty, or contains only excluded files, the column is empty.
  • if it is a file, the column is empty.
  • otherwise it displays the calculated date according to the column.

For the FolderDateColumns script it should now be possible to have a default recursion mode set, while
having the option to invert it (per tab) through a button as shown in the example in the top post.

In case this isn't obvious.. by invert I mean that if you have enabled recursion in the script options then
FDInvertRecursive will disable it for the current tab, or if you disabled it in the script options it will be
enabled for the current tab.

I'm not sure if FolderDateColumnsRec is really needed after the latest changes to FolderDateColumns.

Hi myarmor. The posted Scrips description says version 0.2.1 but the script says 0.2.