Opened 7 years ago

Closed 2 years ago

#117 closed defect (fixed)

__FILE__ doesn't work correctly in hard-linked files

Reported by: sherwind@… Owned by: moo
Priority: major Milestone: 2.0.1
Component: cacher Version: 1.2.1
Keywords: dirname hardlink hard link good_report Cc: judas.iscariote@…
Application: PHP Version: 4.3.9
Other Exts: SAPI: Irrelevant
Probability: Always Blocked By:
Blocking:

Description (last modified by moo)

A file that require()s a config file located in dirname(__FILE__)
and outputs a constant is hard-linked in multiple sites hosted on the
same server. The constant for the site from which the file was first
requested gets cached and is returned in subsequent requests, even for
other sites.

It works fine if the file is *unhardlinked*. It also works if
dirname(__FILE__) is removed or just replaced with './'.

System:

  • Centos 4.5
  • Apache 2.0.52
  • PHP v4.3.9
  • XCache v1.2.1

Reproduce code:

foo.example.com and bar.example.com have the same copies of test.php
and config.php

# sha1sum /www/*/{test,config}.php
a0af22d58a7a7a5fd11547cd304cc08968c13d5c  /www/bar.example.com/test.php
a0af22d58a7a7a5fd11547cd304cc08968c13d5c  /www/foo.example.com/test.php
4494ec973dfed496e4b28f1ae6e4e2224d10a66c  /www/bar.example.com/config.php
4494ec973dfed496e4b28f1ae6e4e2224d10a66c  /www/foo.example.com/config.php

but test.php is hard-linked

# ls -il /www/*/{test,config}.php | awk '{print $1, $10}' | sort -rn
5640819 /www/foo.example.com/test.php
5640819 /www/bar.example.com/test.php
4792040 /www/bar.example.com/config.php
4792039 /www/foo.example.com/config.php

# cat /www/foo.example.com/test.php
<?php
require(dirname(__FILE__) . '/config.php');
echo ABSPATH;
?>

# cat /www/foo.example.com/config.php
<?php
define('ABSPATH', dirname(__FILE__).'/');
?>

Expected result:

"echo ABSPATH;" should return the ABSPATH for foo if foo.example.com is
requested and the ABSPATH for bar if bar.example.com is requested.

Actual result:

# service httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [  OK  ]

# curl -H 'Host: foo.example.com' http://127.0.0.1/test.php
/www/foo.example.com/

# curl -H 'Host: bar.example.com' http://127.0.0.1/test.php
/www/foo.example.com/

# service httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [  OK  ]

# curl -H 'Host: bar.example.com' http://127.0.0.1/test.php
/www/bar.example.com/

# curl -H 'Host: foo.example.com' http://127.0.0.1/test.php
/www/bar.example.com/

Change History (14)

comment:1 Changed 7 years ago by sherwin

  • Milestone set to 1.2.2

This also affects APC and I have already reported it in http://pecl.php.net/bugs/bug.php?id=11872

comment:2 Changed 7 years ago by sherwin

  • Component changed from admin to cacher

comment:3 Changed 7 years ago by sherwin

"PHP v4.3.0" in Description, under System:, should be "PHP v4.3.9". It comes stock with Centos 4.5.

comment:4 Changed 7 years ago by moo

  • Description modified (diff)

thanks for your. nice catch and reproduce detail. it's the wrong FILE in test.php at line: require(dirname(FILE) . '/config.php');

i'll rethink about this issue

FYI: 2.0 support md5sum checking which do the same job like hardlink, and should result in same issue like this bug.

comment:5 Changed 7 years ago by moo

i meant __FILE__

comment:6 Changed 7 years ago by moo

  • Summary changed from dirname(__FILE__) doesn't work correctly in hard-linked files to __FILE__ doesn't work correctly in hard-linked files

comment:7 Changed 7 years ago by judas_iscariote

  • Cc judas.iscariote@… added
  • Keywords good_report added

hrmmm.. interesting problem....I just wonder how to fix it ;-)

comment:8 Changed 7 years ago by moo

to workarround, change #define HAVE_INODE in xcache.h to #undef HAVE_INODE, see if it helps

comment:9 Changed 6 years ago by Smite

I've added a bug report to PHP suggesting a feature they could implement to make things easier on the cache, but so far it's meeting pretty strong resistance, for reasons I don't understand.

http://bugs.php.net/bug.php?id=45421

comment:10 Changed 5 years ago by moo

  • Status changed from new to accepted

will be fixed in 2.0. most work is already done, see ContentSharedHashCaching?

comment:11 Changed 5 years ago by moo

  • Milestone changed from 1.3.1 to 2.0.0

the hard link is done in XCache internally (transparently), i wonder if it still necessary to do it in filesystem level which is opaque to the end users.

comment:12 Changed 5 years ago by moo

well... see AutoHardLinking instead

comment:13 Changed 2 years ago by moo

  • Milestone changed from 2.2.0 to 2.0.1
  • Status changed from accepted to new

comment:14 Changed 2 years ago by moo

  • Resolution set to fixed
  • Status changed from new to closed

this is fixed perfectly in 2.0.1. see bug #284

Note: See TracTickets for help on using tickets.