Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-12890

(Caching-)File problems when using sysmlinks in an installation

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Medium Medium
    • Resolution: Fixed
    • Affects Version/s: 4.0.0
    • Fix Version/s: Customer request
    • Component/s: Caching, Misc
    • Labels:
      None
    • Environment:

      Operating System: gentoo linux 2007.1
      PHP Version: 5.2.5
      Database and version: Oracle 10g XE
      Browser (and version):

      Description

      In some cases it could happen that (cache-)files are stored in a directory where one does not expect them to be stored. This happens if symbolic links are used in an installation.
      Example:

      There are several releases of an installation in an svn repository. Let's say

      /svn/project/releases/0.1.2
      /svn/project/releases/0.1.3

      Within another directory, e.g.

      /var/www

      there is a symbolic link to one of this versions, e.g.

      /var/www/used_version --> /svn/project/releases/0.1.3

      Furthermore there is a webserver document root in

      /var/www/htdocs

      in which the ez publish installation can be found. The eZ Publish files are not placed directly, but also as symbolic links, e.g.

      /var/www/htdocs/kernel --> /var/www/used_version/kernel
      /var/www/htdocs/lib --> /var/www/used_version/lib

      This setup allows easy switching between different versions of an installation.
      Nevertheless it could happen that files one would expect to be stored in

      /var/www/htdocs/var/cache/

      are stored in

      /svn/project/releases/0.1.3/var/cache

      instead. This happened especially with the file expiry.php with the effect that caches are always expired (because the file is read from /var/www/htdocs/var/cache/expiry.php but written to /svn/project/releases/0.1.3/var/cache/expiry.php).

      Steps to reproduce

      Setup an eZ Publish version by making use of symbolic links as described above. Enable e.g. SQLOutput and see that similar statements as the following occur, even on a page reload:

      SELECT id, role_id, module_name, function_name
      FROM ezpolicy
      WHERE role_id='1'
      ORDER BY id ASC

        Activity

        Hide
        Kristof Coomans added a comment -

        Most likely the underlying cause is mentioned here:
        http://www.php.net/register_shutdown_function
        "Note: Working directory of the script can change inside the shutdown function under some web servers, e.g. Apache. "

        Show
        Kristof Coomans added a comment - Most likely the underlying cause is mentioned here: http://www.php.net/register_shutdown_function "Note: Working directory of the script can change inside the shutdown function under some web servers, e.g. Apache. "
        Hide
        Kristof Coomans added a comment -

        in eZExecutionUncleanShutdownHandler() the following code is used:

            // Need to change the current directory, since this information is lost
            // when the callbackfunction is called. eZDocumentRoot is set in index.php.
            if ( isset( $GLOBALS['eZDocumentRoot'] ) )
            {
                $documentRoot = $GLOBALS['eZDocumentRoot'];
                chdir( $documentRoot );
            }
        

        That might solve the problem for the expiry shutdown handler as well.

        Show
        Kristof Coomans added a comment - in eZExecutionUncleanShutdownHandler() the following code is used: // Need to change the current directory, since this information is lost // when the callbackfunction is called. eZDocumentRoot is set in index.php. if ( isset( $GLOBALS['eZDocumentRoot'] ) ) { $documentRoot = $GLOBALS['eZDocumentRoot']; chdir( $documentRoot ); } That might solve the problem for the expiry shutdown handler as well.
        Hide
        Bertrand Dunogier added a comment -

        The issue comes from eZExecution::registerShutdownHandler(): since the $documentRoot parameter is never given, it gets computed from dirname( _FILE_ ). This bug should therefore only occur if lib/ezutils/classes/ezexecution.php is a symbolic link.

        Now the issue is to find a 100% reliable way to get the document root.

        Show
        Bertrand Dunogier added a comment - The issue comes from eZExecution::registerShutdownHandler(): since the $documentRoot parameter is never given, it gets computed from dirname( _ FILE _ ). This bug should therefore only occur if lib/ezutils/classes/ezexecution.php is a symbolic link. Now the issue is to find a 100% reliable way to get the document root.
        Hide
        Bertrand Dunogier added a comment -

        Fixed in:

        • trunk (ezpublish 4.3.0alpha1) rev. 24548
        • stable/4.2 (ezpublish 4.2.1) rev. 24549
        • stable/4.1 (ezpublish 4.1.5) rev. 24550
        Show
        Bertrand Dunogier added a comment - Fixed in: trunk (ezpublish 4.3.0alpha1) rev. 24548 stable/4.2 (ezpublish 4.2.1) rev. 24549 stable/4.1 (ezpublish 4.1.5) rev. 24550
        Hide
        ezrobot added a comment -

        This issue has been automatically closed due to the lack of activity over a long period of time. It is very likely that it is obsolete, but if you think it is still valid, do not hesitate to reopen it and mention why.

        Show
        ezrobot added a comment - This issue has been automatically closed due to the lack of activity over a long period of time. It is very likely that it is obsolete, but if you think it is still valid, do not hesitate to reopen it and mention why.

          People

          • Assignee:
            Bertrand Dunogier
            Reporter:
            Alexander Block
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: