Fixed php7.1; ErrorException: tempnam(): file created in the system's temporary directory

[Xon]

If you are stream wrappers; php7.1 starts throwing "tempnam(): file created in the system's temporary directory" on avatar or attachment uploads. This is because tempnam() deosn't actaully support stream wrappers.

Previous versions would silently use the system temporary directory, and as such would work as expected.

The problem is XenForo_Helper_File::getTempDir is defined as:

 public static function getTempDir()
 {
  return self::getInternalDataPath() . '/temp';
 }

Rather than something that can be defined independantly of the internal data path which can be in a path defined by a stream wrapper.

This affects;

• avatar uploading on registration (gravatars)
• attachments
• avatar uploading
• various importers

I think this affects:

• XenForo's HTTP client (image proxy + title auto-link)

 

[af123]

I think XenForo probably needs to catch this exception and ignore it although, in my case (https://xenforo.com/community/threads/124064 ) it did make me aware of a missing directory.

 

[Xon]

I think a safeTempnam() will be created like there is a safeRename() will be requires since there is a bit of logic that needs fixing around it.

 

[Mike]

Given that we're talking about a temp file, I don't think there's any disadvantage to using sys_get_temp_dir in getTempDir if your internal_data path is a stream wrapper (matches 'protocol://'). Beyond the tempnam usage, I'm not sure you'd necessarily be wanting to actually create a temp file in (say) S3 and clearly that has just silently fallen back to the system temp dir previously so this shouldn't really be behaving any differently with this change.

 

[Groatz]

So was there a conclusion? We've started getting this recently. We use AWS S3 also. PHP 7.3

 

[Groatz]

Sorry, just trying to understand how this is Fixed as the problem still exists and there doesn't seem to be a XenForo workaround or fix in this thread?

 

[Mike]

This report may have applied to one specific scenario, though given the age of it, the context within it may no longer be relevant. It's quite unlikely that what you're running into is a different issue than what was described here, unless you have done specific configuration things which aren't necessarily something we support.

Out of the box, this generally points to permission issues against the internal data directory (or the temp directory which is normally within it, unless you have explicitly overridden it). If that doesn't solve the issue, you should probably post a new troubleshooting thread with more details about the configuration overrides you've set.

 

[Groatz]

This report may have applied to one specific scenario, though given the age of it, the context within it may no longer be relevant. It's quite unlikely that what you're running into is a different issue than what was described here, unless you have done specific configuration things which aren't necessarily something we support.

Out of the box, this generally points to permission issues against the internal data directory (or the temp directory which is normally within it, unless you have explicitly overridden it). If that doesn't solve the issue, you should probably post a new troubleshooting thread with more details about the configuration overrides you've set.

Sorry, what I mean is do you have an official fix on the horizon? The system value of php is pointing to /tmp to get around the streaming issues (we host on s3) for temporary files as Xon pointed out. That's coming up now in PHP 7.3 for us and not being handled. It's essentially the same issue.

 

[Mike]

This bug report relates to XF1 and it doesn't really have any relation to XF2, so there is nothing more to change. (If you are still running XF1, then that isn't a supported version any longer.)

In terms of XF2, there isn't any expectation that the internal data path is pointed to anything other than a local path. Hosting via S3 is done through the filesystem abstraction framework rather than PHP stream wrappers. So this would generally point to a local filesystem permission/setup error that should be resolved. Beyond that, if it really is needed, you can explicitly override the temp data location via config.php.