Thanks Stuart. However, I've looked into this and confirmed that's not the problem. At the point the exception is thrown in the FB SDK (this is after CURL has tried to post and returned an error), I added some code in to check the temp file to be posted still exists and can be read (by file_get_contents) and both are true - the file is fine and readable, and permissions are set to 0777 (not sure if necessary or not, but just in case). So the problem is CURL cannot read the file from vfs:// - is this a bug?
I also checked what parameters were being passed to CURL immediately before it executes, and they are as follows (I hardcoded the filename):
Parameters = Array
(
[source] => CURLFile Object
(
[name] => vfs://root/temp/mytest0001
[mime] => image/png
[postname] =>
)
[message] =>
[access_token] => My-Token
[appsecret_proof] => My-Secret-Proof
)
I am generating the temp file's name only once in the code, using:Â
$randfname = 'mytest0001'; // Normally a short random string
$imfname = sys_get_temp_dir().'/'.$randfname;
As a side note, it didn't make sense that the vfs:// file would be deleted at the point CURL accesses it, because the FB SDK is called to do the post immediately after the file is created, and I assume the call is not asynchronous, so my script must be waiting for that to return and thus not deleting any temp files (confirmed of course, as above).
Any ideas appreciated!
Many thanks,
Alex