id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	appname	phpversion	exts	sapi	probability	blockedby	blocking
193	Hash collision when files are dynamically deleted and created again	c960657	moo	"If a file is deleted and another file is created with another name immediately after, it looks as if the new file sometimes inherits the old file's inode number.

This behaviour is illustrated by the following commands. On my system the two ls calls output identical values:
{{{
rm -f file1 file2 ; touch file1 ; ls -i file1 ; rm file1 ; touch file2 ; ls -i file2
}}}

This causes a problem with XCache that (AFAICT) uses the inode number as a cache key. Thus, if a script dynamically deletes a file, oldfile.php, and subsequently creates another, newfile.php, ""include 'newfile.php';"" may lead to the inclusion of the code in oldfile.php. This happens e.g. with Smarty that compiles templates to PHP file.

Here is a test case in PHP:
{{{
<?php
sleep(2);
for ($i = 0; $i < 2; $i++) {
    $file = '/tmp/file' . $i . '.php';
    file_put_contents($file, '<?php var_dump(""This is ' . $file . '""); ?' . '>');
    include $file;
    $stat = stat($file);
    var_dump('Now including ' . $file . ', inode=' . $stat['ino']);
    unlink($file);
}
?>
}}}

Expected result:
{{{
string(22) ""This is /tmp/file0.php""
string(43) ""Now including /tmp/file0.php, inode=2277518""
string(22) ""This is /tmp/file1.php""
string(43) ""Now including /tmp/file1.php, inode=2277518""
}}}

Actual result:
{{{
string(22) ""This is /tmp/file0.php""
string(43) ""Now including /tmp/file0.php, inode=2277518""
string(22) ""This is /tmp/file0.php""
string(43) ""Now including /tmp/file1.php, inode=2277518""
}}}

If you remove the initial ""sleep(2)"" it works as expected. Without the sleep() it looks as the files are never cached (they don't show up on the XCache Administration page).
"	defect	closed	minor	1.3.0	cacher	1.2.1	fixed		xcache.lighttpd.net@…				apache2handler	Always