Bug #16263 [Com]: session.start() create new empty session file and not resume existing session

Edit report at https://bugs.php.net/bug.php?id=16263&edit=1 ID: 16263 Comment by: phpbugs at aron dot ws Reported by: kur at natur dot cuni dot cz Summary: session.start() create new empty session file and not resume existing session Status: No Feedback Type: Bug Package: Session related Operating System: ANY PHP Version: 4.3.0-dev Block user comment: N Private report: N New Comment: If you run out of space you get the same effect :D Previous Comments: ------------------------------------------------------------------------ [2010-09-23 22:21:55] sartorato at gmail dot com Hi there, I was having the same problem with PHP creating session files with 0Kb. I solved putting the <? session_start();?> on the first line of the php file. After this it works like a charm. Hope it helps somebody. Ricardo Sartorato ------------------------------------------------------------------------ [2009-12-16 20:07:04] sven dot holcombe at gmail dot com Running on default XAMPP installation, with the session.save_path = "C:\xampplite\tmp" When I set the apache document root to be: <Directory "C:/xampplite/htdocs"> And then run a file with contents: <?PHP session_start(); ?> There is a session file created. Ie, normal operation. When I set the apache document root to be: <Directory "S:/htdocs"> And then run THE SAME file with contents: <?PHP session_start(); ?> A 0KB session file is created. Ie, it is empty, and I cannot access session variables. Please help. ------------------------------------------------------------------------ [2009-12-02 18:57:14] john at 5070 dot info The same issue. # php-cgi -v PHP 5.2.6-1+lenny3 with Suhosin-Patch 0.9.6.2 (cgi-fcgi) (built: Apr 26 2009 22:11:16) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies System call trace (in fact, this is processed by mod_php of the same version): open(".../sess_a6549.............", O_RDWR|O_CREAT|O_LARGEFILE, 0600) = 1035 fstat64(1035, {st_mode=S_IFREG|0600, st_size=96, ...}) = 0 flock(1035, LOCK_EX) = 0 fcntl64(1035, F_SETFD, FD_CLOEXEC) = 0 fstat64(1035, {st_mode=S_IFREG|0600, st_size=96, ...}) = 0 _llseek(1035, 0, [0], SEEK_SET) = 0 read(1035, "Acess|s:1:\"1\";id|s:3:\"108\";login|"..., 96) = 96 ... ftruncate64(1035, 0) = 0 _llseek(1035, 0, [0], SEEK_SET) = 0 write(1035, ""..., 0) = 0 close(1035) = 0 Session files are shared via NFSv4, if it is important. ------------------------------------------------------------------------ [2009-08-26 18:00:41] chris dot kerrison at farrendale dot co dot uk Hello, I have theis session problem, tried everything on this page not still wont work. Is anyone else having the problem still?? I have 2 servers, one it works fine on and the other it fails, they use the same settings, and have tried differant versions, yet it still fails on the 2nd server. Ho many people here are running it on a server with a " _ " in the computer name? that to me seems the only thing differant between the computers with my setup. ------------------------------------------------------------------------ [2008-09-12 23:42:19] robin dot chauhan at gmail dot com As noted on http://www.kirupa.com/forum/showthread.php?t=288773 "After 10 hours of searching over 2 days, I figured it out. The UTF-8 encoding was placing invisible characters before my <?php tag, thus throwing an error (which I couldn't see because my server host's debug doesn't show). Switching to ANSI removed those characters and thus the session_start() functioned properly this time, giving me a consistent session ID. Thanks to those who helped." ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=16263 -- Edit this bug report at https://bugs.php.net/bug.php?id=16263&edit=1