Чому можна перемістити запущену програму в Ubuntu?

Я щойно зрозумів, що в змозі перемістити запущену активну програму до іншого каталогу. На мій досвід, це не було можливо в MacO або Windows. Як це працює в Ubuntu?

Редагувати: Я думав, що це не можливо на Mac, але, мабуть, це можливо, як підтверджують коментарі. Можливо, це не можливо в Windows. Дякую за всі відповіді.

Дозвольте мені її розбити.

При запуску виконуваного файлу, послідовність системних викликів виконуються, в першу чергу , fork()і execve():

• fork()створює дочірній процес процесу виклику, який є (здебільшого) точною копією батьківського, обидва досі працюють однаковим виконуваним файлом (використовуючи сторінки пам'яті копіювати при записі, тому це ефективно). Він повертається двічі: у батьків він повертає дочірній ПІД. У дитини він повертає 0. Зазвичай дочірній процес викликає execve відразу:

• execve()приймає повний шлях до виконуваного файлу як аргумент і замінює процес виклику виконуваним файлом. У цей момент новостворений процес отримує власний віртуальний адресний простір, тобто віртуальну пам'ять, і виконання починається в точці входу (у стані, визначеному правилами платформи ABI для свіжих процесів).

У цей момент завантажувач ELF ядра відобразив текстові та сегменти даних виконуваного файлу в пам'ять, як ніби він використовував mmap()системний виклик (із спільним відображенням лише для читання та приватним читанням-записом). BSS також відображається як би з MAP_ANONYMOUS. (BTW, я ігнорую тут динамічне посилання для простоти: динамічний лінкер open()s і mmap()s всі динамічні бібліотеки перед переходом до точки входу головного виконуваного файлу.)

Лише кілька сторінок фактично завантажуються в пам'ять з диска до того, як нещодавно виконаний () ed почне запускати власний код. Подальші сторінки запитуються під час посилання , якщо / коли процес торкнеться тих частин свого віртуального адресного простору. (Попереднє завантаження будь-яких сторінок коду чи даних перед початком виконання коду простору користувача - це лише оптимізація продуктивності.)

Виконавчий файл ідентифікується за допомогою inode на нижньому рівні. Після того, як файл починає виконуватись, ядро ​​зберігає вміст файлу неушкодженим за посиланням inode, а не за ім'ям файлу, як для відкритих дескрипторів файлів або підтримуваних файлами відображень пам'яті. Таким чином, ви можете легко перемістити виконуваний файл в інше місце файлової системи або навіть в іншу файлову систему. В якості бічної примітки, щоб перевірити різні статистичні дані процесу, ви можете зазирнути до /proc/PIDкаталогу (PID - ідентифікатор процесу даного процесу). Ви навіть можете відкрити виконуваний файл як /proc/PID/exe, навіть він від’єднаний від диска.

Тепер давайте викопаємо рухоме:

При переміщенні файлу в одній і тій же файловій системі виконується системний виклик rename(), який просто перейменовує файл на інше ім'я, вкладення файлу залишається незмінним.

Тоді як між двома різними файловими системами трапляються дві речі:

• Вміст файлу в спочатку копіюються в нове місце, з допомогою read()іwrite()

• Після цього файл від’єднується від вихідного каталогу за допомогою unlink()та, очевидно, файл отримає новий вклад у новій файловій системі.

rmнасправді просто unlink()-наведений файл із дерева директорій, тож маючи дозвіл на запис у каталог, ви отримаєте достатнє право видалити будь-який файл із цього каталогу.

Тепер для розваги уявіть, що відбувається, коли ви переміщуєте файли між двома файлами файлів, і у вас немає дозволу на unlink()файл з джерела?

Ну, файл спочатку буде скопійовано до місця призначення ( read(), write()), а потім unlink()вийде з ладу через недостатній дозвіл. Отже, файл залишиться в обох файлових системах !!

Ну, це досить прямо. Візьмемо виконуваний файл з ім’ям / usr / local / bin / whoopdeedoo. Це лише посилання на так званий inode (основна структура файлів у Unix Filesystems). Це inode, який стає позначеним "у використанні".

Тепер, коли ви видаляєте або переміщаєте файл / usr / local / whoopdeedoo, єдине, що переміщується (або стирається) - посилання на inode. Сама індеда залишається незмінною. Це в основному все.

Я повинен це перевірити, але я вважаю, що ви можете це зробити і у файлових системах Mac OS X.

Windows застосовує інший підхід. Чому? Хто знає...? Я не знайомий із внутрішніми стандартами NTFS. Теоретично всі файлові системи, які використовують посилання на інтенальні структури для імен файлів, повинні це робити.

Зізнаюся, я надто спростив, але переходьте читати розділ "Наслідки" у Вікіпедії, який робить набагато кращу роботу, ніж я.

Одне, що здається відсутнім у всіх інших відповідях, це те, що: після відкриття файлу і програми містить дескриптор відкритого файлу, файл не буде видалений із системи, поки дескриптор цього файлу не буде закритий.

Спроба видалити посилання, що посилається, буде відкладено, поки файл не буде закрито: перейменування в одній або іншій файловій системі не може вплинути на відкритий файл незалежно від поведінки перейменування, а також явно видалити або перезаписати файл новим. Єдиний спосіб, коли ви можете зіпсувати файл, - це явно відкрити його inode та зіпсувати вміст, а не за допомогою операцій над каталогом, таким як перейменування / видалення файлу.

Більше того, коли ядро ​​виконує файл, воно зберігає посилання на виконуваний файл, і це знову запобіжить будь-якій модифікації його під час виконання.

Зрештою, навіть якщо це виглядає так, що ви можете видалити / перемістити файли, що складають запущену програму, фактично вміст цих файлів зберігається в пам'яті до завершення програми.

У файловій системі Linux, коли ви переміщуєте файл, доки він не перетинає межі файлової системи (читайте: залишається на одному диску / розділі), все, що ви змінюєте, - це вкладення ..(батьківський каталог) у нове місце . Фактичні дані зовсім не перемістилися на диску, а лише вказівник, щоб файлова система знала, де їх знайти.

Ось чому операції з переміщення є настільки швидкими і, ймовірно, чому немає проблеми з переміщенням запущеної програми, оскільки ви фактично не переміщуєте саму програму.

Це можливо, оскільки переміщення програми не впливає на запущені процеси, запущені її запуском.

Після запуску програми її бітові диски захищені від перезапису, але немає потреби захищати файл, який слід перейменовувати, переміщувати в інше місце в тій же файловій системі, що еквівалентно перейменуванню файлу або переміщенню до іншої файлової системи, що еквівалентно копіювати файл в іншому місці та видалити його.

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

Зауважте, що запуск програми не завантажує все одразу у (фізичну) пам'ять. Навпаки, завантажується лише суворий мінімум, необхідний для початку процесу. Потім потрібні сторінки завантажуються на вимогу протягом усього життя процесу. це називається пейджингом попиту. Якщо є дефіцит оперативної пам’яті, ОС може звільнити оперативну пам’ять, на якій розміщені ці сторінки, тому процес цілком може завантажувати кілька разів ту саму сторінку з виконуваного inode.

Причина, по якій це було неможливо в Windows, спочатку вірогідна через те, що базисна файлова система (FAT) не підтримує розділену концепцію записів каталогів проти inodes. Це обмеження більше не було в NTFS, але дизайн ОС зберігався тривалий час, що призводило до неприємного обмеження, яке доведеться перезавантажувати під час встановлення нової версії бінарного файлу, що більше не стосується останніх версій Windows.

В основному, в Unix та його ilk ім'я файлу (включаючи шлях до каталогу, що веде до нього) використовується для асоціації / пошуку файлу, коли його відкритті (виконання файлу - це один із способів його відкриття). Після цього моменту ідентифікація файлу (через його "inode") встановлюється і більше не ставиться під сумнів. Ви можете видалити файл, перейменувати його, змінити його дозволи. Поки будь-який процес або шлях до файлу має ручку для цього файлу / inode, він буде триматися навколо, як і труба між процесами (насправді, в історичному UNIX труба була безіменною inode розміром, який щойно вписався в "прямі блоки" посилання на зберігання диска в inode, щось на зразок 10 блоків).

Якщо у вашому PDF-файлі відкрито переглядач PDF, ви можете видалити цей файл і відкрити новий з тим же ім’ям, і поки старий переглядач відкритий, він все одно буде добре отримувати доступ до старого файлу (якщо він активно не дивиться файлова система, щоб помітити, коли файл зникає під початковим іменем).

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

Таким чином, шлях до файлу не є властивістю самого файлу (насправді, жорсткі посилання можуть передбачати декілька різних таких шляхів) і потрібен лише для його відкриття, а не для постійного доступу процесами, які вже відкрили його.