могу логически понять её
1. Есть консольная команда, она в мультипотоках качает файлы из удаленного сервера во временный файл (максимум 10 параллельных потоков):
$download_temp_path = tempnam(sys_get_temp_dir(), 'resource_');
// GuzzleHttp\Client
$client->get($file->download_url, [
'sink' => $download_temp_path
]);
2. Затем с этим файлом делаю некоторые манипуляции и обновляю модель:
$file->md5 = hash_file('md5', $download_temp_path);
$file->sha1 = hash_file('sha1', $download_temp_path);
$file->sha512 = hash_file('sha512', $download_temp_path);
$file->size = filesize($download_temp_path);
$file->save();
3. Далее — сохраняю в облако:
Storage::cloud()->put($file->download_path, fopen($download_temp_path, 'r+'));
4. А затем удаляю его локально:
if (file_exists($download_temp_path)) {
unlink($download_temp_path);
}
Происходят коллизии. Некоторые временные файлы иногда остаются на сервере и не удаляются вовсе.
Причем, если пропустить махинации с файлом (п. 2, 3), — файлы удаляются корректно, мусора никакого не остается
Подскажите, сталкивался ли кто-нибудь с такой проблемой? Может, есть мысли на этот счет?
а выполнение вообще доходит до 4 пункта то?
Да, ведь иначе я бы видел ошибки Ошибок никаких не возникает
Если файлы большие лучше вместо guzzle -> get, использовать Process и curl системный. Это будет и быстрее и памяти меньше)) не говоря про то, что curl системный в отличии от guzzle->get поддерживает докачку с ключем -C.. $process = new Process(['curl', '-L', '-o', $download_temp_path, $file->download_url]); $process->run(); По теме - при манипуляциях с файлами какие процессы происходят? Нет ли отвязки пути от оригинального? А так же, расставь дебаг поинты, чтобы понять, что точно unlink вызывается. Учитывая, что не пишешь по наличие ошибки, скорее всего ошибка не возникает, в результате чего теоретический unlink не вызывается. По условию он может не вызываться если файл отсутсвует, однако тогда вопрос какой путь попадает в условие в случаях когда временные файлы каким-то образом остаются?
Обсуждают сегодня