@KevinTheJedi
I think I found the problem.
Given that if I remove the delete command (commenting out the line) the file export works.
// Delete the file.
// @$exporter->delete();
The file is also deleted later by:
scp/export.php → $export->download(); → if ($delete) @$this->delete();
The most correct and least invasive fix would be:
- don't delete the file in
queueExport() of ajax.tickets.php
- let the exporter delete it after downloading by function download
in include/class.export.php the download function always has delete set to true, so the file is already deleted after export, deleting it in the ajax.tickets.php file creates the bug.
function download($filename=false, $delete=true) {
$this->close();
$filename = $filename ?: $this->getFilename();
Http::download($filename, 'application/octet-stream', null, 'attachment');
header('Content-Length: '.$this->getFileSize());
readfile($this->getFile());
// Delete the file if requsted
if ($delete) @$this->delete();
exit;
}
Upon further investigation, there's a factor that makes the bug environment-dependent: ack() uses Http::flush(), which in turn tries to immediately close the response and, if available, calls fastcgi_finish_request(). However, the PHP documentation clearly states that flush() doesn't always bypass web server or browser buffering; fastcgi_finish_request() only works in certain stacks, and with buffering/proxy enabled, the client may see the response too late, that is, when the file has already been deleted by the background process. This explains why commenting out the delete makes the file available again.
I've updated the github issue:
https://github.com/osTicket/osTicket/issues/6756#issuecomment-4011537301
