Почему возможно переместить под управлением программу в Ubuntu?
Я просто понял, что могу переместить под управлением активную программу в другой каталог. По моему опыту, это не было возможно в MacOs или Windows. Как это работает в Ubuntu?
Править: Я думал, что это не было возможно на Mac, но по-видимому это возможно, поскольку комментарии проверяют. Это только не возможно в Windows, возможно. Спасибо за все ответы.
6 ответов
Позвольте мне сломать его.
Когда Вы выполняете исполняемый файл, последовательность системных вызовов выполняются, прежде всего fork() и execve():
fork()создает дочерний процесс обработки вызовов, которая является (главным образом) точной копией родителя, оба все еще выполнение того же исполняемого файла (использование страниц памяти копии на записи, таким образом, это эффективно). Это возвращается дважды: В родителе это возвращает дочерний PID. В ребенке это возвращается 0. Обычно, дочерний процесс называет execve сразу же:execve()берет полный путь к исполняемому файлу как аргумент и заменяет обработку вызовов исполняемым файлом. В этой точке недавно созданный процесс получает свое собственное виртуальное адресное пространство т.е. виртуальную память, и выполнение начинается в его точке входа (в состоянии, указанном правилами ABI платформы для новых процессов).
На данном этапе загрузчик ELF ядра отобразил сегменты текста и сегменты данных исполняемого файла в память, как будто это использовало mmap() системный вызов (с общими и частными отображениями чтения-записи только для чтения соответственно). BSS также отображается как будто с MAP_ANONYMOUS. (BTW, я игнорирую динамическое подключение здесь для простоты: динамический компоновщик open()s и mmap()s все динамические библиотеки прежде, чем перейти к точке входа основного исполняемого файла.)
Только несколько страниц на самом деле загружаются в память из диска перед недавно-должностным-лицом (), редактор начинает выполнять его собственный код. Дальнейшие страницы являются спросом, разбитым на страницы в по мере необходимости, если/когда процесс касается тех частей своего виртуального адресного пространства. (Предварительно загружающий любые страницы кода или данных прежде, чем начать выполнять код пространства пользователя просто оптимизация производительности.)
Исполняемый файл определяется inode на более низком уровне. После того, как файл начал выполняться, ядро сохраняет содержание файла в целости inode ссылкой, не именем файла, как для открытых дескрипторов файлов или поддержанных файлом размещений в ОЗУ. Таким образом, можно легко переместить исполняемый файл в другое местоположение файловой системы или даже в другой файловой системе. Как примечание стороны, для проверки различной статистики процесса можно посмотреть в /proc/PID (PID является идентификатором Процесса данного процесса), каталог. Можно даже открыть исполняемый файл как /proc/PID/exe, даже это было несвязанным с диском.
Теперь давайте копнем перемещение:
При перемещении файла в той же файловой системе системный вызов, который выполняется, rename(), который просто переименовывает файл к другому имени, inode файла остаются тем же.
Принимая во внимание, что между двумя различными файловыми системами, две вещи происходят:
Содержание файла в скопированном сначала в новое местоположение,
read()иwrite()После этого файл является несвязанным с исходным использованием каталога
unlink()и очевидно файл получит новый inode в новой файловой системе.
rm на самом деле справедливо unlink()- луг данный файл от дерева каталогов, также - разрешение записи на каталоге получит Вас достаточное право удалить любой файл из того каталога.
Теперь для забавы, вообразите то, что происходит, когда Вы перемещаете файлы между двумя файловыми системами, и у Вас нет разрешения к unlink() файл из источника?
Ну, файл будет скопирован в место назначения сначала (read(), write()) и затем unlink() перестанет работать из-за недостаточного разрешения. Так, файл останется в обеих файловых системах!!
Ну, это довольно просто. Давайте возьмем исполняемый файл, названный/usr/local/bin/whoopdeedoo. Это - только ссылка на так называемый inode (базовая структура файлов в Файловых системах Unix). Это - inode, который отмечен "используемый".
Теперь, когда Вы удаляете или перемещаете файл/usr/local/whoopdeedoo, единственной вещью, которая перемещена (или вытерта), является ссылка на inode. Сам inode остается неизменным. Это - в основном это.
я должен проверить его, но я полагаю, что можно сделать это в файловых системах Mac OS X также.
Windows проявляет другой подход. Почему? Кто знает...? Я не знаком с внутренностями NTFS. Теоретически, все файловые системы, которые используют ссылки на intenal структуры для filesnames, должны смочь сделать это.
я признаю, я чрезмерно упростил, но пойдите, читает раздел "Implications" по Википедии, которая делает намного лучшее задание, чем я.
Одна вещь, которая кажется пропавшими без вести из всех других ответов, состоит в том что: , после того как файл открыт, и программа содержит открытый дескриптор файла, файл будет не быть удаленным из системы, пока тот дескриптор файла не будет закрыт.
Попытки удалить inode, на который ссылаются, будут задержаны, пока файл не закрывается: переименование в той же или другой файловой системе не может влиять на открытый файл, независимо от поведения переименовывания, ни явно удаления или перезаписи файла с новым. Единственный путь, которым можно испортить файл, путем явного открытия его inode и путаницы с содержанием, не операциями на каталоге, такими как переименование/удаление файла.
, Кроме того, когда ядро выполняет файл, это сохраняет ссылку на исполняемый файл, и это снова предотвратит любую модификацию его во время выполнения.
Так в конце, даже если это похоже , что Вы можете удалить/переместить файлы, которые составляют под управлением программу, на самом деле содержание тех файлов сохранено в памяти, пока программа не заканчивается.
В файловой системе Linux, когда Вы перемещаете файл, пока это не пересекает границы файловой системы (чтение: остается на том же диске/разделе), все, что Вы изменяете, inode .. (родительский каталог) к тому из нового местоположения. Фактические данные не переместились вообще в диск, просто указатель так, чтобы файловая система знала, где найти его.
Поэтому операции пересылки так быстры и вероятны, почему нет никакой проблемы, перемещающей под управлением программу, поскольку Вы на самом деле не перемещаете саму программу.
Это возможно, потому что перемещение программы не влияет на рабочие процессы, запущенные путем запуска его.
, После того как программа запускается, ее дисковые биты защищены от того, чтобы быть перезаписанным, но нет никакой потребности защитить файл, который будет переименован, перемещен в другое местоположение в той же файловой системе, которая эквивалентна для переименования файла, или перемещенный в другую файловую систему, которая эквивалентна для копирования файла в другом месте, затем удаляют его.
Удаление файла, который используется, или потому что процесс имеет дескриптор файла, открытый на нем, или потому что процесс выполняет его, не удаляет данные файла, которые остаются ссылаемыми файлом inode, но только удаляют запись каталога, т.е. путь, от которого может быть достигнут inode.
Примечание, что запуск программы не загружает все сразу в (физической) памяти. На противоположном только загружается строгий минимум, необходимый, чтобы процесс запустился. Затем требуемые страницы загружаются по требованию во время целой жизни процесса. это называют подкачкой по обращению. Если существует нехватка RAM, ОС свободна выпустить RAM, содержащую эти страницы, таким образом, для процесса хорошо возможно загрузить многократно ту же самую страницу из исполняемого файла inode.
причина, почему это не было возможно с Windows, первоначально, вероятно, происходит из-за того, что базовая файловая система (FAT) не поддерживала понятие разделения записей каталога по сравнению с inodes. Это ограничение, больше не было не дарят NTFS, но дизайн ОС сохранялся в течение долгого времени, ведя к неприятному ограничению для перезагрузки при установке новой версии двоичного файла, который больше не является случаем с последними версиями Windows.
В основном, в Unix и его роде, имя файла (включая продвижение пути к каталогу к нему) используется для соединения/открытия файла, когда открытие это (выполнение файла является одним способом открыть его способом). После того момента идентификационные данные файла (через его "inode") устанавливаются и больше не подвергаются сомнению. Можно удалить файл, переименовать его, изменить его полномочия. Пока любой процесс или путь к файлу имеют дескриптор на этом file/inode, он будет слоняться поблизости, точно так же, как канал между процессами делает (на самом деле, в историческом UNIX канал был неназванный inode с размером, который просто поместился в "прямые блоки" ссылка памяти на диске в inode, чем-то как 10 блоков).
, Если у Вас есть средство просмотра PDF, открывают на файле PDF, можно удалить тот файл и открыть новый с тем же именем, и, пока старое средство просмотра открыто, это все еще будет прекрасный доступ к старому файлу (если это активно не будет наблюдать файловую систему для замечания, когда файл исчезает под своим настоящим именем).
Программы, бывшие нужные во временных файлах, могут просто открыть такой файл под некоторым именем, и затем сразу удаляют его (или скорее его запись каталога), в то время как это все еще открыто. Впоследствии файл больше не доступен по имени, но любые процессы, имеющие открытый дескриптор файла в файл, могут все еще получить доступ к нему, и если будет неожиданный выход программы впоследствии, то файл будет удален, и устройство хранения данных исправлено автоматически.
, Таким образом, путь к файлу не является свойством самого файла (на самом деле, жесткие ссылки могут обеспечить несколько отличающиеся такие пути), и необходим только для открытия его, не для длительного доступа процессами, уже имеющими его открытый.