#27152 [NEW]: fam_next_event() doesn't return the corresponding request

From: josh at mediascape dot com Operating system: Linux PHP version: 5.0.0b3 (beta3) PHP Bug Type: Feature/Change Request Bug description: fam_next_event() doesn't return the corresponding request Description: ------------ The array returned by fam_next_event() contains "filename", "code" and possibly "hostname", but it doesn't return any indicator of the FAMRequest that the event belongs to. The underlying library returns this as the "fr" member of the FAMEvent struct -- "FAMRequest *fr;". When monitoring multiple directories, this additional context is needed, since the filenames returned have no associated path information. Reproduce code: --------------- -- Sample PHP FAM client -- #! /usr/local/bin/php5 <?php $conn = fam_open('zot-watch'); $r1 = fam_monitor_directory($conn, '/tmp'); $r2 = fam_monitor_directory($conn, '/var/tmp'); while ($event = fam_next_event($conn)) { print "File: $event[filename]\n"; print "Code: $event[code]\n\n"; } ?> -- Sample filesystem activity to trigger it -- $ touch /tmp/blib $ touch /var/tmp/blib Expected result: ---------------- I would expect fam_next_event() to return either the resource handle for the underlying FAMRequest structure (also returned by fam_monitor_directory() -- $r1 and $r2 in the code above), or the path argument to the fam_monitor_*() function so that the client code can reconstruct something meaningful from the returned event. As an example, here's the modified lines inside the while() loop above, but expecting that fam_next_event() also returns the resource handle corresponding to fe->fr in the underlying struct: print "File: $event[filename]\n"; print "Code: $event[code]\n"; print "Request: $event[request]\n"; $req = intval($event['request']); print "Path: ".($req == intval($r1) ? '/tmp' : '/var/tmp') . "\n\n"; I hesitate to produce the patch to php-5.0b3 I used to test this, only because I've never looked under PHP's hood before, and someone that knows what they're doing would likely produce the same changes at least as quickly as finding the SIGSEGV that I created in the process. Actual result: -------------- [Skipping the list of files that already exist for brevity] File: blib Code: 5 File: blib Code: 5 -- Compared with the result from my test build -- File: blib Code: 5 Request: Resource id #5 Path: /tmp File: blib Code: 5 Request: Resource id #6 Path: /var/tmp -- Edit bug report at http://bugs.php.net/?id=27152&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27152&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27152&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27152&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27152&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27152&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27152&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27152&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=27152&r=support Expected behavior: http://bugs.php.net/fix.php?id=27152&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=27152&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=27152&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27152&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27152&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27152&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27152&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=27152&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27152&r=float