php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #62072 The "copy" function can't copy files from /proc
Submitted: 2012-05-19 16:39 UTC Modified: 2012-05-19 17:45 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: mr_platelet+jin6vr at fastmail dot fm Assigned:
Status: Open Package: Filesystem function related
PHP Version: 5.3.13 OS: Debian Linux 6.0.4
Private report: No CVE-ID: None
 [2012-05-19 16:39 UTC] mr_platelet+jin6vr at fastmail dot fm
Description:
------------
The "copy" function can't copy files from /proc.

This is the "configure" line I used to compile PHP.  (Don't be misled
by the value for "prefix"; I'm using PHP 5.3.13, not PHP 5.3.12.)

./configure  --prefix=/usr/local/php/5.3.12 --disable-cgi --with-
pgsql=shared,/usr --with-xmlrpc=shared --with-tidy=shared,/usr --with-
mssql=shared,/usr --with-sqlite=shared,/usr --with-snmp=shared,/usr --with-
xsl=shared,/usr --with-recode=shared,/usr --with-unixODBC=shared,/usr --with-
pspell=shared,/usr --with-mysqli=shared,/usr/bin/mysql_config --with-
mysql=shared,/usr --with-mcrypt=shared,/usr --with-ldap-sasl=/usr --with-
ldap=shared,/usr --with-t1lib=shared,/usr --with-ttf=shared,/usr --enable-
intl=shared --with-pdo-firebird=shared,/usr --with-interbase=shared,/usr --with-
imap-ssl --with-freetype-dir=shared,/usr --with-png-dir=shared,/usr --with-xpm-
dir=shared,/usr/X11R6 --with-jpeg-dir=shared,/usr --with-gmp=shared,/usr --
enable-gd-native-ttf --with-gd=shared,/usr --with-zlib-dir=/usr --with-
enchant=shared,/usr --with-curl=shared,/usr --without-mm --with-mhash=yes --
enable-zip --enable-soap --with-openssl=/usr --with-kerberos=/usr --with-zlib --
with-libxml-dir=/usr --enable-wddx --enable-sockets --enable-shmop --with-pcre-
regex=/usr --with-onig=/usr --enable-mbstring --with-gettext --enable-ftp --
enable-exif --with-iconv --without-gdbm --with-db4 --enable-ctype --with-bz2 --
enable-bcmath --enable-sysvmsg --enable-sysvshm --enable-sysvsem --enable-
calendar --with-pic --disable-static --disable-rpath --with-regex=php --disable-
debug --enable-pcntl --with-readline

Test script:
---------------
<?php
copy("/proc/self/stat", "php://stdout");

Expected result:
----------------
I expect the script to print the contents of /proc/self/stat.

Actual result:
--------------
The script prints nothing.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-05-19 17:45 UTC] rasmus@php.net
-Type: Bug +Type: Feature/Change Request
 [2012-05-19 17:45 UTC] rasmus@php.net
/proc files are special and aren't actually files at all. One of the weird 
characteristics of "files" in /proc is that they have a size of 0 bytes.

eg.

% stat /proc/self/stat
  File: `/proc/self/stat'
  Size: 0         	Blocks: 0          IO Block: 1024   regular empty file
Device: 3h/3d	Inode: 2290608     Links: 1
Access: (0444/-r--r--r--)  Uid: ( 1000/  rasmus)   Gid: ( 1000/  rasmus)
Access: 2012-05-19 19:37:34.891956230 +0200
Modify: 2012-05-19 19:37:34.891956230 +0200
Change: 2012-05-19 19:37:34.891956230 +0200
 Birth: -

And a "man 2 stat" has this note:

   For  most  files  under the /proc directory, stat() does not return the
   file size in the st_size field; instead the field is returned with  the
   value 0.

PHP's various file-related functions rely on stat telling the truth as the 
stream-to-stream copy first checks to see if it is possible to stat the src 
stream. If it is a stat'able stream, we get the size and then if it is an 
mmap'able stream we will mmap based on that size. If stat() tells us we have a 
0-length file we short-circuit everything and return at that point because in 
every case other than for /proc files this is the correct behaviour. 

In order to fix this we would have to add a special-case for stat'able streams 
that lie about the size which I would consider more of a feature request than a 
bug.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Nov 25 08:01:32 2024 UTC