omg linux

[wizzard]

а что случается в линухе если переименовать папку в которую тем временем копируется большой файл? я ее потом правда переименовал обратно, но все же, что происходит?

Comments

[gds.livejournal.com]

можно было и не переименовывать :) Если копирование в целом без фокусов (а, например, стиле "пишем в файл и закрываем его"), то юниксам пофиг, какой файловый дескриптор закрывают. Главное, что он связан с inode файла. Который, в свою очередь, находится в таблице, содержащей inode'ы других файлов директории, как и ссылку на inode родительской директории. А что её имя изменилось -- пофиг.

[wizzard]

ну, туда копировалось более одного файла :)

[lionet.livejournal.com]

Ничего особенного — поменялись несколько байт "имени файла" в записи каталога, которые ссылаются на один и тот же файл.

[nponeccop.livejournal.com]

Небольшое уточнение: inode - это деталь реализации древней файловой системы FFS, т.е. рассуждения о том, что рассуждения каких-то таблицах, содержащих inode, надо воспринимать с долей скептицизма, т.к. это undefined behaviour.

Стандарт IEEE Std 1003.1 определяет довольно мало.

[wizzard]

Ну, в принципе, да.

Let's think about sshfs, FUSE and other neat *nix things :)

[wizzard]

Я тут вспомнил про FUSE и прочие абстракции, которые могут лежать "под капотом". А что говорит про это POSIX, или эээ на каком уровне этот бихевиор работает?

[nponeccop.livejournal.com]

C точки зрения UNIX - это undefined behavior, т.е. в переносимом софте на это полагаться нельзя. Папка может как лочиться (как в винде), так и не лочиться (как в вашей ОС).

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

Правда, чем меньше лочит система - тем легче создавать inconsistencies в файловой системе и подводные камни в софте. Скажем, если разрешать удалять каталог с открытыми файлами так, что они остаются открытыми и удаляются только при закрытии, то получается, что операция close для файла, открытого только на чтение, модифицирует файловую систему. Т.е. инвариант операции close становится неочевидным.

Скажем, некоторая система может при переходе на резервное питание сделать fsync и запретить все операции записи, но забыть про то, что операция close является небезопасной даже для файлов, открытых на чтение. Т.е. если какой-то файл открыт на чтение, но не имеет ни одной записи в каталогах, и произойдет сбой, то при следующей загрузке файл будет недоступен, и надежная файловая система должна обладать средствами отлова таких потерянных фрагментов. А если вместо этого лочить - то и средства самовосстановления понадобятся попроще. Короче, не всё просто с этими блокировками (и вонючестью требований перезагрузки в винде).

[nponeccop.livejournal.com]

IEEE Std 1003.1, 2004 Edition ничего не говорит вроде

[nponeccop.livejournal.com]

Ну, тут не все ужасно - так, тот же IEEE Std 1003.1 требует от всех файловых систем реализации hard links и file serial number.

Стандарт лишь не оговаривает поведение ссылок при странных операциях вроде описанной.

[wizzard]

(общее впечатление от закапывания глубоко в любую технологию) как страшно жить :-D

а если серьезно, то таки да. с текущей сложностью систем software development is hard, разница лишь в глубине подводных камней.

и баги будут всегда, похоже.

[wizzard]

А, ну если есть хардлинки, тогда можно в определенном контексте считать их инодами.

[nponeccop.livejournal.com]

Конечно можно. Но из всего сообщения является стандартным только выделенное жирным, да и то с небольшой поправкой что не inode, а file serial number :) а всё остальное - это личные наблюдения автора за одной или двумя реализациями и стандартом не оговорено

---
можно было и не переименовывать :) Если копирование в целом без фокусов (а, например, стиле "пишем в файл и закрываем его"), то юниксам пофиг, какой файловый дескриптор закрывают. Главное, что он связан с inode файла. Который, в свою очередь, находится в таблице, содержащей inode'ы других файлов директории, как и ссылку на inode родительской директории. А что её имя изменилось -- пофиг.
---

[wizzard]

Ясно.

[nponeccop.livejournal.com]

> баги будут всегда, похоже

Ну, тут можно говорить о небольших улучшениях. Скажем, в Хаскеле ошибку при рефакторинге допустить сложнее, чем в JavaScript.

Дальнейший прогресс в уменьшении багов в софте - это либо сокращение размера кода (этим, скажем, Эрланг круче Перла, хоть оба динамически типизированы) либо кодирование большего количества инвариантов в типах.

Прогресс в последней области определяется прогрессом в математике. Сейчас формальные системы в математике неудобны даже для самих математиков, приходится сидеть и ждать прорыва.

[lionet.livejournal.com]

Это уровень ядра в современных юниксах. В первых юниксах команды типа mv открывали каталог [как файл] и писали туда самостоятельно, но потом быстро поняли, что это путь к разрушению, и убрали это на уровень ядра.