а что случается в линухе если переименовать папку в которую тем временем копируется большой файл? я ее потом правда переименовал обратно, но все же, что происходит?
можно было и не переименовывать :) Если копирование в целом без фокусов (а, например, стиле "пишем в файл и закрываем его"), то юниксам пофиг, какой файловый дескриптор закрывают. Главное, что он связан с inode файла. Который, в свою очередь, находится в таблице, содержащей inode'ы других файлов директории, как и ссылку на inode родительской директории. А что её имя изменилось -- пофиг.
Небольшое уточнение: inode - это деталь реализации древней файловой системы FFS, т.е. рассуждения о том, что рассуждения каких-то таблицах, содержащих inode, надо воспринимать с долей скептицизма, т.к. это undefined behaviour.
Стандарт IEEE Std 1003.1 определяет довольно мало.
Конечно можно. Но из всего сообщения является стандартным только выделенное жирным, да и то с небольшой поправкой что не inode, а file serial number :) а всё остальное - это личные наблюдения автора за одной или двумя реализациями и стандартом не оговорено
--- можно было и не переименовывать :) Если копирование в целом без фокусов (а, например, стиле "пишем в файл и закрываем его"), то юниксам пофиг, какой файловый дескриптор закрывают. Главное, что он связан с inode файла. Который, в свою очередь, находится в таблице, содержащей inode'ы других файлов директории, как и ссылку на inode родительской директории. А что её имя изменилось -- пофиг. ---
Я тут вспомнил про FUSE и прочие абстракции, которые могут лежать "под капотом". А что говорит про это POSIX, или эээ на каком уровне этот бихевиор работает?
Это уровень ядра в современных юниксах. В первых юниксах команды типа mv открывали каталог [как файл] и писали туда самостоятельно, но потом быстро поняли, что это путь к разрушению, и убрали это на уровень ядра.
C точки зрения UNIX - это undefined behavior, т.е. в переносимом софте на это полагаться нельзя. Папка может как лочиться (как в винде), так и не лочиться (как в вашей ОС).
В принципе, физические структуры в файловой системе, отвечающие за хранение данных файла, и структуры, отвечающие за хранение directory entry файла, почти всегда не пересекаются, т.е. возможно поддерживать даже операции над анонимными файлами.
Правда, чем меньше лочит система - тем легче создавать inconsistencies в файловой системе и подводные камни в софте. Скажем, если разрешать удалять каталог с открытыми файлами так, что они остаются открытыми и удаляются только при закрытии, то получается, что операция close для файла, открытого только на чтение, модифицирует файловую систему. Т.е. инвариант операции close становится неочевидным.
Скажем, некоторая система может при переходе на резервное питание сделать fsync и запретить все операции записи, но забыть про то, что операция close является небезопасной даже для файлов, открытых на чтение. Т.е. если какой-то файл открыт на чтение, но не имеет ни одной записи в каталогах, и произойдет сбой, то при следующей загрузке файл будет недоступен, и надежная файловая система должна обладать средствами отлова таких потерянных фрагментов. А если вместо этого лочить - то и средства самовосстановления понадобятся попроще. Короче, не всё просто с этими блокировками (и вонючестью требований перезагрузки в винде).
Ну, тут можно говорить о небольших улучшениях. Скажем, в Хаскеле ошибку при рефакторинге допустить сложнее, чем в JavaScript.
Дальнейший прогресс в уменьшении багов в софте - это либо сокращение размера кода (этим, скажем, Эрланг круче Перла, хоть оба динамически типизированы) либо кодирование большего количества инвариантов в типах.
Прогресс в последней области определяется прогрессом в математике. Сейчас формальные системы в математике неудобны даже для самих математиков, приходится сидеть и ждать прорыва.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2009-09-12 11:32 am (UTC)no subject
Date: 2009-09-12 11:35 am (UTC)no subject
Date: 2009-09-14 06:19 am (UTC)Стандарт IEEE Std 1003.1 определяет довольно мало.
no subject
Date: 2009-09-14 06:22 am (UTC)Let's think about sshfs, FUSE and other neat *nix things :)
no subject
Date: 2009-09-14 06:50 am (UTC)Стандарт лишь не оговаривает поведение ссылок при странных операциях вроде описанной.
no subject
Date: 2009-09-14 06:51 am (UTC)no subject
Date: 2009-09-14 07:00 am (UTC)---
можно было и не переименовывать :) Если копирование в целом без фокусов (а, например, стиле "пишем в файл и закрываем его"), то юниксам пофиг, какой файловый дескриптор закрывают. Главное, что он связан с inode файла. Который, в свою очередь, находится в таблице, содержащей inode'ы других файлов директории, как и ссылку на inode родительской директории. А что её имя изменилось -- пофиг.
---
no subject
Date: 2009-09-14 07:02 am (UTC)no subject
Date: 2009-09-12 11:53 am (UTC)no subject
Date: 2009-09-14 06:23 am (UTC)no subject
Date: 2009-09-14 06:46 am (UTC)no subject
Date: 2009-09-14 08:12 am (UTC)no subject
Date: 2009-09-14 06:44 am (UTC)В принципе, физические структуры в файловой системе, отвечающие за хранение данных файла, и структуры, отвечающие за хранение directory entry файла, почти всегда не пересекаются, т.е. возможно поддерживать даже операции над анонимными файлами.
Правда, чем меньше лочит система - тем легче создавать inconsistencies в файловой системе и подводные камни в софте. Скажем, если разрешать удалять каталог с открытыми файлами так, что они остаются открытыми и удаляются только при закрытии, то получается, что операция close для файла, открытого только на чтение, модифицирует файловую систему. Т.е. инвариант операции close становится неочевидным.
Скажем, некоторая система может при переходе на резервное питание сделать fsync и запретить все операции записи, но забыть про то, что операция close является небезопасной даже для файлов, открытых на чтение. Т.е. если какой-то файл открыт на чтение, но не имеет ни одной записи в каталогах, и произойдет сбой, то при следующей загрузке файл будет недоступен, и надежная файловая система должна обладать средствами отлова таких потерянных фрагментов. А если вместо этого лочить - то и средства самовосстановления понадобятся попроще. Короче, не всё просто с этими блокировками (и вонючестью требований перезагрузки в винде).
no subject
Date: 2009-09-14 06:50 am (UTC)а если серьезно, то таки да. с текущей сложностью систем software development is hard, разница лишь в глубине подводных камней.
и баги будут всегда, похоже.
no subject
Date: 2009-09-14 07:06 am (UTC)Ну, тут можно говорить о небольших улучшениях. Скажем, в Хаскеле ошибку при рефакторинге допустить сложнее, чем в JavaScript.
Дальнейший прогресс в уменьшении багов в софте - это либо сокращение размера кода (этим, скажем, Эрланг круче Перла, хоть оба динамически типизированы) либо кодирование большего количества инвариантов в типах.
Прогресс в последней области определяется прогрессом в математике. Сейчас формальные системы в математике неудобны даже для самих математиков, приходится сидеть и ждать прорыва.