ID: 22476 User updated by: mccarthy36 at earthlink dot net Reported By: mccarthy36 at earthlink dot net Status: Assigned Bug Type: Documentation problem PHP Version: 4.3.0 Assigned To: philip New Comment:
But according to what you quoted: [ ; NOTE: If you are using the subdirectory option for storing session files ; (see session.save_path above), then garbage collection does *not* ; happen automatically. ] The note doesn't seem to make any qualification with respect to the level, N. Taken at face value that note says that, unconditionally, if you use the N;/path form, automatic garbage collection will not take place. At the moment I'm most concerned with clarifying what happens in the more basic situation when only a path is specified. In that case, automatic garbage collection occurs normally regardless of the path depth? Thanks Previous Comments: ------------------------------------------------------------------------ [2003-02-28 10:49:27] [EMAIL PROTECTED] Yes, it is misleading. The following are exerpts from php.ini-dist which explains it pretty well. Note that the '2' in the docs refers to the 'N' in php.ini. Also note that the parameter separator is a semi-colon (;) for all OS's and since ; is also for comments in php.ini, one must quote the string when N is used. [snip] ; Argument passed to save_handler. In the case of files, this is the path ; where data files are stored. Note: Windows users have to change this ; variable in order to use PHP's session functions. ; ; As of PHP 4.0.1, you can define the path as: ; ; session.save_path = "N;/path" ; ; where N is an integer. Instead of storing all the session files in ; /path, what this will do is use subdirectories N-levels deep, and ; store the session data in those directories. This is useful if you ; or your OS have problems with lots of files in one directory, and is ; a more efficient layout for servers that handle lots of sessions. ; ; NOTE 1: PHP will not create this directory structure automatically. ; You can use the script in the ext/session dir for that purpose. ; NOTE 2: See the section on garbage collection below if you choose to ; use subdirectories for session storage ; ; The file storage module creates files using mode 600 by default. ; You can change that by using ; ; session.save_path = "N;MODE;/path" ; ; where MODE is the octal representation of the mode. Note that this ; does not overwrite the process's umask. session.save_path = "/tmp" [snip] ; After this number of seconds, stored data will be seen as 'garbage' and ; cleaned up by the garbage collection process. session.gc_maxlifetime = 1440 ; NOTE: If you are using the subdirectory option for storing session files ; (see session.save_path above), then garbage collection does *not* ; happen automatically. You will need to do your own garbage ; collection through a shell script, cron entry, or some other method. ; For example, the following script would is the equivalent of ; setting session.gc_maxlifetime to 1440 (1440 seconds = 24 minutes): ; cd /path/to/sessions; find -cmin +24 | xargs rm ; PHP 4.2 and less have an undocumented feature/bug that allows you to ; to initialize a session variable in the global scope, albeit register_globals ; is disabled. PHP 4.3 and later will warn you, if this feature is used. ; You can disable the feature and the warning seperately. At this time, ; the warning is only displayed, if bug_compat_42 is enabled. session.bug_compat_42 = 1 session.bug_compat_warn = 1 ------------------------------------------------------------------------ [2003-02-28 09:27:30] mccarthy36 at earthlink dot net The Session documentation says: [ If session.save_path's path depth is more than 2, garbage collection will not be performed. ] Honestly I never understood why that would be the case, but it seems to not / no longer be the case. I'm on Linux / Apache 1.3.26 / PHP 4.3.0 with a session.save_path of home/username/data/sessions and garbage collection seems to be working normally. Sorry if I've misunderstood something, but this doesn't make sense to me. I hope that that section of the manual is just wrong / outdated, because that would be a big downer if true. If it is wrong, then obviously it would be helpful to have it corrected. Thanks ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=22476&edit=1 -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
