I´ve written a tool using PHPseclibs SFTP solution to uplaod various files to different target server. All targetserver are using wingFTP.
Under some conditions the upload fails without giving any debug message or error code.
I could figure out that the error (if it occures) allways occures in the following line of my code:
[...]
if(!$sftp->put($aResult[0]["targetpath"] . $sFilename, EXPORTFOLDER . "/" . $sFilename, NET_SFTP_LOCAL_FILE)){
[...]
Is there any way to see what is happening? There are no error messages or something... can I configure debug/error messages while using PHPseclib somewhere?
In about 95% of all cases the Upload is successfull and it does not only appear on one target server or for one file. Does someone have an idea where the problem could be located?
Related
I am using the Laravel filesystem calls - for example: Storage::disk('sftp')->put and it is working fine but I am wondering how I can view debug or error information if there ever were the need?
So for example if the file upload failed, how would I see that? When I first wrote the code it was not working and there was no Laravel exception screen and nothing in the laravel.log.
I'm in the same case.
I'm using Laravel Storage library with league/flysystem-sftp for sftp transfer. Here is the problematic line.
Storage::disk(self::REMOTE_DISK)->putFileAs($destFolder, $this->localFilePath, $destFilename);
Most of the time all is working fine. File is copied from local to remote without any problem.
But sometimes one problem occurs and I failed to understand what's occured during the transfer.
All I can do (at this time) is
$result = Storage::disk(self::REMOTE_DISK)->putFileAs($destFolder, $this->localFilePath, $destFilename);
if ($result === false) {
$exception = new FileUploadFailureException("file upload has failed");
}
Is there a better way to debug one sftp connection trouble ?
I usually don't post any question on Stack Overflow because I always find an answer to whatever problem I'm in trouble with. But here, I haven't found a clear answer so if you can help me, thanks a lot !
I'm working on a Symfony 3.4 website. I've made a script inside my controller to return a file as a BinaryFileResponse.
$response = new BinaryFileResponse($pathtofile);
$response->setContentDisposition(ResponseHeaderBag::DISPOSITION_ATTACHMENT, $filename);
return $response;
At first, the downloading process works ok, but just at the end, an error occurs. Chrome returns a "Network error" failure and the downloaded file stays as a .crdownload instead of being rename as an .mp3 in my case. (Note : If I rename manually the file as an .mp3, it plays correctly.)
I've searched for a possible issue on the content-length property of the headers, but it seems to be sent correctly when I check the Symfony Profiler Capture here
I've found a way to bypass this error by using a stream as mentionned in the Symfony Docs, like this :
$stream = new Stream('path/to/stream');
$response = new BinaryFileResponse($stream);
My file is served by a PHP script, but it is not generated by it. Is there a way to serve it as a static file instead of a stream ?
With the stream solution, the client can't see the actual size of the file, which is not really user friendly. Also, it is really slow.
Thanks for your help !
EDIT : the first solution works on localhost, but not on prod server.
Thought I would drop a question, as this is giving me a proper headache
I have a PHP application which uploads files into SoftLayer Object Storage containers.
To communicate with the Object Storage API I am using the PHP bindings from
https://github.com/softlayer/softlayer-object-storage-php
and referenced them from my composer.json file
"softlayer/objectstorage": "dev-master",
Retrieving object container files and urls is working all fine.
But I keep having problems with uploading files though, specially depending on their size. It used to work couple of days ago but some reason stopped working recently
Here is the 'out-of-the-box' code I am using for uploading files:
$options = array('adapter' => ObjectStorage_Http_Client::SOCKET, 'timeout' => 10);
$objStorage = new ObjectStorage('', '', '', $options);
try {
$newFile = $objStorage->with('RemoteFilePath')
->setLocalFile($PathTolocalFile)
->create();
return $newFile->getUrl();
}
catch (Exception $e) {
return $e->getMessage();
}
For some reason, uploading a file that is under 1Mb works. But any file with a size bigger than this, the ->create() request eventually times out, no exception is thrown and I keep getting these error in my log:
xxx.xxx.xxx.xx - [05/06/16 03:47:02] Warning: fwrite(): SSL operation failed with code 1. OpenSSL Error messages:
error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry (/var/www/vendor/softlayer/objectstorage/lib/ObjectStorage/Http/Adapter/Socket.php:132)
As those bindings are essentially a wrapper round curl, I then tested with CURL myself see if I could upload a file bigger than 1M to Softlayer Storage Container. It turns out it succeeded using CURL both on my dev machine and staging server!
curl -i -XPUT -H "X-Auth-Token: {{MyAuthToken}}" --data-binary "#BigFile.txt" https://lon02.objectstorage.softlayer.net/v1/{{MyAuthTokenKey}}/{{MyContainer}}/BigFile.txt
Have you ever come across this? I don't understand why it suddenly stopped working.
Has anyone any idea?
Thanks for reading
I was not able to reproduce your issue, I was able to upload files higher than 2 MB using your code.
Anyway, the issue that you have is related to SSL/OpenSSL broken, take a look the following links in order to get more information about it and how to solve it:
Bug #54439 SSL/OpenSSL
broken
fwrite(): SSL operation failed with code 1. OpenSSL Error
messages:\nerror:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write
retry IN
PHP
Why am I getting “error:1409F07F:SSL routines:SSL3_WRITE_PENDING:
bad write retry” error while attempting an
SSL_write?
I have used DROPBOX API to upload backup on my dropbox+php...And I'm on the half way
1)I have made local-connection and took backup file in my local
2)Then I have added key,secret(in config.json) and generated access-token(dropbox_sqlbackup.php) in proper place
Now Where I am stuck is:
I am not able to upload the generated backup file of database on my dropbox...
my error message is:
Fatal error: Uncaught exception 'Exception' with message 'The Dropbox SDK uses 64-bit integers, but it looks like we're running on a version of PHP that doesn't support 64-bit integers (PHP_INT_MAX=2147483647). Library: "C:\xampp\htdocs\demo\dropbox-sdk\lib\Dropbox\RequestUtil.php"' in C:\xampp\htdocs\demo\dropbox-sdk\lib\Dropbox\RequestUtil.php:22
now i have tried other answers on stackoverflow to remove "64 bit integer conversion" but not getting what to do??
the demo i have follwed is :
http://www.inboundhorizons.com/use-php-and-dropbox-api-to-automatically-backup-mysql-databases-to-dropbox/
Which is just to get reference...
Finally, I found the solution....
Don't try the demo in your local system,it will not work in local,You only need to upload the code in live and test it..!!
NOTE:In local your backup file will be generated in your folder but it could not be uploaded on dropbox account
I've spent a lot of time troubleshooting this myself but none of what I've read solves my issue so I'm hoping I get some help here.
So anyway, I have written a PHP script that provides various functions to connect with Google Calendar. When I run this script directly using some inline test code to call my functions, everything runs fine. However, when I call the function from other scripts using 'require_once' to include it I get the following errors:
Warning: include_once(Zend\Gdata\Calendar\Extension\EventQuery.php) [function.include-once]: failed to open stream: No such file or directory in C:\Users\Luke Franklin\Clients\Tiers For Tea\Development\TiersForTea.com v1.1\lib\Zend\Loader.php on line 134
Warning: include_once() [function.include]: Failed opening 'Zend\Gdata\Calendar\Extension\EventQuery.php' for inclusion (include_path='.;C:\xampp\php\PEAR;C:\Users\Luke Franklin\Clients\Tiers For Tea\Development\TiersForTea.com v1.1\lib;C:\xampp\htdocs\TiersForTea.com\lib') in C:\Users\Luke Franklin\Clients\Tiers For Tea\Development\TiersForTea.com v1.1\lib\Zend\Loader.php on line 134
Your first thoughts might be that I'm not using the correct include path, but I have checked and rechecked this many times. I even tried hard coding the path. I'm quite sure that I'm using the correct path.
Now for the weird bit. If you look at the error you will notice the file Zend is trying to include: Zend\Gdata\Calendar\Extension\EventQuery.php. This file does not actually exist in the 'Extension' folder. It does exist in the parent folder though. If I just copy 'EventQuery.php' into the 'Extension' folder my script runs as expected. Weird, right?
So that does sorta solve my problem, but I would like to know what's going on here in-case it creates further issues. I should also note that I'm calling this script into an OpenCart module.
You might want to see some of my code so here's a snippet of the important bits, if you want more details just let me know:
<?php
set_include_path(get_include_path() . PATH_SEPARATOR . realpath('\\lib') . PATH_SEPARATOR . "C:\\xampp\\htdocs\\TiersForTea.com\\lib");
require_once('Zend/Loader.php');
function connect() {
Zend_Loader::loadClass('Zend_Gdata');
Zend_Loader::loadClass('Zend_Gdata_ClientLogin');
Zend_Loader::loadClass('Zend_Gdata_Calendar');
I doubt the error exists in any of the Zend files as you have indicated it works correctly in your isolation tests.
The error is thrown from Zend_Loader which means something in your code is making reference to Zend_Gdata_Calendar_Extension_EventQuery.
Check the stack trace for the error if available to pinpoint the location. If that's not available, do a global find for that string. If you find any matches, you will need to change them to Zend_Gdata_Calendar_EventQuery.
Update
Seems this is a known bug(s)
http://framework.zend.com/issues/browse/ZF-7013
http://framework.zend.com/issues/browse/ZF-11959
It's an issue when your code registers an error handler using ErrorException. Apparently it's fixed in the 1.12 branch but hasn't made it to a release yet.
There's a patch in the 11959 bug report that fixes the issue