Page 1 of 2

Dos notifications - Anyway to get more event information

Posted: Mon Jul 08, 2013 6:30 pm
by theamigaone
I'm working on my Nephele project (cloud storage access, dropbox etc), after looking into notifications it seems its either gonna be limited or very hard to get the information needed. Mainly I need to know what file has changed/added/deleted within a directory. I know you can create a notifyrequest per file, but then this wont recognise new files and if I notify on the directory i'm gonna constantly get double(or more) notifications for the same edit. All fine when less that 100files but what happens if someone syncs 5000files in one directory.

Is there some technique thats available that i'm missing? I'm worried about having to use like 60000 or more notifyrequests + listnodes, I dont want it to hog memory if possible

PS My app will hold a database of all files avail to be synchronised

Re: Dos notifications - Anyway to get more event information

Posted: Mon Jul 08, 2013 6:57 pm
by ZeroG
You could use the archive file attribute.

Re: Dos notifications - Anyway to get more event information

Posted: Tue Jul 09, 2013 12:34 am
by colinw
Hook notifications are all you have publicly available.
Attach a DOS hook type notification on the parent directory,
the struct NotifyHookMsg will provide the action and name of the object changed / deleted / added.

struct NotifyHookMsg
{
int32 nhm_Size; /* Size of data structure */
int32 nhm_Action; /* What happened (see below) */
STRPTR nhm_Name; /* The name of the object */
};

See also include file; dos/notify.h

If you need more specific object info, tell me what you need.

Re: Dos notifications - Anyway to get more event information

Posted: Tue Jul 09, 2013 1:22 am
by theamigaone
Ah cool, I must of been assuming that the notifyhook will just return the name of the of the NotifyRequest object, my bad

Re: Dos notifications - Anyway to get more event information

Posted: Tue Jul 09, 2013 3:19 pm
by ssolie
You can find some more information about DOS notification on the wiki as well.

I realize the article needs some more updating so any suggestions for improvement are welcome.

Re: Dos notifications - Anyway to get more event information

Posted: Wed Jul 10, 2013 12:42 am
by theamigaone
Yep the Wiki has been great, although yes regarding file notifications using hooks it is loose :) I've got my head around now how hooks are implemented and technically got a hook working by setting one up and then calling IUtility->CallHook to run it.

Problem is now, how does the wait(signal) look recognise the hook needs to be called, as the NotifyRequest only accepts a messageport when using NFR_SEND_MESSAGE. Ive modified the Send Message.c from the wiki to use hooks, but its seems the hooks are not being called.


Heres what Ive changed compared to the wiki example.

/* Testing function for the hook */
int func(struct Hook *hook, APTR researved,struct NotifyHookMsg *msg){
IDOS->Printf("HookCalled\n");
}

/* Setup hook */
notifyHook = IExec->AllocSysObjectTags( ASOT_HOOK,
ASOHOOK_Entry, func,
ASOHOOK_Subentry, NULL,
ASOHOOK_Data, NULL,
TAG_END );

/* changed to NRF flag to use hook instead of Message */
notifyrequest->nr_Flags = NRF_CALL_HOOK;

/* Changed the union to nr_Callhook instead of nr_Msg */
notifyrequest->nr_stuff.nr_CallHook.nr_Hook = notifyHook;

The wait(signal) loop is still listening for Wait(notifysignal | SIGBREAKF_CTRL_C) of which I expect to only receive the Ctrl_c which of course closes the program.

Thanks again

PS there is a few typos in the Wiki Code examples, which caused errors. Where would you want me to list any I find.

Re: Dos notifications - Anyway to get more event information

Posted: Wed Jul 10, 2013 8:05 am
by salass00
theamigaone wrote: /* Testing function for the hook */
int func(struct Hook *hook, APTR researved,struct NotifyHookMsg *msg){
IDOS->Printf("HookCalled\n");
}
Using IDOS->Printf() here is a very bad idea as the hook will likely be either called on the context of the filesystem process (which might not be allowed to use standard dos i/o calls if it's a standard packet based fs and the pr_MsgPort is used as the filesystem msgport) or some other program. In either case you won't know where your output will be going or that it won't cause a crash.

If you want to do debug output from your hook function you should rather use IExec->DebugPrintF() and use either sashimi or dumpdebugbuffer to catch the serial output.

Re: Dos notifications - Anyway to get more event information

Posted: Wed Jul 10, 2013 8:11 am
by salass00
theamigaone wrote: The wait(signal) loop is still listening for Wait(notifysignal | SIGBREAKF_CTRL_C) of which I expect to only receive the Ctrl_c which of course closes the program.
Obviously because you changed the program so that it doesn't use a msgport but a hook so there is no signal to wait for because the signal was for the msgport (when it receives a notify msg). If you want a signal then you will have to do it yourself from within your hook function.

Re: Dos notifications - Anyway to get more event information

Posted: Wed Jul 10, 2013 2:48 pm
by theamigaone
Right, did'nt quite realize that the Filesystem will actually call the hook, true the printfs could go awol. The serial debug is something which sounds very useful.

So I'm guessing now the best way forward for my solution would be to get the hook to send an execmsg to my listening notifyport(from my App) with some extended information obtained from the NotifyMessage name and action with the Hook func.

Re: Dos notifications - Anyway to get more event information

Posted: Wed Jul 10, 2013 3:37 pm
by ssolie
theamigaone wrote:PS there is a few typos in the Wiki Code examples, which caused errors. Where would you want me to list any I find.
You can send any corrections to me (email or PM). You may also want to consider joining the wiki editing team and making the corrections directly yourself.

I apologize for the state of the notification examples on the wiki. They have not yet been converted to use the modern AmigaOS 4.x API. I just took a quick stab at correcting some of it (sans a compiler).