PHP Wamp is not finding a file which exists - php

I'm having a critical issue where my WAMP installation for PHP 5.3.0 is not finding a file which exists within my computer. Does anyone know anything about this? Possibly a PHP Bug?
Any help would be much appreciated.
Here is the variable which creates the file:
$baseNewsUrl = "C:/reviews/reviews/$platform/$fullname";
And here is the code which grabs the contents:
if(is_file($baseNewsUrl)){
$contents = file_get_contents($baseNewsUrl);
} else {
echo "File not found. " . "\r\n";
continue;
}
Here is the output of $baseNewsUrl: C:/reviews/reviews/GBA/r20107_GBA.htm
And the file does exist.

Check that the entire path leading up to your file is readable by the user PHP is running as (if you are using IIS, this might be something like "Network Service," although I am not particularly experienced with PHP on Windows). Also, check whether the INI directives "open_basedir" or perhaps "safe_mode" are set--these would give PHP self-imposed limits on which files are accessible.

Do a var_dump (not an echo) on your variable.
var_dump($baseNewsUrl);
and look at the actual contents. You may have some invisible garbage characters in there that's preventing Windows if you're doing this in a browser to make sure there's no empty tags (or other browser-render-invisible) characters.
If that doesn't reveal anything, remove the is_file check and try to open the file with file_get_contents (or any file related function) and var_dump it's contents. You'll either open the file, or PHP will spit out an error/warning/notice (either to your browser or to your error log) that should let you know why it can't open the file.

I'm gonna say this, and it very well might not be your problem but it is a recurring one for me. If you use skype on your computer, it has a somewhat known compatibility issue with WAMP. It cause's WAMP to be unstable, not load files properly.. everything.

on windows
$baseNewsUrl = "C:\\reviews\\reviews\\$platform\\$fullname";

It's due to Windows Vista and WAMP.

Related

fopen creates the file, so why is the fwrite failing?

I have this stupid little test PHP script running on a Ubuntu system inside an instance of a virtual server (Oracle Virtual Box) running on my pc:
<?
error_reporting(E_ALL);
ini_set('display_errors', 1); // show errors
echo "<p>test</p>";
$filename = "andy.txt";
$fh = fopen($filename, 'w') or die('fopen failed');
fwrite($fh, "qwerty") or die('fwrite failed');
fclose($fh);
?>
Despite all appropriate directory and file permissions being set, it is failing on the fwrite. The fopen works and creates the file, so write access is clearly enabled, but the fwrite dies, and the 'fwrite failed' message is output (no other error output is displayed).
The same script works perfectly well when I upload to my real server, so I am completely stumped as to why it won't write to the file; maybe it's something about my virtual server that is causing the problem.
Seems like such a pathetic thing, but it's driving me nuts! Considerable time Googling has failed to yield an answer, so can anybody here please provide some insight? Many thanks.
Not sure why the fwrite() call would die, as it returns the number of bytes written.
That said, have you tried with file_put_contents() instead? It's a simpler way of writing to a file, and is the recommended way since early PHP 5.
With it you only need to do the following
$filename = "andy.txt";
if(!file_put_contents ($contents, $filename)) {
// Write failed!
}
No need to bother with opening and closing the file pointer, as that's automatically handled by the function. :)
Solved! It was a disk space error on my virtual server. At the back of my mind, I knew I had seen this mentioned elsewhere as an issue with write fails, but in this case I failed to make the connection.
#ChristianF Thanks! Switching to file_put_contents() was very helpful, since it also failed, but gave me a meaningful error message:
'file_put_contents(): Only 0 of 6 bytes written, possibly out of free disk space'
Aha! Having recalled that growing log files can be a problem, I took it upon myself to delete everything inside /var/log (after saving them) and Presto! it now works! So, thank you for that tip - I will switch to using file_put_contents from now on. BTW: The contents of error.log itself was 2GB, while the remaining size of everything else in /var/log was only about 15MB, but deleting error.log by itself did not work, so I deleted everything.
#Clayton Smith Thank you, but removing the "or die('fwrite failed')" part did not result in any further error info - which is what is so frustrating: It's a shame that those error reporting directives at the start of the script didn't seem to do much.
#NaeiKinDus Thank you, but I don't think I have SELinux running (I'm afraid I don't know anything about this). Although I have a /etc/selinux directory present, there's no config file in it, just what appears to be a skeleton semanage.conf - whatever that is. Commands such as sestatus are not recognised.

Bug with the PHP exec() function for an ADA program

I really need some help for a problem.
I'm trying to use the exec() PHP function which is directly integrated on PHP, but it doesn't work.
I've tried this :
$directory = "C:/wamp/www/ADA-WEB/Conversion";
$file ="/main.exe";
chmod($directory, 0600);
exec($directory.$file);
But nothing goes on. So, i've tried to see if an error was reported on the Apache Log, and this is what appears :
raised ADA.IO_EXCEPTIONS.NAME_ERROR : convertir\EXPORT.DAT: No such file or directory
It's a typical error that ADA may raise.
But i don't understand why this error is generated. It seems that PHP runs the file on a random folder (perhaps a temp one).
When i launch directly the exe on windows i don't have this kind of problem.
If you should help...
Thanks a lot.
Nicolas
You could consider using http://php.net/manual/fr/function.chdir.php before launching your ada application. This way you can control what is the current directory used when running your binary
$directory = "C:/wamp/www/ADA-WEB/Conversion";
$file ="/main.exe";
$current = getcwd();
chdir($direcoty);
chmod($directory, 0600);
exec($directory.$file);
chdir($current);
Well, i've changed my mind, going on another direction..
After more searches about this problem it really seems that the problem is not because of the exec() function but because Windows doesn't allow a program to be executed through a navigator.
Thanks for your answers.
Nicolas
There may be alternative approaches to the problem. that sidestep the limitation (apparently with Windows) that you are facing.
If you're driving an Ada program through a web-based interface, the Ada Web Server (AWS) toolkit is a way to build a webserver right into your program - it's easy to use, and fast too. Apparently there is some other toolkit called AWS, but the one I mean is here: with an introduction here. See also this StackOverflow question for some other views on the toolkit.

Extract a Zip Archive using PHP

what i'm trying to do is to basically extract the contents of Zip archives on my server.Here is some code:
$entry="test.zip";
$zip = new ZipArchive;
if ($zip->open($entry,ZIPARCHIVE::OVERWRITE) === TRUE)
{
$zip->extractTo('unpacked');
$zip->close();
}else
{
echo ‘failed’;
}
the directory "unpacked" is writeable for everyone and all the used methods of the ZipArchive Class return true. However nothing is being extracted. Does anyone happen to have an idea what could cause this behaviour? Any hint will be highly appreciated...Thanks in advance!
If you are using PHP 5.2.0 or later can you check zlib extension first http://www.zlib.net/
You also check PECL extensions, In order to access ZipArchive, you can also try zip_open, zip_read just for checking.
If this code is in-house, and you can safely make the assumption that you won't move this code from Linux to Windows (or vice versa), you also have the option to execute local system commands, which may help solve your problem.
<?php
echo `unzip myarchive.zip`;
echo `tar -xzf myotherarchive.tar.gz`;
?>
When developing internal-use and/or maintenance scripts, I used to opt for straight-up system calls, as it was more in-line with the commands sysadmins were used to using.
In case of failure you should echo out $zip as it contains the error.
Furthermore I'd guess that you may not have the needed permissions for test.zip
If your zip archive is big, sometimes you cannot extract all files during the maximum allowed execution time of your server.
The only solution, if you cannot change the maximum_execution_time in your php.ini, is to use a javascript to extract one file after the other. On the first javascript request you take the number of files in the archive
$nbr_of_files = $zip->numFiles;
And after you extract one file after another using the id number in the zip archive for each file
$zip->extractTo('unpacked', array($zip->getNameIndex($file_nbr)));
Please try removing the ZIPARCHIVE::OVERWRITE flag from the ZipArchive open method. (The flag may not be functioning as expected and may be the root of the issue if you have followed the advice in the other answers.)
I had the same issue too. The solution:
$zip->extractTo(public_path() .'/restoreDb/extracted/');
add the public_path() helper function.

Shortcut web page file in PHP

I wish I knew how to make a file that is a principal access to a web page. I'm using PHP to do this. It occurred to me the following:
function crearArchivoUrl($url){
$archivo=str_replace(array("http://", "https://", "mailto://", "ftp://"), "", $url);
$archivo=str_replace(array("/"), "-", $archivo);
$this->checkNombreDestino($archivo);
$contenido="[InternetShortcut]\r\nURL=".$url."\r\n";
$fp = fopen($archivo, 'w');
chmod($archivo, 0644);
fwrite($fp, $contenido);
fclose($fp);
}
But when I test it (by double-clicking on it) I did not jump the browser.
Anybody can tell me how to make files that are shortcuts to web pages?
Thanks for the help.
Greetings!
My code was correct, all I needed was that the file extension should be .url, ie, my-web-shortcut.url
Thanks for everything.
Greetings!
Your PHP will only be executed if you have a PHP interpreter installed, and if the webserver is configured to run your PHP file. If you distribute this file to unconfigured computers, it will never be executed as PHP code, and will therefore never run as you expect.
If you are running this script on a webserver that is properly configured, consider using header("Location: <URL>") to redirect the user to the new page.
Actually, you are reading a file, and writing it to another file. Doing that sends nothing to the web browser.
A first approach would be to send a header Location to redirect the broswer. See examples in the manual to know how to use it.
Another approach would be to read the file contents, and to print it, using echo or any other printing command.

can't include("absolute_path")

I can't figure out why this won't work.
$docRoot = getenv("DOCUMENT_ROOT");
include_once($docRoot."/conn/connection.php");
include_once($docRoot."/auth/user.php");
It works locally through wamp, but it won't work on my live server. I tried this:
if(!include_once($docRoot."/auth/user.php")){
session_start();
$debug = array();
$debug["docRoot"] = $docRoot;
$debug["inc_path"] = $docRoot."/auth/user.php";
$debug["file_exists"] = file_exists($debug["inc_path"]);
$_SESSION['DEBUG'] = $debug;
// exit
header("Location:debug.php");
exit();
}
The debug page just echoes that array and it shows the correct absolute paths and indicates that the file does in fact exist. So why didn't the include_once() work? The server (a DV account on a MediaTemple server) has not been configured at all, so I wonder if there is an apache or php setting that is messing with me.
Ultimately, what I want here is a way to refer to a file in such a way that if I move the file, or include it in another file, nothing will break. Any ideas?
In your debugging you might try is_readable($docRoot."/conn/connection.php"). The file_exists function will return true even if the file does not have readable permissions.
If you get an error code we might be able to provide more info as to what is going wrong.
Turn on error reporting dummy. It turns out one of the includes on another file was breaking this page and I wasn't able to trace that out until I turned on error reporting.
Incidentally, the problematic include was missing a leading slash in the filepath ( include("dir/file.ext"); ) which works on my local wamp setup and breaks on the linux server.

Categories