Deleted files still show up in search

[Tired-Fox]

Files that have been deleted from the file system still show up in the results. After running FrecencyValidate the files are still there. I have to manually delete them from the DB with FrecencyDelete

[delphinus]

You mean, after you renamed temp\Test.py into temp\test.py and did :FrecencyValidate, it still shows both files in candidates, right?

Strange. I will look into this further.

[Tired-Fox]

That is correct. Restarting nvim doesn't fix anything either. Have to run :FrecencyDelete <full path to file> to remove it

[delphinus]

I found the cause. The decision to distinguish the file's existence depends on vim.uv.fs_stat(filename).type == "file". Even if the filename is foo.lua, fs_stat("Foo.lua") returns stat for foo.lua implicitly. Capital or lower cases does not make sense.

I think this is a limitation of this plugin because vim.uv has the same limitation.

[delphinus]

I'm thinking about an implementation to detect accurate filenames for removing entries.

local function path_exist(path)
  local parent = vim.fs.dirname(path)
  local dir = uv.fs_opendir(parent)
  local entries = uv.fs_readdir(dir)
  for _, entry in ipairs(entries) do
    if entry.type == "file" and vim.fs.joinpath(parent, entry.name) == path then
      return true
    end
  end
  return false
end

If /path/to/Foo.lua does not exist, but /path/to/foo.lua does, path_exist "/path/to/Foo.lua" returns false, although uv.fs_stat "/path/to/Foo.lua" returns a truthy value.

[delphinus]

I stopped to implement this logic above because a significant problem occurs -- symlink. It is too difficult to manage targets if they are symlinks.

I also found one more problem already has been occurring: #230. We should think about more robust logic.

[delphinus]

Now we use realpath to detect filenames. For this case, :FrecencyValidate detects the file definitely exists and removes the entry from DB if it does not exist.