Getting a FileEntry by path

[LoganDark]

In my file watcher I'm performing some extra operations on certain files (when they're in a special folder, I do some parsing on them and set metadata so that the rendered items can display this data). I can't seem to get a hold of the FileEntry corresponding to some path.

I need to do this to update metadata when renames happen. My application uses atomic writes so I need to re-do the detection and parsing logic when something is renamed.

model.root.inotify seems to know what to do with paths so how come I can't do the same?

[LoganDark]

Maybe this is an XY problem and the real solution would be to allow me to modify metadata using inotify. Doesn't really matter in the end

[zikaari]

IsforceLoadFileentryAtPath not returning you the handle?

Also since you say you are trying to get a handle after the rename, could it be that you are querying the old file by mistake?

Also note that if inotify is used properly, the FileEntry object reference remains the same even after it is renamed, again this is assuming inotify was provided with appropriate info.

[LoganDark]

IsforceLoadFileentryAtPath not returning you the handle?

I... did not know that function existed.

Also since you say you are trying to get a handle after the rename, could it be that you are querying the old file by mistake?

Considering I couldn't find out how to run any query, no.

Also note that if inotify is used properly, the FileEntry object reference remains the same even after it is renamed, again this is assuming inotify was provided with appropriate info.

Exactly, this is why it's not being populated with the correct metadata.

I'll try out forceLoadFileentryAtPath, but I'd prefer not to force a load if aspen is not yet interested (i.e. parents haven't been expanded and such).

[LoganDark]

Turns out none of that was needed.

The solution I settled on was to check if, during a rename, the new path is a different "kind" of file than the old path (as in the metadata needs changing). If so, just delete the old path and use an Added event to create the new one.

The code looks something like this:

[LoganDark]

Now I need this for a different reason - chokidar likes to fire 8 billion add events immediately upon startup, and there is no way to turn that off. Aspen reads the files, but then chokidar fires its 8 billion add events for those entries that already exist - long story short, there end up being multiple instances of the same path in the tree view.

Alternatively aspen-core could like not add duplicate entries since this apparently is such a common behavior that not a single chokidar issue mentions it.

[zikaari]

Did you try the ignoreInitial option of chokidar?

[LoganDark]

Did you try the ignoreInitial option of chokidar?

I did not know that existed, it has such a non-obvious name. I literally did search all the members of WatchOptions too. Thanks