Sorting by modification time

[tmummert]

Dear community,

my goal is to sort files and directories by modification time.

The documentation provides an example for a custom function:

sort_function = function (a,b)
    if a.type == b.type then
        return a.path > b.path
    else
        return a.type > b.type
    end
end

How can I adapt this function?

Thank you very much!

[cseickel]

That is going to be real tricky because it does not currently collect the modified time when it scan the filesystem, just the name and the type. To make this work you would need to lookup the modification time by yourself.

That would of course be crazy inefficient in a sort function so you would need to create a lookup table outside of that function so that it is only looked up once per node. You would then need to take care to invalidate that cache. I would probably have the lookup be something like this:

local modified_lookup = {
  ["my/file/name.txt"] = {
    modified = 1692279525, -- unix epoch time
    lookup_time = 1692279525 -- last time it was read from the file system
  }
}

local function get_current_time()
  -- implement this
end

local function get_modified_time()
  -- implement this
end

local function get_modified(filename)
  local val = modified_lookup[filename]
  local lookup_time = val and val.lookup_time or 0
  local now = get_current_time()
  local age = now - lookup_time
  if age > 1000 then
    val = nil
  end
  if not val then
    -- get the modified time
    modified = get_modified_time(filename)
    val = {
      modified = modified
      lookup_time = now
    }
    modified_lookup[filename] = val
  end
  return val.modified
end

local sort_function = function (a,b)
    local a_mod = get_modified(a.path)
    local b_mod = get_modified(b.path)
    if a.type == b.type then
        return a_mod > b_mod
    else
        return a.type > b.type
    end
end

[miversen33]

Any particular reason we don't go the other route and store the basic stat info with the node when we get it asynchronously here or synchronously here.

It would take a bit of changing how we put the nodes together in the create_item function but we can actually store whatever we want in the node.extra attribute as its always passed back from nui. This is how I go about saving certain metadata that I don't feel like looking up on for nodes in netman.

[cseickel]

None. I was just providing a solution that could be done in user config.

I wasn't sure if modification time was already being returned by the functions we use. If it is then we should just store extra data like that. If it is a separate call though, it would hurt performance and we should not do that in core.

[miversen33]

I'm not in front of my computer right now but IIRC the luv.fs_stat returns general Nixy stat results. I'll verify but I believe we are simply discarding the mod time (along with a lot of other stat stuff) right now.

If I'm correct, we could probably do something like extra.stat and just store a structured stat dump of each node.

Also note, fetching that info as an extra call is very fast (though not negligible). I wouldn't discard that as an option without testing to see if it's a "visible" speed decrease on large file systems (if stat doesn't return that info already and we decide to do something within the filesystem source)

[miversen33]

Checked out the fs_stat doc, ya mtime is in there. So we already have the data available to us :) We just need to store it (if we want to do so).

[cseickel]

We should do that. Wouldn't it be awesome to have the option to display all of these details in columns? It really wouldn't be hard to do at all...

[cseickel]

This discussion has inspired me to start collecting AND showing these extra stats. It's still a WIP but see here: #1107

The next logical step would be to add the ability to sort on any column.

[cseickel]

This functionality was just merged to main @tmummert. Use om to sort by last modified.