#41493 [Ver]: Harmonise behaviour of function disk_free_space() in 3 OS's

From: Date: Tue, 29 May 2007 13:13:53 +0000
Subject: #41493 [Ver]: Harmonise behaviour of function disk_free_space() in 3 OS's
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-113152@lists.php.net to get a copy of this message
ID: 41493 User updated by: tayloj1 at uk dot ibm dot com -Summary: Linux behaviour of function disk_free_space() Reported By: tayloj1 at uk dot ibm dot com Status: Verified -Bug Type: Documentation problem +Bug Type: Filesystem function related Operating System: linux -PHP Version: Irrelevant +PHP Version: 5.2.2 New Comment: Editing submission to change bug category from 'Documentation' to 'Filesystem function related', and to update Summary line. As per preceding discussion, please change implementation of function disk_free_space()so that the behaviour is the same for Linux, OS2 and Windows. Ideal result would be for all 3 OS's to accept a directory or filename as input, ref. rquadling comment, 29 May 10:35am. If this is implemented, then please update doc also: "Given a string containing a directory <insert: "or filename">, this function will return the number of bytes available in the corresponding filesystem or disk partition. " Previous Comments: ------------------------------------------------------------------------ [2007-05-29 11:55:03] rquadling@php.net I would raise a bug as 2 of the 3 os's which have different implementations of this function support the supplying of a filename. Only windows has (is?) the problem. And it makes sense to ask how much space in on the drive holding a file. ------------------------------------------------------------------------ [2007-05-29 11:09:10] tayloj1 at uk dot ibm dot com OK, then please - either - (1) fix the function to make Linux implementation behave the same way as Windows (eg. by adding a check to stop Linux users supplying a filename). - or - (2) add the following text (instead of my previous suggestion): "Given a file name instead of a directory, the behaviour of the function is unspecified and may differ between operating systems and PHP versions. " Please advise your preference, I'm happy to raise a bug against the implementation if required. ------------------------------------------------------------------------ [2007-05-29 11:02:51] tayloj1 at uk dot ibm dot com OK, then please - either - (1) fix the function to make Linux implementation behave the same way as Windows (eg. by adding a check to stop Linux users supplying a filename). - or - (2) add the following text (instead of my previous suggestion): "Given a file name instead of a directory, the behaviour of the function is unspecified and may differ between operating systems and PHP versions. " Please advise your prefererence, I'm happy to raise a bug against the implementation if required. ------------------------------------------------------------------------ [2007-05-29 10:35:31] rquadling@php.net Is there any reason why both OS's cannot perform in the same manner? In checking filestat.c (/* $Id: filestat.c,v 1.160 2007/02/26 20:35:41 tony2001 Exp $ */), for OS2, only the first character of the path is used (char drive = path[0] & 95;). Linux accepts a full path. OS2 accepts a full path, but only uses the drive part. Windows doesn't accept a full path, but could by checking to see if the supplied path is a file (php_stat() would do that) and if so, chop off the filename and try that. Alternatively, only do the chopping part if the original test fails. ------------------------------------------------------------------------ [2007-05-26 13:15:54] ezyang@php.net Verified behavior on Linux machine. I'm not sure if we should document this, however, because it's not portable at all. ------------------------------------------------------------------------ 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 http://bugs.php.net/41493 -- Edit this bug report at http://bugs.php.net/?id=41493&edit=1

« previous php.bugs (#113152) next »