Req #50197 [Com]: long filenames
Edit report at https://bugs.php.net/bug.php?id=50197&edit=1 ID: 50197 Comment by: php at stock-consulting dot com Reported by:jandidrik dot fagerlid at hotmail dot com Summary:long filenames Status: Assigned Type: Feature/Change Request Package:Filesystem function related Operating System: winxp 32bit PHP Version:5.3.0 Assigned To:pajoye Block user comment: N Private report: N New Comment: Apparently, the path length limit exists for other PHP functions as well. For example, glob() fails to return files when the length of the file name including it's path exceeds 240...260 characters (unsure of the precise limit). There is no warning, it just silently gives the wrong result. In my case, it's PHP 5.3.6 running as a CLI script on Ubuntu 11.10, the files in question reside on a network share (host: Win7). Shell commands like "ls" display all directory entries correctly, so the OSes appear to work okay. I tried to change the shell's CWD to the network directory and to run the script there, but the issue remained. Apparently, PHP doesn't consider the current working directory, but the "real path", which remains too long. Previous Comments: [2009-11-16 22:40:22] jandidrik dot fagerlid at hotmail dot com Description: Firstly, thank you for your hard work, it is appreciated. It seems filemtime will not accept file paths longer than 256 chars. I have some long dir names consisting of totally 165 chars, and a file inside it consisting of 94 chars. The script doesnt exit, but i get a warning and a NULL result. Warning: filemtime() [function.filemtime]: stat failed for [file.php] in [dir] on line # Reproduce code: --- #$path = string 165 chars #$file = string of 94 chars filemtime($path."/".$file); Expected result: timestamp for file Actual result: -- NULL -- Edit this bug report at https://bugs.php.net/bug.php?id=50197&edit=1
#42492 [NEW]: FTP functions apparently use wrong IP address for PORT in PASV mode
From: php at stock-consulting dot com
Operating system: Windows 2000
PHP version: 5.2.4
PHP Bug Type: FTP related
Bug description: FTP functions apparently use wrong IP address for PORT in
PASV mode
Description:
Situation: the local machine, which executes the PHP script via the
command line, sits behind a NAT firefall and needs to retrieve directory
listings and files from an FTP server sitting somewhere on the Internet.
Passive FTP is required to traverse the firewall. The local machine has the
IP address 10.0.0.1 (subnet configured as Class C). The external (WAN) IP
of the router/firewall is 80.x.x.x (address partially concealed to protect
the, erm, innocent).
Now the problem: the script correctly connects to the FTP server and
begins to retrieve directory listings (recursively) and files. At some
RANDOM point, the following warning appears:
Warning: ftp_chdir(): PORT command only accepts client IP address
(80.x.x.x
!=10.0.0.1). in my_script.php on line 40
This warning then appears both at all further attempts to retrieve
directory listings and files. The transfers are not successful.
Note that directory and file retrieval works perfectly UNTIL the warning
occurs for the first time, at some random time. When the script is
restarted, it will again work for some listings and files, until, at some
different point, the warning will appear again.
Reproduce code:
---
// Short version, stripped from anything which appeared not so useful for
this bug report
function remote_scan($path) {
global $ftp;
ftp_chdir($ftp, $path);
$raw_entries = ftp_rawlist($ftp, $path);
foreach ($raw_entries AS $line) {
$entry = preg_split('@\s+@', $line, 9);
if ($entry[4] == 0) {
remote_scan($path . $entry[8] . '/');
} else {
ftp_get($ftp, 'x:/local_path' . $path . $entry[8],
$path . $entry[8],
FTP_BINARY);
}
}
}
$ftp = ftp_connect('ftp.url', 47624); // server uses non-standard port
$login_result = ftp_login($ftp, 'user', 'password');
ftp_pasv($ftp, true);
remote_scan('/');
ftp_close($ftp);
--
Edit bug report at http://bugs.php.net/?id=42492&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42492&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42492&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42492&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42492&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42492&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42492&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42492&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42492&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42492&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42492&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42492&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42492&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42492&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42492&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42492&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42492&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42492&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42492&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42492&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42492&r=mysqlcfg
#42492 [Fbk->Opn]: FTP functions apparently use wrong IP address for PORT in PASV mode
ID: 42492
User updated by: php at stock-consulting dot com
Reported By: php at stock-consulting dot com
-Status: Feedback
+Status: Open
Bug Type: FTP related
Operating System: Windows 2000
PHP Version: 5.2.4
New Comment:
Yes, defnitely, I just downloaded it...yesterday? F***! ***! *** ** *
! Just checked it (php.exe -v). It's PHP 5.2.3. Okay. Sorry.
Upgraded to 5.2.4 now, checked (php.exe -v), yup, now I'm at 5.2.4!
Yup. I can confirm the bug in 5.2.4 as well. The warning is now:
Warning: ftp_get(): PORT command only accepts client IP address
(80.x.x.x!=
10.0.0.1). in my_script.php on line 71
Best regards, Klaus
Previous Comments:
[2007-08-31 11:27:49] [EMAIL PROTECTED]
And you're really using PHP 5.2.4?
[2007-08-31 11:15:27] php at stock-consulting dot com
Description:
Situation: the local machine, which executes the PHP script via the
command line, sits behind a NAT firefall and needs to retrieve directory
listings and files from an FTP server sitting somewhere on the Internet.
Passive FTP is required to traverse the firewall. The local machine has
the IP address 10.0.0.1 (subnet configured as Class C). The external
(WAN) IP of the router/firewall is 80.x.x.x (address partially concealed
to protect the, erm, innocent).
Now the problem: the script correctly connects to the FTP server and
begins to retrieve directory listings (recursively) and files. At some
RANDOM point, the following warning appears:
Warning: ftp_chdir(): PORT command only accepts client IP address
(80.x.x.x
!=10.0.0.1). in my_script.php on line 40
This warning then appears both at all further attempts to retrieve
directory listings and files. The transfers are not successful.
Note that directory and file retrieval works perfectly UNTIL the
warning occurs for the first time, at some random time. When the script
is restarted, it will again work for some listings and files, until, at
some different point, the warning will appear again.
Reproduce code:
---
// Short version, stripped from anything which appeared not so useful
for this bug report
function remote_scan($path) {
global $ftp;
ftp_chdir($ftp, $path);
$raw_entries = ftp_rawlist($ftp, $path);
foreach ($raw_entries AS $line) {
$entry = preg_split('@\s+@', $line, 9);
if ($entry[4] == 0) {
remote_scan($path . $entry[8] . '/');
} else {
ftp_get($ftp, 'x:/local_path' . $path . $entry[8],
$path .
$entry[8], FTP_BINARY);
}
}
}
$ftp = ftp_connect('ftp.url', 47624); // server uses non-standard port
$login_result = ftp_login($ftp, 'user', 'password');
ftp_pasv($ftp, true);
remote_scan('/');
ftp_close($ftp);
--
Edit this bug report at http://bugs.php.net/?id=42492&edit=1
#42492 [Opn]: FTP functions apparently use wrong IP address for PORT in PASV mode
ID: 42492
User updated by: php at stock-consulting dot com
Reported By: php at stock-consulting dot com
Status: Open
Bug Type: FTP related
Operating System: Windows 2000
PHP Version: 5.2.4
New Comment:
Further thoughts.
It appears to me that the message "PORT command only accepts..."
originates from the FTP server.
"PORT command"? What "PORT command"? I thought I was using PASV?
Exactly. I can confim that I use ftp_pasv($ftp, true) once, and that I
never turn passive mode off. So apparently the FTP functions somehow
seem to "forget" (at some random point) that they should use PASV mode.
Always suspicious as I am, this smells like something like buffer
overflow to me. Let's have a look at ftp.h:
typedef struct ftpbuf
{
php_socket_tfd; /* control connection */
php_sockaddr_storagelocaladdr; /* local address */
int resp; /* last response code */
charinbuf[FTP_BUFSIZE]; /* last response text */
char*extra; /* extra characters */
int extralen; /* number of extra chars */
charoutbuf[FTP_BUFSIZE];/* command output buffer */
char*pwd; /* cached pwd */
char*syst; /* cached system type */
ftptype_t type; /* current transfer type */
int pasv; /* 0=off; 1=pasv; 2=ready */
Hm, candiates might be inbuf and outbuf. However, a look at the code
pieces which might be primary candidates for a buffer overflow revealed
nothing suspicious to me.
However, I stumbled across a piece a code which looked kinda fishy to
me, beginning at line 1140 in ftp.c:
/* shift the extra to the front */
size = FTP_BUFSIZE;
rcvd = 0;
if (ftp->extra) {
memmove(ftp->inbuf, ftp->extra, ftp->extralen);
rcvd = ftp->extralen;
}
ftp->extra, together with ftp->textralen, appear to be essentiall
unbounded. Yuk! Now, I don't see any place where ftp->extra or
ftp->extralen gets set. I should have a look at the initilization code,
to find out if it gets at least initialized correctly.
As soon as time permits - currently I have no time and so I've to leave
this scene of investivation :-(
Best regards, Klaus
Previous Comments:
------------------------
[2007-08-31 13:07:04] php at stock-consulting dot com
Yes, defnitely, I just downloaded it...yesterday? F***! ***! *** ** *
! Just checked it (php.exe -v). It's PHP 5.2.3. Okay. Sorry.
Upgraded to 5.2.4 now, checked (php.exe -v), yup, now I'm at 5.2.4!
Yup. I can confirm the bug in 5.2.4 as well. The warning is now:
Warning: ftp_get(): PORT command only accepts client IP address
(80.x.x.x!=
10.0.0.1). in my_script.php on line 71
Best regards, Klaus
[2007-08-31 11:27:49] [EMAIL PROTECTED]
And you're really using PHP 5.2.4?
--------------------
[2007-08-31 11:15:27] php at stock-consulting dot com
Description:
Situation: the local machine, which executes the PHP script via the
command line, sits behind a NAT firefall and needs to retrieve directory
listings and files from an FTP server sitting somewhere on the Internet.
Passive FTP is required to traverse the firewall. The local machine has
the IP address 10.0.0.1 (subnet configured as Class C). The external
(WAN) IP of the router/firewall is 80.x.x.x (address partially concealed
to protect the, erm, innocent).
Now the problem: the script correctly connects to the FTP server and
begins to retrieve directory listings (recursively) and files. At some
RANDOM point, the following warning appears:
Warning: ftp_chdir(): PORT command only accepts client IP address
(80.x.x.x
!=10.0.0.1). in my_script.php on line 40
This warning then appears both at all further attempts to retrieve
directory listings and files. The transfers are not successful.
Note that directory and file retrieval works perfectly UNTIL the
warning occurs for the first time, at some random time. When the script
is restarted, it will again work for some listings and files, until, at
some different point, the warning will appear again.
Reproduce code:
---
// Short version, stripped from anything which appeared not so useful
for this bug report
function remote_scan($path) {
global $ftp;
ftp_chdir($ftp, $path);
$raw_entries = ftp_rawlist($ftp, $path);
foreach ($raw_entries AS $line) {
$entry = preg_split('@\s+@', $line, 9);
if ($entry[4] == 0) {
remote_scan($path . $entry[8
#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: php at stock-consulting dot com Reported By: graham at directhostinguk dot com Status: Assigned Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.2 Assigned To: georg New Comment: I receive the message as well, when running PHP 5.2.2 from the command line, so definitely no IIS-related issue. The php_mysql.dll is loaded as an extension, but no functions from the library are called by the application, so most likely no MySQL issue. The message appeared after the PHP version update; no MySQL update was performed. A clear indication, IMHO, the something went wrong on the PHP side. Previous Comments: [2007-05-18 10:30:33] e_remove_paine at lastfrontiers dot com With PHP5.2.2, and MySQL5.0.41 under Windows XP (IIS5.1) I can reproduce this by simply creating a normal html page (no php tags) with a .php extension. Error in my_thread_global_end(): 1 threads didn't exit [2007-05-14 01:36:28] sptong at hotmail dot com I have upgraded to PHP 5.2.2. I cfm that using libmysql.dll from 5.2.1, instead of 5.2.2 solved the pbm. Or rather, the error does not show up again. [2007-05-13 15:35:22] paul at orac dot clara dot co dot uk This IS a bug - it is in the libmysql.dll library. If you replace the copy from 5.2.2 with the one from 5.2.1, then the problem goes away. That guy [EMAIL PROTECTED] says that the error message is not in PHP. He might be right about that, but that doesn't mean the PHP isn't the cause of it, which it quite clearly is. Closing bugs without any discussion doesn't help the situation either. [2007-05-10 12:12:10] graham at directhostinguk dot com Description: This closed PHP bug: http://bugs.php.net/bug.php?id=41316 MySQL Bug: http://bugs.mysql.com/bug.php?id=25621 Error in my_thread_global_end(): 1 threads didn't exit I have the same issue even when the script doesn't call any MySQL, but this error only happens when using fast-cgi If I run php 5.2.2 ISAPI the problem goes away. I think this is a php bug It seems to me that the problem lies in the PHP dll "php_mysql.dll" as it is opening the threads but not telling MySql to close them. -- Edit this bug report at http://bugs.php.net/?id=41350&edit=1
