Всё пропало, файловые блокировки выпилили?

[weregod]

Windows 10, под Ubuntu 18.04.3 LTS проверял только на PHP 7.4

error_reporting(E_ALL);

$path = "./file";
file_put_contents($path, "stuff");
$file = fopen($path, "r");
flock($file, LOCK_EX);
unlink($path);

PHP 5.6
Warning: unlink(./file): Permission denied in ...
PHP 7.2
Warning: unlink(./file): Resource temporarily unavailable in ...
PHP 7.3 и 7.4 молча удаляют файл (((

 

[флоппик]

А как ты хочешь сам от себя блокировку получить в этом же процессе?
В 7.3 и 7.4 поведение правильнее, мне кажется.

 

[fixxxer]

Во-первых, блокировка - это, условно говоря, привязка inode к pid, и процесс, получивший блокировку, ни в чем не ограничен (в этом и смысл).
Во-вторых, unlink - это по сути просто "отвязка" конкретного имени файла от inode (потому и unlink, а не delete): inode удалится только когда (1) количество "имен файлов" в файловой системе будет равно нулю (а их может быть сколько угодно) и (2) все процессы закроют соответствующие этому inode дескрипторы.
В-третьих, unlink залоченного файла - это стандартный паттерн при работе с локфайлами, так что раньше был баг.

Это все, конечно, в контексте Unix-систем, в Windows все иначе, но кого волнует Windows? Видимо, сделали, чтобы поведение в Windows было таким же, как в Unix, что абсолютно логично для кроссплатформенного продукта.

 

[AnrDaemon]

в Windows все иначе

Кто тебе сказал такую глупость?

 

[fixxxer]

Я, конечно, виндой не пользовался очень давно, но помню, что при попытке удаления открытого файла возвращалась ошибка, и приходилось искать, какой же процесс его держит открытым.
Вряд ли что-то с тех пор поменялось

 

[AnrDaemon]

Если файл не заблокирован, удаление будет успешным.
Это верно и для Линукса.

 

[fixxxer]

А это тогда что?

The DeleteFile function fails if an application attempts to delete a file that has other handles open for normal I/O or as a memory-mapped file (FILE_SHARE_DELETE must have been specified when other handles were opened).

Вот, из-за тебя гуглю какую-то фигню. Вообще мне сто раз наплевать, что там в винде, но ты достал спорить на пустом месте, даже не проверяя свои утверждения.

 

[AnrDaemon]

Вот сейчас ты не прав. В POSIX не уточняется, как именно программы обязаны блокировать файл при открытии. То, что Windows по умолчанию не разрешает удаление файлов, открытых для чтения - не более чем специфика реализации. Само поведение остаётся прозрачным - если блокировки нет, файл удалится. Другое дело, что при этом будет происходить с файловой системой в Linux и в Windows. Если удалённый файл имеет открытые дескрипторы, под Windows он будет виден в системе, пока все дескрипторы не будут закрыты. Под Linux файл пропадёт из видимости сразу после успешного удаления.

 

[fixxxer]

Да-да, конечно, можно натянуть сову на глобус, и сказать, что OpenFile по умолчанию делает такую блокировку, которая блокирует только на удаление, а специально взведенный FILE_SHARE_DELETE отменяет поведение по умолчанию, а то, что при взведенном FILE_SHARE_DELETE удаленный файл как бы и не удален - ну это так, не имеет отношения к вопросу.

Хотя совершенно понятно, что отличия тут ключевые, если просто вспомнить, как (примитивно) устроены файловые системы семейства FAT, и архитектура обоснована прежде всего (частичной) обратной совместимостью вплоть до Win16.

 

[grigori]

в винде прикол в том, что файл остается в файловой системе после освобождения другим процессом, и удалить его после этого уже нельзя до перегрузки, я винду в целом люблю, особенно с WSL2
щас пишу с мака в кафе, не могу проверить алгоритм как воспроизвести

 

[fixxxer]

особенно с WSL2

А докер нативно уже заработал?

Все это проксирование I/O с нелинуксовой хостноды, хоть и все время улучшается, с ростом проекта и количеством сервисов в compose все равно начинает тормозить адово.
Я вот месяца три назад устал от тормозов на маке, психанул и купил десктоп с core i9 и 32 гигами оперативки, на который поставил линукс - все летает. Макбук остался, конечно, для всяких фотошопов, ну и для мобильности (что не особо актуально ввиду происходящего).

щас пишу с мака в кафе

Я тебя ненавижу.

 

[AnrDaemon]

файл остается в файловой системе после освобождения другим процессом

> ECHO . > test & START "" far /v test
// FAR в режиме просмотра не блокирует запись/удаление

> DIR /B test & TYPE test
test
.

> del test & dir test & type test
test
Отказано в доступе.

// Закрываем FAR
> DIR /B test
Файл не найден

Из документации:

7.3.0 On Windows, it is now possible to unlink() files with handles in use, while formerly that would fail. However, it is still not possible to re-create the unlinked file, until all handles to it have been closed.

Впрочем, это легко обходится через

<?php

$n = __DIR__ . "/test";
$x = tempnam(dirname($n), "xy");

$f = fopen($n, "wb+");
rename($n, $x);
unlink($x);

 

[fixxxer]

7.3.0 On Windows, it is now possible to unlink() files with handles in use, while formerly that would fail. However, it is still not possible to re-create the unlinked file, until all handles to it have been closed.

О, это, конечно, шикарно:

https://github.com/php/php-src/blob/f6ae728f562acf28bbdd45f41f4caddd07d08659/win32/ioutil.c#L424

https://docs.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-file_disposition_info

https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfileinformationbyhandle?redirectedfrom=MSDN

То есть, чтобы удалить файл, который удалить как бы нельзя, но можно, надо его открыть со специальными флагами и потом взвести другой специальный флаг.
И эти люди запрещают мне ковыряться в носу!

 

[AnrDaemon]

Нет, это означает, что надо правильно интерпретировать ответ системы на твои действия.

 

[grigori]

А докер нативно уже заработал?

Все это проксирование I/O с нелинуксовой хостноды, хоть и все время улучшается, с ростом проекта и количеством сервисов в compose все равно начинает тормозить адово.
Я вот месяца три назад устал от тормозов на маке, психанул и купил десктоп с core i9 и 32 гигами оперативки, на который поставил линукс - все летает. Макбук остался, конечно, для всяких фотошопов, ну и для мобильности (что не особо актуально ввиду происходящего).

Comparing WSL Versions

WSL 2 provides the benefits of WSL 1, but uses an actual Linux kernel, rather than a translation layer like WSL 1, resulting in faster performance.

docs.microsoft.com

в этом же весь смысл, теперь в Docker Desktop не задаешь объем памяти - на старте кушает 1гб, и потом сколько надо
подмонтированные с ntfs файлы подтормаживают, естественно, а база с нативного шареного volume стартует прям заметно быстрее, чем раньше, и чем в макбуке

У меня на свежем MacBook Pro 16" PHPStorm между файлами переключается с маленькой, но раздражающей задержкой ... в чем может быть проблема?
На винде задержки нет, конфиги PHPStorm засинканы. Может, просто десктопный проц за счет TDI вытягивает, и никакие оптимизации за 5 лет не компенсируют частоту ядра и размер кеша?

Я тебя ненавижу.

 

[fixxxer]

У меня на свежем MacBook Pro 16" PHPStorm между файлами переключается с маленькой, но раздражающей задержкой

Ахз, не сталкивался с таким.

подмонтированные с ntfs файлы подтормаживают, естественно

Ну в том и проблема. С нативными volumes и на маке уже все хорошо в edge сборке докер-десктопа. А вот компиляция из сорцов, подмонтированных с внешней хостноды (ну а где мне их еще редактировать?), с ростом проекта начинает тормозить довольно мучительно. (С php такой проблемы почти нет, я понимаю =)

 

[grigori]

ставь вендоров в нативный volume, а свой код монтируй из host os, в чем проблема?

для composer это одна строка в entrypoint-скрипте контейнера

#!/bin/sh

cd /code/ || exit

[ "$(ls -A /code/vendor 2> /dev/null)" ] || composer install --no-dev &

 

[fixxxer]

С php такой проблемы почти нет, я понимаю

Я на php почти не пишу уже.

 

[grigori]

в ноде точно так же указывается путь для зависимостей

впрочем, какая разница, ты уже решил задачу пачкой денег

 

[grigori]

У меня на свежем MacBook Pro 16" PHPStorm между файлами переключается с маленькой, но раздражающей задержкой ... в чем может быть проблема?

Оказалась известная бага в JDK 11.0.7

https://youtrack.jetbrains.com/issue/WI-53673

workaround - откатить JDK на 11.0.6

могли бы и сами откатить в поставке, блин