Есть две задачки: 1) определить запущен ли определенный файл 2) определить по PID имя файла (или линки) из которого запустился процесс. Код должен работать на любой OS в том числе и на Mac OS, т.е. без procfs. Единственное что я нашел это вытащить имя файла из стека(он там около аргументов лежит). Но, как я понимаю, некоторые процессы могут менять эту строку. И вообще я хотел бы иметь код на платформонезависимом языке (например Java).
Крутую задачу себе ты поставил, если учесть, что процесс может быть в любой ОС. Ведь всё будет зависеть от неё, у каждой системы свои способы хранения имени файла, из которого процесс запустился. Ещё не факт что эта информация будет доступна из стека или регистров, возможно, придётся вызывать специфические функции для этой ОС - тогда всё пропало.
Ну, давайте упростим задачу. Пускай у нас Mac OS. Больше всего меня удивляет, почему ни одна тулза не выдает такой инфы? Ведь не грузится веси исполняемы файл сразу в память. Ресурсы то надо знать откуда подкачивать.
NullSessi0n А я не думаю, что *никсы когда-нибудь откажутся от прототипа int main(int argc, char** argv). MYP Видимо, загрузчик (или интерпретатор) хранит где-то дескриптор открытого файла, но можно ли через дескриптор добраться до имени платформеннонезависимым образом?.. Думаю, что нельзя. Как на Java можно залезть в стек чужого процесса? Для подобных вещей, IMHO, Java совершенно не годится.
Quantum Речь шла не только о никсах (вначале). MYP Java создана для написания "безопасного кода", он и в своём то процессе не всё сделает, а в чужой и подавно не влезет. Вот в Windows можно простым перечислением процессов узнать такую инфу. Можно даже Task Manager на это настроить. А вот Mac OS нету, к сожалению.
Quantum не откажется. но, этот прототип не гарантирует что 1. программа не скажет strncpy (argv[0], "hey, its my name", strlen (argv[0])); 2. что ядро впишет в argv[0] вовсе не путь к исполняемому файлу. Напр. в linux, используя binfmt_misc можно настраивая на запуск тех же PE файлов и использованием wine, сказать что argv[0] == "/usr/bin/wine", а можно и имя приложения. MYP да потому, что ядро не хранит этой информации. Зачем, использовать для подкачки файл программы? Не знаю как виндовс выкручивается, но ... проблемы: - возможностью работы этого в chroot-environment, - другими изменениями в структуре vfs типа mount/umount, - обработкой попыток записи в файл или удаления файла - какой путь ставить программе восстановленной из core? И дизайнеры unix явно сочли эти проблемы достаточными для того чтобы забить на хранение связи между процессом и файлом из которого он запущен. В конце концов для подкачки можно выделить отдельный раздел (или несколько), и админу виднее какой жёсткий диск наиболее адекватен задаче подкачки для данной системы. суть в том, процесс и файл программы -- это две большие разницы. Код процесса собран из многих файлов -- исполняемых файлов, core-файлов, библиотек, в тч и явно подгруженных через dlopen. С каким из них ассоциировать? И даже из текстов скриптов: когда я запускаю my-script.sh, то argv[0] == "my-script.sh", и вовсе не /bin/bash который его интерпретирует. Более того придётся озираться на переменную окружения $PATH, чтобы выяснить где же собственно валяется файл my-script.sh. А переменную окружения можно изменить, как в родительском процессе, так и в дочернем. Короче, для *nix и C, могу предложить взглянуть на этот фак. А уж для java делай выводы сам.
а ещё вспомнил проблемы: символические ссылки в файловой системе. Если такая ссылка указывает на исполняемый файл, то при execl ("/path/to/symlink"), ядро загрузит файл на который указывает симлинк, а в argv[0] будет лежать "/path/to/symlink". а вот способ сменить argv[0], даже для `ps aux' покатит: #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { if (argc == 1) { execl (argv[0], "гыгыгы", "аргумент", 0); } else { printf ("хых, гляньте на мой argv[0]: `%s'\n", argv[0]); return 0; } }
Все проблемы понятны. Но в procfs есть же ссылка exe. И она же устанавливается из каких-то соображений. Понятно, что можно придумать кучу вариантов, в которых сложно сказать что такое “исполняемый файл”. Но procfs как-то решила этот вопрос. Вот, скажем так, хочется получить ту же инфу на “никс” OS без procfs.
кстати, насчёт симлинка exe: во freebsd, я его не нашёл. может потому что shell у меня chroot'нутый или просто админ спрятал, но ведь не нашёл...
