|DataDirectory|
не является файлом как таковым. Цитата из этой довольно старой статьи MSDN (подробнее читайте в полной статье):
По умолчанию переменная | DataDirectory | будет расширена как следуйте:
- Для приложений, размещенных в каталоге на пользовательском компьютере, это будет папка приложения (.exe).
- Для приложений, работающих под ClickOnce, это будет специальная папка данных, созданная ClickOnce.
- Для веб-приложений это будет папка App_Data.
. для | DataDirectory | просто происходит из свойства в домене приложения. Можно изменить это значение и переопределить поведение по умолчанию, выполнив следующее:
AppDomain.CurrentDomain.SetData("DataDirectory", newpath)
Еще одна цитата относительно несоответствий вашей схемы:
Одна из вещей знать при работе с локальными файлами базы данных, что они обрабатываются как любые другие файлы содержимого. Для настольных проектов это означает, что по умолчанию файл базы данных будет копироваться в выходную папку (он же bin) при каждой сборке проекта. После F5 вот как это будет выглядеть на диске
MyProject\Data.mdf MyProject\MyApp.vb MyProject\Bin\Debug\Data.mdf MyProject\Bin\Debug\MyApp.exe
Во время разработки MyProject \ Data.mdf используется инструментами данных. Во время выполнения приложение будет использовать базу данных в выходной папке. В результате копирования у многих создалось впечатление, что приложение не сохранило данные в файл базы данных. На самом деле это просто потому, что задействованы две копии файла данных. То же самое касается просмотра схемы / данных через проводник баз данных. Инструменты используют копию в проекте, а не ту, которая находится в папке bin.
Я использую команду strace
. Но он только сообщает, какие системные вызовы выполняет процесс. Хотя этого может быть достаточно ...
Можно привязать запущенный процесс к strace
во время выполнения.
Очевидно, gdb
также можно использовать.
Если вы хотите отслеживать системные вызовы, выполняемые процессом, попробуйте использовать strace .
какую информацию вы ищете? Псевдокаталоги в / proc / pid должны быть в значительной степени понятными. Это действительно зависит от того, что вы ищете.
Обычно ответом является strace на этот вопрос. Самый простой способ - запустить команду напрямую с помощью strace, например:
wichert@fog:~$ strace ls
execve("/bin/ls", ["ls"], [/* 16 vars */]) = 0
brk(0) = 0x9fa8000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f0a000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
Это не работает для уже запущенных процессов, таких как PHP. К счастью, вы также можете присоединить strace к существующему процессу с помощью параметра -p . Например:
wichert@fog:~$ strace -p 3761
Process 3761 attached - interrupt to quit
select(16, [5 7 8], NULL, [5 7 8], {0, 580000}) = 0 (Timeout)
alarm(0) = 62
rt_sigprocmask(SIG_BLOCK, [ALRM], [], 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, {0x809a270, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
Для демонов, которые порождают другие процессы, вам может потребоваться также параметр -f .
Помимо всегда полезного strace, вы также можете посмотреть ltrace . ltrace похож на strace, но показывает вызовы библиотеки вместо системных вызовов. Пример:
[one;~]-6> ltrace ls
__libc_start_main(0x804e5f0, 1, 0xbfdb7254, 0x8059a10, 0x8059a00 <unfinished ...>
setlocale(6, "") = "LC_CTYPE=en_GB.UTF-8;LC_NUMERIC="...
bindtextdomain("coreutils", "/usr/share/locale") = "/usr/share/locale"
textdomain("coreutils") = "coreutils"
__cxa_atexit(0x8051860, 0, 0, 0xb7f65ff4, 0xbfdb71b8) = 0
isatty(1) = 1
getenv("QUOTING_STYLE") = NULL
Обратите внимание, что вы также увидите изрядное количество внутренних вызовов libc, поэтому вывод может быть более подробным, чем вы ожидаете.