Efficient way to monitor file creation on volume

Software Native
1

I’m looking for an efficient way to monitor a volume for new files being created.
I need to make sure that certain custom attributes I’m using in my application are not replicated to new files.

Tried with NodeMonitor and checked out some Haiku test source which fills in some important information missing from the API docs (mainly the fields and opcode in the notification message).

However, I get notified on every stat change even when explicitly checking for B_ENTRY_CREATED.

How can I do this or what am I doing wrong?

2

The BeBook covers node monitoring and explains what all of the fields do.

1 Like
3

I’m not sure I fully understand what you need, but, if the attributes are indexed then you might be able to use a live query.

1 Like
4

Of course! Good idea, I’ll try good old live queries then.
Love the documentation btw😅

A live query is the gift that keeps on giving

1 Like
5

thanks again for the nudge into the right direction @Lrrr, works perfectly so far :slight_smile:
Just found a last obstacle when moving files, here I also get the B_ENTRY_CREATED message. Need to find a clever way to differentiate between copy and move…

~/Develop/SEN/sen-core> cp BookNote3 BookNote5
in SEN Server::MessageReceived
checking new node BookNote5 for existing SEN attributes...
found new node BookNote5 with duplicate ID 1573082, stripping all SEN attributes...
removed SEN attribute SEN:ID from node BookNote5
removed SEN attribute SEN:REL:association from node BookNote5
removed SEN attribute SEN:REL:quotation from node BookNote5
SEN server sending result 0
6

There might be some ways to do it by checking the creation time of the file or by tracking the entries created and waiting for a B_ENTRY_REMOVED for the moved file. It can get a bit tricky to keep track of the refs though. I’m not sure if it would take too much CPU time but you could start a second non-live query on the specific ID to see if you get more than one result.

1 Like
7

Maybe it’s worth looking at the PathMonitor to see how this case is handled and take inspiration.

1 Like
8

Thanks @Lrrr I tried with the first approach, caching the attribute to check on B_ENTRY_CREATED and checking for that in B_ENTRY_REMOVED, but it did not work as expected, so I went with the query (was also my initial thought but feared it would be too expensive, which is not the case - going to the FS for a kind-of-hash-query vs. hash lookup in my own code is not that much of a difference after all).

Thenks @Nexus-6 for the link, but from what I could gather it’s far more complex than needed here :sweat_smile: