@buckbeak ебать ты тупой, а ещё линуксоидом зовёшься // отделение inode файла от его имени в директории (+ reference counting иноды (откуда также появляются хардлинки), в том числе по открытым хендлам на иноду в юзерских процессах) — один из важнейших майлстоунов развития ОС; в шиндошс, естественно, эту идею капитально проебланили — именно из-за чего, в частности, шіндовс приходится постоянно ребутить после установок/апдейтов (потому что какую-нибудь широко используемую либу [типа libc.so, или libz.so, libpng.so, msvcrt, etc etc etc] невозможно заменить новой пока её использует хоть один процесс (а такой всегда находится), хотя в неуёбищных ОС апдейт такой либы тривиален: нужно просто положить новую so-шку в новую иноду + флипнуть на неё указатель по имени из содержащей директории — все последующие лукапы по файлнейму будут возвращать новую иноду, а старая будет жить с ненулевым счётчиком ссылок до тех пор пока все использовавшие её процессы не завершатся и не закроют свои хендлы на неё).
@buckbeak ебать ты тупой, а ещё линуксоидом зовёшься // отделение inode файла от его имени в директории (+ reference counting иноды (откуда также появляются хардлинки), в том числе по открытым хендлам на иноду в юзерских процессах) — один из важнейших майлстоунов развития ОС; в шиндошс, естественно, эту идею капитально проебланили — именно из-за чего, в частности, шіндовс приходится постоянно ребутить после установок/апдейтов (потому что какую-нибудь широко используемую либу [типа libc.so, или libz.so, libpng.so, msvcrt, etc etc etc] невозможно заменить новой пока её использует хоть один процесс (а такой всегда находится), хотя в неуёбищных ОС апдейт такой либы тривиален: нужно просто положить новую so-шку в новую иноду + флипнуть на неё указатель по имени из содержащей директории — все последующие лукапы по файлнейму будут возвращать новую иноду, а старая будет жить с ненулевым счётчиком ссылок до тех пор пока все использовавшие её процессы не завершатся и не закроют свои хендлы на неё).