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
