[PHP-DEV] CVS Account Request: stone
I'll help to translate the documentation to german. Therefore I need cvs access to [phpdoc-de]. I've been developing with php mainly on win32 for more than three years. Meanwhile I have gained a level of knowledge which should permit this kind of work. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)
[EMAIL PROTECTED] (Sascha Schumann) wrote: And we should not close our eyes from the possibility of a 4.3.1 release (e.g. due to a security issue). In that not-so-remote event, having a 4.3 branch with minimal changes is a simple requirement. With 4.3.0 you introduced lots of useful new features and new code (streams, bundled gd, PEAR release) and is - in my eyes - one of the biggest steps since 4.0.0. However - there have also been some new and annoying bugs. So why not release a bugfix 4.3.1 not because of a security hole but just to complete the great work already done on PHP 4.3 - before definitely jumping to PHP 5? Maybe I'm too swissy, but it makes me sad when I see PHP 4 beeing thrown away so fast... and PHP 5 will not be mature with the 5.0.0 release, there will be bugs, missing extensions and so on. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)
[EMAIL PROTECTED] (Derick Rethans) wrote: So why not release a bugfix 4.3.1 not because of a security hole but just to complete the great work already done on PHP 4.3 - before definitely jumping to PHP 5? Who said that we're not going to release a 4.3.1 or 4.3.n? I'm just not favoring new code going into the PHP_4_3 branch, but only bugfixes. I'd like to see new functionality going into HEAD, for PHP 5. Maybe I misunderstood when Edin said that there will be no new release for some time due to the move on PHP 5. I completely agree with you, then. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What headers/libs does Win32 Snaps build use?
Edin, I don't know much about this, but maybe the libraries could be distributed via a cvs directory (e.g win32libs). Like this there would be no need for additional (and probably soon outdated) HOWTO files (and it would make windows builds much easier for not-so-experienced users as I am). Christoph Edin Kadribasic wrote: Yes, Steph is right, the set of libraries used on the snaps machine is ~70MB (uncompressed) and I don't think it's practical to update win32build.zip to include them all. And this 70 MB does not include files needed for building ext/infromix, ext/interbase and sapi/pi3web. Edin - Original Message - From: Steph [EMAIL PROTECTED] To: Christoph Grottolo [EMAIL PROTECTED]; Michael Sisolak [EMAIL PROTECTED] Cc: PHP DEV [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 8:44 PM Subject: Re: [PHP-DEV] What headers/libs does Win32 Snaps build use? There are a lot of them - that's likely to be the biggest issue. Nearly 20 megs of libraries (and this from some months ago). This is really Edin's territory... - Original Message - From: Christoph Grottolo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 07, 2003 7:31 PM Subject: Re: [PHP-DEV] What headers/libs does Win32 Snaps build use? Basically what I'm talking about is updating win32build.zip so that it has all the current libraries that are really used to do a PHP build on Win32. Is there a practical or licensing reason why that couldn't be done? Would it be a lot more work than just packaging up a few directories on the snaps machine? Michael Sisolak +1 on this - if my vote counts Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What headers/libs does Win32 Snaps build use?
Basically what I'm talking about is updating win32build.zip so that it has all the current libraries that are really used to do a PHP build on Win32. Is there a practical or licensing reason why that couldn't be done? Would it be a lot more work than just packaging up a few directories on the snaps machine? Michael Sisolak +1 on this - if my vote counts Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Error Loading mcrypt.dll on Windows XP system
Hi Jean Baptiste Favre wrote: Jim Bierlein [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] My problem is that I cannot get Apache to properly load the mcrypt module, I keep getting the warning message: Unknown(): Unable to load dynamic library 'c:\php-4.3.0-Win32\extensions\php_mcrypt.dll' - The specific module could not be found. Does anyone know what I am missing or if there is a workaround to this issue. Any help would be appreciated. I am kind of new at this. Hi, You need limcrypt.dll which is not provided by default. Just download it here: http://ftp.proventum.net/pub/php/win32/misc/mcrypt/php-4.3-mcrypt.zip , copy the files: php_mcrypt.dll in your extensions directory and libmcrypt.dll in c:\windows\system32, restart your apache and enjoy ;-)) How about adding libmcrypt.dll to dlls folder of the windows distributions? It's hard to find a matching binary on the web. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: ground rules
Frank M. Kromann wrote: Hi, It was decided to move php_printer.dll, as well as other extensions (iisfunc and ixsfunc) from the php repository to PECL. This was not caused by instability. These extensions all work fine (AFAIK). They were moved from php to PECL to reduce the size of PHP and tehreby reduce the time needed to perform QA with each release. The reference to these files in php.ini will be removed and the documentation should move as well. I'll create PECL packages for these extensions so they can be obtained from the pear.net web site as other PECL extensions. - Frank Will there be a way to get the windows binaries from PECL? At the moment the PECL packages can't be found at all on pear.php.net (or am I too tired?). Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: ground rules
Hi Andrei Zmievski wrote: Everyone, I have just released 4.3.0RC4. Despite the quote in my signature, I am determined to keep this one the very last final RC of the interminable 4.3.0 development cycle. Towards that end, I will closely monitor the CVS commits and revert any that do not satisfactorily explain what critical or showstopper bug they are fixing. There are inconsistencies in php.ini on windows: The following extensions are listed in the [extensions] part of php.ini, but are not dlivered with the distribution: - ctype (now built in) - cybercash (?) - dotnet (build failure since months) - ingres (build failure since months) - tokenizer (now built in) The following extensions are part of the distribution but not listed in php.ini - gd2 - mime_magic - msql - xmlrpc - zip Maybe you can correct this before 4.3.0. At least the missing GD2 is bad. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RC4 + windows
Hi Marcus Börger wrote: Hi, i can no longer load mhash and domxml dll's under windows RC4. marcus I can load both of them with RC4 (tried with ISAPI). Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CGI and CLI
Hi Andrei Zmievski wrote: What was the consensus on CGI vs. CLI naming or merging issue? Or was there a consensus at all? I full plan to go ahead with 4.3.0 release before the end of the year, so those interested in doing anything about this issue better get their butts in gear. -Andrei I've seen that install.txt has already been adapted to the new cgi version (php.exe has been replaced by php-cgi.exe), however the manual only mentions the eventual name change in chapter 23 about CLI (http://www.php.net/manual/en/features.commandline.php) but not in http://www.php.net/manual/en/install.windows.php. Please consider this whatever the result of the discussions will be. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Derick Rethans wrote: On Wed, 18 Dec 2002, Sebastian Nohn wrote: But renaming php-cli to php means renaming php to anything else (php-cgi, cgi-php, phpcgi, phpfoo, whatever), right? No, we didn't do that for 4.2.[0-3] either: [root@saturnus php-4.2.1]# ./configure --enable-cli [root@saturnus php-4.2.1]# make CGI: [root@saturnus php-4.2.1]# ls -l ./php -rwxr-xr-x1 root root 2915010 Dec 18 22:24 ./php CLI: [root@saturnus php-4.2.1]# ls -l sapi/cli/php -rwxr-xr-x1 root root 2912387 Dec 18 22:24 sapi/cli/php Isn't it only an issue on win32? In the 4.2.X win32 binaries php-cli has always been called php.exe and php-cli php-cli.exe. I just don't understand why this can't be left in win32 releases like it has been before - at least until 5.0. I'm sure there are not many cli users which on win32 - and if: these people are certainly not the beginners and they won't start filing bogus bug reports. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Please mention the name change at least in the NEWS file and maybe php-cli could even output a readable error when beeing called as cgi. that sounds like a nice idea, but how would you know? Derick Perhaps by the presence of CGI environment vars? Sorry I'm amateur. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Please mention the name change at least in the NEWS file and maybe php-cli could even output a readable error when beeing called as cgi. that sounds like a nice idea, but how would you know? Derick Maybe you can test the presence of CGI environment variables? I'm amateur... Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Hi evolution is not an excuse here. We want to use PHP on the command line and many people will do also. And we make the command line usage as easy as possible. Even if that requires some mauals being updated and marking some bug reports as bogus. marcus If you really want to easy shell access to php on windows you can provide a batch script for startup (php-cli %1). To save even more keystrokes, call this script p.bat and let it guess the file extension of the script itself(php-cli %1.php). Like this you would have to type p index instead of php index.php and you'd save 6 more keystrokes - even without a bc break. If you provide (a more advanced version of) this script with the win32 distribution as php.bat, everybody has what s(he) wants/needs. Or is this really a philosophical question? Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
When installing a sapi for a web server i do it once and every time i update it i look if i have to change something in the setup - even file names. And before updating anything i test the stuff on a non production system. I hope (and I know) there's more evolution in php 4.3 than a senseless rename of php.exe on windows. I know you're right - but beeing right is not always the same as doing the right thing. Please mention the name change at least in the NEWS file and maybe php-cli could even output a readable error when beeing called as cgi. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Marcus Börger wrote: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. marcus It's worse. At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI). Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php.exe - php-cgi.exe
Hi In the NEWS file for 4.3.0 there should definitly be an entry about renaming php.exe to php-cgi.exe on win32, maybe this should even be mentioned on the download page together with the release. If not, there will be many bug reports about HTTP 500 errors and premature end of script headers after having installed PHP 4.3.0 as CGI on Win32. BTW, I still don't understand why php-cli cannot be called php-cli.exe on win32. Like this, many users would guess how the problem cgi and 4.3.0 can be solved even if they don't read php-dev (or the release notes). Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Marcus Börger wrote: I understand the reason why cli has to get a short name (the lazyness of good programmers). What i don't understand is why it has to be called php.exe. You force each and every user of php-cgi on win32 to change his webserver configuration when switching to 4.3.0. yes but they will have to touch their ini files any way. But not the webserver configuration. And: all the existing PHP HOWTOs will give them wrong information, some of them will never be updated... How many bug reports do you expect? 100? 500? Yes that could happen...maybe we should have another *big* message for the configure part and a *huge* message in the release notes and news entries. that's what i was asking for. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] auto_prepend/append: does the PHP engine cache the
If so ... maybe you can suggest something to me then? What about setting server variables? You can set them once, they stay in memory and your scripts can read them. Just an idea... Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] odbc problems in 4.2
Hi Dan I've been trying out with the snapshots from snaps.php.net/win32 but I still have the same errors. The actual snaps of 4.2 don't work either. Christoph I'm looking into these problems right now. Please be patient. A recent slew of bug reports suggests that there might be some stuff that is working for me here locally, but not for other setups.. As for getting a hold of a different version, the best I can suggest right now is A) try a snapshot from http://snaps.php.net/win32 or B) build your own (requires VC++, or some such compiler). On Fri, 26 Apr 2002, Ryan Jameson (USA) wrote: is this it then? How hard is it to get a hold of a version that is compiled the same way as my version 4.1.1? I'd really like to upgrade. I do have the tools I need to compile my own version but I'm not set up to do it and for the last 4 years of using PHP I haven't had to since the distributions have all worked. Thanks. Dan Kalowsky wrote: Hi Ryan, Okay did a little looking over the odbc_fetch_row code, and it should reset the result-fetched to whatever the second argument (if one is provided) is. This variable is how the ODBC result system handles where it currently is in the cache. Now the catch is that odbc_result checks this value, and if it's set to 0 re-fetches the results. This should be perfectly ok, just as if you start with a fresh resultset. Row # 0 doesn't contain data. So in otherwords the code sample you sent should work, provided that the $rs is a valid result. I'm having some local DB access/ODBC issues so I cannot test it right at the moment. I'm working on fixing that. On Wed, 24 Apr 2002, Ryan Jameson (USA) wrote: If this is easy for anyone could someone verify that: odbc_fetch_row($rs,0); ...does not reset the result set in version 4.2? From what I can tell it doesn't work at all. I want to be certain that we cannot upgrade to 4.2. If someone has another way to reset an ODBC result set I'd love to hear about it. It's done in a central core function, but is necessary in a plethora of scripts. The result set comes from the MS SQL Server driver (shhh... I tried to get them to use MySQL ... they are scared of free stuff. I'm just glad they let me use PHP). Thanks! Just to clarify: The odbc module doesn't cache or refetch resultsets. Whether you're able to reset a resultset depends on the odbc driver or driver manager you use (And how PHP was compiled, see below). If the driver doesn't support so called scrollable cursors, some Driver Managers (afaik unixODBC and the standard MS Windows DM do) provide support for this via a cusror library that caches resultsets and emulates scrolling cursors. My guess is that the PHP 4.2 you've tried was wasn't compiled with HAVE_SQL_EXTENDED_FETCH (so only the simple SQLFetch that can only move forwards gets used; the rownum parameter is ignored in this case) or that your DM wasn't configured to use it's cursor library. -Andreas
[PHP-DEV] Re: snaps.php.net
Jim Winstead [EMAIL PROTECTED] schrieb im Newsbeitrag [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Marko Karppinen [EMAIL PROTECTED] wrote: Even though no sane person can dispute the fact that the frantic pace of PHP3 development warrants fresh snapshot of the venerable scripting environment every three hours, many people feel that the development and especially QA efforts on the 4.2 branch would greatly benefit from snapshot availability. snapshots of the 4.2 branch are now available as php4-STABLE-* from snaps.php.net. I hope not to insult with that question, but win32 binaries of the snapshots of the stable branch would also be very helpful.. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: fopen UNC filename
| I tried to fopen(\\machine\shaer\file.txt,w) | | on w2k iis 5.0 PHP 4.1.0 and I got fopen invalid argument error. I know, | that UNC filenames are supported since PHP 4.0.6. I tried variants with | machine\\share\\file.txt, ... but the error was the same. Please read the latest threads about this on php-windows. It should work (4.06 didn't) with quoted backslashes (machine\\share\\file.txt) or slashes (//server/share/file.txt) if the permissions are set correctly. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #14877 Updated: HTTP_FDF_DATA not available
ID: 14877 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: FDF related Operating System: XP Pro PHP Version: 4.1.0 New Comment: yes, fdf is enabled. I found out that I can get HTTP_FDF_DATA in PHP when I append #FDF to the destination URL of the form (in Acrobat). I can then write the fdf file and reopen it correctly using Acrobat. But when trying to open it with php I always get th e following error: Warning: Could not open fdf document: formtest.fdf in f:\testroot\formtest\formtest.php on line 7 I doublechecked the script, it's just the same as in the manual. I can open the fdf file with fopen, but not with fdf_open. Could it be a version problem? I'm using Acrobat 5.05 which seems to produce FDF 1.2. I noticed that the fdfTk used in PHP is 4, the actual version from Adobe is 5. Christoph Previous Comments: [2002-01-05 20:31:21] [EMAIL PROTECTED] just curious: you have configured php to use the fdf extension? [2002-01-05 17:24:32] [EMAIL PROTECTED] The data from a PDF form doesn't arrive at the php script when submitted in FDF format, however it works, when the same data is submitted by the form with POST. I searched the data with phpinfo() to debug, but there were no entries (register_globals on and off). I tried with Apache 1.3.22 and IIS 5.1, submitting from Mozilla 0.97 and IE 6. The same script works with a php 4.08dev from July, 3. Test scripts and PDF form available on request. Christoph Edit this bug report at http://bugs.php.net/?id=14877edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14877: HTTP_FDF_DATA not available
From: [EMAIL PROTECTED] Operating system: XP Pro PHP version: 4.1.0 PHP Bug Type: FDF related Bug description: HTTP_FDF_DATA not available The data from a PDF form doesn't arrive at the php script when submitted in FDF format, however it works, when the same data is submitted by the form with POST. I searched the data with phpinfo() to debug, but there were no entries (register_globals on and off). I tried with Apache 1.3.22 and IIS 5.1, submitting from Mozilla 0.97 and IE 6. The same script works with a php 4.08dev from July, 3. Test scripts and PDF form available on request. Christoph -- Edit bug report at: http://bugs.php.net/?id=14877edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #14563 Updated: include_path in Apache SAPI on Win2K very broken...
[EMAIL PROTECTED] schrieb im Newsbeitrag
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
ID: 14563
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Configuration Issues
Operating System: Windows 2000 (Win2K)
PHP Version: 4.1.0
New Comment:
Warning: Failed opening '/apache/htdocs/curl_banking.php' for inclusion
(include_path='.;y:\apache\includes') in Unknown on line 0
PHP (on Win32) also responds also with the Failed opening '/x.php' for
inclusion message if it can't find the originally called file (try calling
a non-existant php-file), at least with PHP as SAPI, but not as CGI (message
in CGI: Unable to open x.php in Unknown on line 0')
There is no specific need to set it to .. It's the default.
If it is the same as the default, shouldn't it work?
If I can't get
include_path=.
to work under Win2K SAPI, how would
include_path=.;C:\PHP\includes
ever be able to function?
I always had to set '.' in include_path when setting any other value, at
least with SAPI.
I don't have much experience with Apache SAPI, but in IIS PHP has problems
to get the appropriate permissions for include files, specially if the
reside on network shares. In IIS the work around is to let IIS check the
permissions for PHP ('check that file exists'). Only after that PHP is able
to fetch the original file and the includes if the user on which the server
runs has the appropriate permissions.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #14531 Updated: Reference to bug #14496
But it would be cool to be at least able to add comments to bug reports of other users - like in the manual. Sometimes a non-dev member can reproduce a bug, give a hint or even an answer. Now, a common user who wants to comment a bug has to post to the dev list. Christoph Rasmus Lerdorf [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]... Users can update bug reports just fine if they bother to remember the passwords they set On 15 Dec 2001 [EMAIL PROTECTED] wrote: I hope we can have new bug tracking system, so that users can update bug reports :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #13292 Updated: file_exists not working with UNC names
For me it works since php-dev from july 4 2001 and also in 4.1.0. We had to
install the July 4 version on our production website to be able to access
UNC-style paths, now we could switch to 4.1.0.
We've made better experiences using //server instead of because there
has been a bug in the slash/backslash translation: To get \\ you had to use
- i don't know if this still exists, but this could be the reason
why Helmuts script doesn't work.
Christoph
[EMAIL PROTECTED] schrieb im Newsbeitrag
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
ID: 13292
Updated by: sander
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Filesystem function related
Operating System: Windows NT/2000
PHP Version: 4.0.6
New Comment:
Doesn't work with 4.1.0 nor with 4.2.0-dev.
Previous Comments:
[2001-12-14 14:29:39] [EMAIL PROTECTED]
This is not a Scripting Engine Problem, but a FIle System function report.
[2001-12-14 14:28:20] [EMAIL PROTECTED]
Any updates for this? This is a known issue for a long time.
To reporter: I don't use windows. Could you try 4.1.0 and report the
result?
[2001-09-13 15:55:36] [EMAIL PROTECTED]
On a Windows 2000 box with PHP and IIS5.0, create a page the calls the
file_exists function on a
known machine\share\file
You will need to create a share on that machine or another.
For example :
if (file_exists(machine\\share\\test.txt) {
echo ExistsBR;
} else {
echo Does not ExistBR;
}
The file_exists function will always return false.
The function works fine with drive letter associations, but not for UNC
notation on win32.
You have closed this bug with id #6554.
But this bug is not fixed in 4.0.6
Edit this bug report at http://bugs.php.net/?id=13292edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] bug system: user comment
Hi Actually, a bug entry can only be modified by the one who submitted the bug or by a developer with karma. It would be handy, if common users could add comments to existing bug reports. Otherwise they have to enter a new bug report if they want to provide additional information to a bug which has already been reported before. Maybe this would reduce the amount of duplicate bug reports. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
