Какая из следующих записей может быть именем файла

Обновлено: 21.11.2024

Нижеследующее содержит инструкции и подробные сведения об учебном семинаре LDM для конкретного семинара.

Создайте учетную запись пользователя LDM

Учетная запись пользователя LDM уже должна существовать на вашей рабочей станции.

Убедитесь, что TCP-соединения могут быть установлены

Это уже должно было быть сделано.

Стать пользователем LDM в домашнем каталоге пользователя

Если вы стали пользователем root, выполнив команду su от имени пользователя LDM в окне терминала, просто выполните команду exit в окне терминала; в противном случае выйдите из системы и войдите в систему как пользователь LDM.

Редактировать файл профиля пользователя LDM

Это уже должно было быть сделано. Вы можете проверить это с помощью команды

Сборка и установка дистрибутива

Если bash(1) является вашей пользовательской оболочкой (которая используется по умолчанию), сделайте следующее: В противном случае сделайте то же самое, что и выше, для вашей пользовательской оболочки.

Проверить реестр LDM

Значения по умолчанию подходят.

Средние показатели для различных типов фидов см., например, на веб-странице со сводкой объема данных для компьютера в UPC.

Запрос авторизации на вышестоящем LDM

Добавьте следующую запись в файл $HOME/etc/ldmd.conf, чтобы разрешить всем LDM мастерской получать данные из любого LDM мастерской:

Отредактируйте файл конфигурации LDM, `etc/ldmd.conf`

Запись "EXEC pqact" уже должна быть включена, чтобы разрешить локальную обработку полученных продуктов данных.

Добавьте следующие записи в файл конфигурации LDM, ldmd.conf, чтобы запрашивать каналы данных IDS|DDPLUS и NEXRAD3 от LDM инструктора:

Отредактируйте файл конфигурации `pqact`, `etc/pqact.conf`

Убедитесь, что следующая запись является единственной активной: Не забудьте начинать строки продолжения с символа табуляции!

Эта запись будет хранить продукты данных фида типа IDS|DDPLUS в соответствующей иерархии каталогов с каноническим временем продукта данных в качестве имени файла.

Отредактируйте файл конфигурации `scour`, `etc/scour.conf`

Добавьте следующую строку в файл конфигурации scour(1), etc/scour.conf : Это удалит все файлы в иерархии каталогов данных, которые старше одного дня.

Редактировать файл `crontab(1)` пользователя LDM

Добавьте следующие строки с помощью команды "crontab -e":

Убедитесь, что LDM запускается во время загрузки

В этом семинаре нас не беспокоит перезапуск LDM во время загрузки. Поэтому мы пропустим этот шаг.

Все файловые системы, поддерживаемые Windows, используют концепцию файлов и каталогов для доступа к данным, хранящимся на диске или устройстве. Разработчики Windows, работающие с Windows API для ввода-вывода файлов и устройств, должны понимать различные правила, соглашения и ограничения имен файлов и каталогов.

Доступ к данным можно получить с дисков, устройств и общих сетевых ресурсов с помощью API файлового ввода-вывода. Файлы и каталоги, наряду с пространствами имен, являются частью концепции пути, который представляет собой строковое представление того, где можно получить данные, независимо от того, получены ли они с диска, устройства или сетевого подключения для конкретной операции.

Некоторые файловые системы, такие как NTFS, поддерживают связанные файлы и каталоги, которые также следуют соглашениям и правилам именования файлов, как и обычные файлы или каталоги. Дополнительные сведения см. в разделах «Жесткие ссылки и соединения» и «Точки повторной обработки и операции с файлами».

Дополнительную информацию см. в следующих подразделах:

Чтобы узнать, как настроить Windows 10 для поддержки длинных путей к файлам, см. статью Ограничение максимальной длины пути.

Имена файлов и каталогов

Все файловые системы следуют одним и тем же общим соглашениям об именах для отдельных файлов: базовое имя файла и необязательное расширение, разделенные точкой. Однако каждая файловая система, такая как NTFS, CDFS, exFAT, UDFS, FAT и FAT32, может иметь определенные и отличающиеся правила формирования отдельных компонентов пути к каталогу или файлу. Обратите внимание, что каталог — это просто файл со специальным атрибутом, определяющим его как каталог, но в остальном он должен соответствовать тем же правилам именования, что и обычный файл. Поскольку термин каталог просто относится к особому типу файла в том, что касается файловой системы, в некоторых справочных материалах используется общий термин файл для охвата обеих концепций каталогов. и файлы данных как таковые. По этой причине, если не указано иное, любые правила или примеры именования или использования файла также должны применяться к каталогу. Термин путь относится к одному или нескольким каталогам, обратной косой черте и, возможно, имени тома. Дополнительные сведения см. в разделе «Пути».

Ограничения по количеству символов также могут различаться в зависимости от файловой системы и используемого формата префикса имени пути.Это еще более усложняется поддержкой механизмов обратной совместимости. Например, более старая файловая система MS-DOS FAT поддерживает не более 8 символов для основного имени файла и 3 символа для расширения, всего 12 символов, включая разделитель точек. Это обычно известно как имя файла 8.3. Файловые системы Windows FAT и NTFS не ограничены именами файлов версии 8.3, поскольку они имеют поддержку длинных имен файлов, но они по-прежнему поддерживают версию 8.3 длинных имен файлов.

Соглашения об именах

Следующие основные правила позволяют приложениям создавать и обрабатывать допустимые имена для файлов и каталогов независимо от файловой системы:

Используйте точку, чтобы отделить базовое имя файла от расширения в имени каталога или файла.

Используйте обратную косую черту (\) для разделения компонентов пути. Обратная косая черта отделяет имя файла от пути к нему и одно имя каталога от другого имени каталога в пути. Вы не можете использовать обратную косую черту в имени фактического файла или каталога, потому что это зарезервированный символ, который разделяет имена на компоненты.

При необходимости используйте обратную косую черту в имени тома, например, "C:\" в "C:\path\file" или "\\server\share" в "\\server\share\path". \file" для имен универсального соглашения об именах (UNC). Дополнительные сведения об именах UNC см. в разделе «Ограничение максимальной длины пути».

Не предполагайте чувствительность к регистру. Например, считайте имена OSCAR, Oscar и oscar одинаковыми, хотя некоторые файловые системы (например, POSIX-совместимая файловая система) могут считать их разными. Обратите внимание, что NTFS поддерживает семантику POSIX для учета регистра, но это не поведение по умолчанию. Дополнительные сведения см. в разделе CreateFile.

Обозначения томов (буквы дисков) также нечувствительны к регистру. Например, "D:\" и "d:\" относятся к одному и тому же тому.

Используйте любой символ текущей кодовой страницы для имени, включая символы Unicode и символы расширенного набора символов (128–255), за исключением следующих:

Следующие зарезервированные символы:

(больше)
: (двоеточие)
" (двойные кавычки)
/ (косая черта)
\ (обратная косая черта)
| (вертикальная полоса или труба)
* (звездочка)

Целое значение, равное нулю, иногда называемое символом NUL ASCII.

Символы, целочисленные представления которых находятся в диапазоне от 1 до 31, за исключением альтернативных потоков данных, где эти символы разрешены. Дополнительные сведения о файловых потоках см. в разделе Файловые потоки.

Любой другой символ, который не разрешен целевой файловой системой.

Используйте точку в качестве компонента каталога в пути для представления текущего каталога, например ".\temp.txt". Дополнительные сведения см. в разделе Пути.

Используйте две последовательные точки (..) в качестве компонента каталога в пути для представления родительского каталога текущего каталога, например "..\temp.txt". Дополнительные сведения см. в разделе Пути.

Не используйте следующие зарезервированные имена для имени файла:

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8 и LPT9. Также избегайте этих имен, за которыми сразу следует расширение; например, NUL.txt не рекомендуется. Дополнительные сведения см. в разделе Пространства имен.

Не заканчивайте имя файла или каталога пробелом или точкой. Хотя базовая файловая система может поддерживать такие имена, оболочка Windows и пользовательский интерфейс этого не делают. Однако допустимо указывать точку в качестве первого символа имени. Например, ".temp".

Короткие и длинные имена

Длинным именем файла считается любое имя файла, которое выходит за рамки короткого стиля именования MS-DOS (также называемого 8.3). Когда вы создаете длинное имя файла, Windows также может создать короткую форму имени 8.3, называемую псевдонимом 8.3 или коротким именем, и также сохранить ее на диске. Этот псевдоним 8.3 можно отключить по соображениям производительности либо для всей системы, либо для указанного тома, в зависимости от конкретной файловой системы.

Windows Server 2008, Windows Vista, Windows Server 2003 и Windows XP: псевдонимы 8.3 нельзя отключить для указанных томов до Windows 7 и Windows Server 2008 R2.

Во многих файловых системах имя файла будет содержать тильду (~) в каждом компоненте имени, которое слишком длинно для соответствия правилам именования 8.3.

Не все файловые системы следуют соглашению о замене тильды, и системы можно настроить таким образом, чтобы отключить создание псевдонима 8.3, даже если они обычно его поддерживают. Поэтому не думайте, что псевдоним 8.3 уже существует на диске.

Чтобы запросить имена файлов формата 8.3, длинные имена файлов или полный путь к файлу из системы, рассмотрите следующие варианты:

Чтобы получить 8.3 из длинного имени файла используйте функцию GetShortPathName.
Чтобы получить версию короткого имени с длинным именем файла, используйте функцию GetLongPathName.
Чтобы получить полный путь к файлу, используйте функцию GetFullPathName.

В более новых файловых системах, таких как NTFS, exFAT, UDFS и FAT32, Windows сохраняет длинные имена файлов на диске в кодировке Юникод, что означает, что исходное длинное имя файла всегда сохраняется. Это верно, даже если длинное имя файла содержит расширенные символы, независимо от кодовой страницы, которая активна во время операции чтения или записи с диска.

Файлы с длинными именами файлов можно копировать между разделами файловой системы NTFS и разделами файловой системы Windows FAT без потери информации об именах файлов. Это может быть не так для более старых файловых систем MS-DOS FAT и некоторых типов файловых систем CDFS (CD-ROM), в зависимости от фактического имени файла. В этом случае по возможности заменяется короткое имя файла.

Пути

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

Если компонент пути является именем файла, он должен быть последним компонентом.

Каждый компонент пути также будет ограничен максимальной длиной, указанной для конкретной файловой системы. В целом, эти правила делятся на две категории: короткие и длинные. Обратите внимание, что имена каталогов хранятся в файловой системе как файлы особого типа, но правила именования файлов также применяются к именам каталогов. Подводя итог, можно сказать, что путь — это просто строковое представление иерархии между всеми каталогами, существующими для определенного файла или имени каталога.

Полный и относительный пути

Для функций Windows API, управляющих файлами, имена файлов часто могут указываться относительно текущего каталога, а для некоторых API требуется полный путь. Имя файла относится к текущему каталогу, если оно не начинается с одного из следующих символов:

Имя UNC любого формата, которое всегда начинается с двух символов обратной косой черты ("\\"). Дополнительные сведения см. в следующем разделе.
Обозначение диска с обратной косой чертой, например "C:\" или "d:\".
Одна обратная косая черта, например, "\directory" или "\file.txt". Его также называют абсолютным путем.

Если имя файла начинается только с обозначения диска, но не с обратной косой черты после двоеточия, оно интерпретируется как относительный путь к текущему каталогу на диске с указанной буквой. Обратите внимание, что текущий каталог может быть или не быть корневым каталогом в зависимости от того, что он был установлен во время самой последней операции «изменить каталог» на этом диске. Ниже приведены примеры этого формата:

«C:tmp.txt» относится к файлу с именем «tmp.txt» в текущем каталоге на диске C.
"C:tempdir\tmp.txt" относится к файлу в подкаталоге текущего каталога на диске C.

Путь также считается относительным, если он содержит "двойные точки"; то есть два периода вместе в одном компоненте пути. Этот специальный спецификатор используется для обозначения каталога над текущим каталогом, также известного как «родительский каталог». Ниже приведены примеры этого формата:

"..\tmp.txt" указывает файл с именем tmp.txt, расположенный в родительском каталоге текущего каталога.
"..\..\tmp.txt" указывает файл, который находится на два каталога выше текущего каталога.
"..\tempdir\tmp.txt" указывает файл с именем tmp.txt, расположенный в каталоге с именем tempdir, который является равноправным каталогом для текущего каталога.

Относительные пути могут сочетать оба типа примеров, например "C.\tmp.txt". Это полезно, потому что, хотя система отслеживает текущий диск вместе с текущим каталогом этого диска, она также отслеживает текущие каталоги в каждой из разных букв диска (если в вашей системе их несколько), независимо от какое обозначение диска установлено в качестве текущего диска.

Ограничение максимальной длины пути

В выпусках Windows до Windows 10 версии 1607 максимальная длина пути — MAX_PATH, которая определяется как 260 символов. В более поздних версиях Windows для снятия ограничения требуется изменение раздела реестра или использование инструмента групповой политики. Полную информацию см. в разделе Ограничение максимальной длины пути.

Пространства имен

Существует две основные категории соглашений о пространствах имен, используемых в Windows API, обычно называемых пространствами имен NT и пространствами имен Win32.Пространство имен NT было разработано как пространство имен самого низкого уровня, в котором могут существовать другие подсистемы и пространства имен, включая подсистему Win32 и, соответственно, пространства имен Win32. POSIX — еще один пример подсистемы Windows, созданной поверх пространства имен NT. Ранние версии Windows также определяли несколько предопределенных или зарезервированных имен для определенных специальных устройств, таких как коммуникационные (последовательные и параллельные) порты и консоль дисплея по умолчанию, как часть того, что сейчас называется пространством имен устройств NT, и все еще поддерживаются в текущих версиях. Windows для обратной совместимости.

Пространства имен файлов Win32

В этом и следующем разделах кратко изложены префиксы и соглашения пространства имен Win32 с описанием их использования. Обратите внимание, что эти примеры предназначены для использования с функциями Windows API, и не все они обязательно работают с приложениями оболочки Windows, такими как проводник Windows. По этой причине существует более широкий диапазон возможных путей, чем обычно доступно из приложений оболочки Windows, и приложения Windows, которые используют это преимущество, могут быть разработаны с использованием этих соглашений о пространстве имен.

При файловом вводе-выводе префикс "\\?\" к строке пути указывает API Windows отключить всю строку синтаксического анализа и отправить строку, следующую за ней, прямо в файловую систему. Например, если файловая система поддерживает большие пути и имена файлов, вы можете превысить ограничения MAX_PATH, которые в противном случае применяются API-интерфейсами Windows. Дополнительные сведения об обычном ограничении максимального пути см. в предыдущем разделе Ограничение максимальной длины пути.

Поскольку он отключает автоматическое расширение строки пути, префикс "\\?\" также позволяет использовать ".." и "." в именах путей, что может быть полезно, если вы пытаетесь выполнить операции с файлом с этими в противном случае зарезервированными спецификаторами относительного пути как части полного пути.

Многие, но не все API файлового ввода/вывода поддерживают "\\?\"; вы должны посмотреть справочную тему для каждого API, чтобы быть уверенным.

Обратите внимание, что API Unicode следует использовать, чтобы убедиться, что префикс "\\?\" позволяет превысить MAX_PATH

Пространства имен устройств Win32

Префикс "\\.\" обеспечивает доступ к пространству имен устройств Win32 вместо пространства имен файлов Win32. Так осуществляется доступ к физическим дискам и томам напрямую, минуя файловую систему, если API поддерживает такой тип доступа. Таким образом вы можете получить доступ ко многим устройствам, кроме дисков (например, с помощью функций CreateFile и DefineDosDevice).

Например, если вы хотите открыть последовательный порт 1 системы, вы можете использовать "COM1" в вызове функции CreateFile. Это работает, потому что COM1–COM9 являются частью зарезервированных имен в пространстве имен NT, хотя использование префикса «\\.\» также будет работать с этими именами устройств. Для сравнения, если у вас установлена плата последовательного расширения на 100 портов и вы хотите открыть COM56, вы не сможете открыть ее с помощью «COM56», поскольку для COM56 нет предопределенного пространства имен NT. Вам нужно будет открыть его с помощью "\\.\COM56", потому что "\\.\" переходит непосредственно к пространству имен устройства, не пытаясь найти предопределенный псевдоним.

Другим примером использования пространства имен устройств Win32 является использование функции CreateFile с "\\.\PhysicalDiskX" (где X – допустимое целочисленное значение) или " \\.\CdRomX". Это позволяет вам обращаться к этим устройствам напрямую, минуя файловую систему. Это работает, потому что эти имена устройств создаются системой по мере перечисления этих устройств, а некоторые драйверы также создают другие псевдонимы в системе. Например, драйвер устройства, реализующий имя "C:\", имеет собственное пространство имен, которое также является файловой системой.

API, использующие функцию CreateFile, обычно работают с префиксом "\\.\", поскольку функция CreateFile используется для открытия как файлов, так и устройств, в зависимости от используемых вами параметров.

Если вы работаете с функциями Windows API, вы должны использовать префикс "\\.\" для доступа только к устройствам, а не к файлам.

Большинство API не поддерживают "\\.\"; только те, которые предназначены для работы с пространством имен устройства, распознают его. Всегда проверяйте справочную тему для каждого API, чтобы быть уверенным.

Пространства имен NT

Существуют также API, позволяющие использовать соглашение о пространстве имен NT, но диспетчер объектов Windows в большинстве случаев делает это ненужным. Для иллюстрации полезно просматривать пространства имен Windows в обозревателе системных объектов с помощью инструмента Windows Sysinternals WinObj. Когда вы запускаете этот инструмент, вы видите пространство имен NT, начинающееся с корня, или "\". Подпапка под названием "Global??" где находится пространство имен Win32. Объекты именованных устройств находятся в пространстве имен NT в подкаталоге «Device». Здесь вы также можете найти Serial0 и Serial1, объекты устройств, представляющие первые два COM-порта, если они есть в вашей системе.Объект устройства, представляющий том, может иметь вид HarddiskVolume1, хотя числовой индекс может отличаться. Имя "DR0" в подкаталоге "Harddisk0" является примером объекта устройства, представляющего диск, и т. д.

Чтобы сделать эти объекты устройств доступными для приложений Windows, драйверы устройств создают символическую ссылку (символическую ссылку) в пространстве имен Win32 "Global??" на соответствующие объекты устройств. Например, COM0 и COM1 в разделе "Глобальные??" подкаталог — это просто символическая ссылка на Serial0 и Serial1, «C:» — это символическая ссылка на HarddiskVolume1, «Physicaldrive0» — это символическая ссылка на DR0 и так далее. Без символической ссылки указанное устройство «Xxx» не будет доступно ни одному приложению Windows, использующему соглашения о пространстве имен Win32, как описано ранее. Однако дескриптор этого устройства может быть открыт с помощью любых API, поддерживающих абсолютный путь пространства имен NT в формате "\Device\Xxx".

С добавлением многопользовательской поддержки через службы терминалов и виртуальные машины возникла необходимость в виртуализации общесистемного корневого устройства в пространстве имен Win32. Это было достигнуто путем добавления символической ссылки с именем «GLOBALROOT» в пространство имен Win32, которое вы можете увидеть в «Global??» подкаталог инструмента браузера WinObj, который обсуждался ранее, и может получить доступ через путь «\\?\GLOBALROOT». Этот префикс гарантирует, что путь, следующий за ним, соответствует истинному корневому пути диспетчера системных объектов, а не пути, зависящему от сеанса.

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

Как правило, файлы ядра создаются после аварийного завершения процесса из-за ошибки в соответствующем приложении. Какой бы ни была причина, сам файл ядра предоставляет программисту или инженеру службы поддержки бесценную информацию, помогающую диагностировать проблему. Файл ядра можно проверить с помощью отладчика, такого как dbx(1) или mdb(1), либо применив один из proc(1 ) инструменты.

Операционная система пытается создать до двух основных файлов для каждого аварийно завершившегося процесса, используя шаблон глобального имени файла ядра и шаблон имени файла ядра для каждого процесса. Эти шаблоны расширены для определения пути к результирующим файлам ядра и могут быть настроены с помощью coreadm(1M). По умолчанию глобальный шаблон файла ядра отключен и не используется, а шаблон файла ядра для каждого процесса имеет значение core. Поэтому по умолчанию операционная система пытается создать основной файл с именем core в текущем рабочем каталоге процесса.

Процесс завершается и создает файл дампа каждый раз, когда он получает один из сигналов, который по умолчанию вызывает создание дампа памяти. Список сигналов, которые приводят к созданию основного файла, показан в файле signal.h(3HEAD). Следовательно, процесс может не создать файл ядра, если он заблокировал или изменил поведение соответствующего сигнала. Кроме того, дамп ядра не может быть создан при следующих условиях:

Если обычные права доступа к файлам и каталогам препятствуют созданию или изменению пути к основному файлу для каждого процесса текущим пользователем процесса и идентификатором группы. Этот тест не применяется к глобальному пути к файлу дампа ядра, поскольку независимо от UID ядра дампа процесса попытка записать глобальный файл дампа выполняется от имени суперпользователя.

Основные файлы, принадлежащие пользователю nobody, создаваться не будут. Например, основные файлы, созданные для суперпользователя в каталоге NFS, не принадлежат никто и поэтому не записываются.

Если шаблон основного файла расширяется до имени пути, содержащего компоненты промежуточного каталога, которые не существуют. Например, если для глобального шаблона задано значение /var/core/%n/core.%p и нет каталога /var/core/`uname -n` создан, глобальные файлы ядра не создаются.

Если целевой каталог является частью файловой системы, смонтированной только для чтения.

Если ограничение ресурсов RLIMIT_CORE для процесса установлено на 0, файл ядра для каждого процесса не создается. Дополнительные сведения об ограничениях ресурсов см. в разделах setrlimit(2) и ulimit(1).

Если имя основного файла уже существует в целевом каталоге и не является обычным файлом (то есть символической ссылкой, блочным или символьным специальным файлом и т. д.).

Если ядро не может открыть файл назначения O_EXCL, что может произойти, если тот же файл одновременно создается другим процессом.

Если эффективный идентификатор пользователя процесса отличается от его реального идентификатора пользователя или его эффективный идентификатор группы отличается от его реального идентификатора группы. Точно так же программы set-user-ID и set-group-ID не создают файлы ядра, поскольку это потенциально может поставить под угрозу безопасность системы. Этим процессам может быть явно предоставлено разрешение на создание основных файлов с использованием coreadm(1M) с риском раскрытия защищенной информации.

Основной файл содержит всю информацию о процессе, относящуюся к отладке: содержимое аппаратных регистров, состояние процесса и данные процесса. Формат основного файла зависит от объектного файла.

Для исполняемых программ ELF (см. a.out(4)) созданный основной файл также является файлом ELF, содержащим программу ELF и заголовки файлов. Поле e_type в заголовке файла имеет тип ET_CORE. Заголовок программы содержит запись для каждого сегмента, который был частью адресного пространства процесса, включая сегменты разделяемой библиотеки. Содержимое отображений, заданных параметром coreadm(1M), также является частью основного образа. В каждом заголовке программы есть поле p_memsz, для которого задан размер отображения. Поле p_filesz для заголовков программ, представляющих сопоставления, данные которых включены в основной файл, равно p_memsz, в противном случае p_filesz равно ноль.

Данные сопоставления могут быть исключены из-за настроек содержимого основного файла (см. coreadm(1M)) или из-за какой-либо ошибки. Если данные исключены из-за сбоя, в записи заголовка программы будет установлен флаг PF_SUNW_FAILURE в поле p_flags.

Заголовки программ основного файла ELF также содержат записи для двух сегментов NOTE, каждый из которых содержит несколько записей примечаний, как описано ниже. Определения заголовка записи примечания и типа примечания основного файла (n_type) содержатся в файлах . Первый сегмент NOTE существует для бинарной совместимости со старыми программами, работающими с файлами ядра. Он содержит структуры, определенные в . Новые программы должны распознавать и пропускать этот сегмент NOTE, вместо этого переходя к новому сегменту NOTE. Старый сегмент NOTE будет удален из основных файлов в будущем выпуске.

n_type: NT_PRPSINFO. Эта запись содержит информацию, представляющую интерес для команды ps(1), такую как статус процесса, использование ЦП, значение nice, управляющий терминал, идентификатор пользователя, идентификатор процесса, имя исполняемого файла и так далее. Структура prpsinfo_t определена в .

n_type: NT_PLATFORM. Эта запись содержит строку, описывающую конкретную модель аппаратной платформы, на которой был создан этот файл ядра. Эта информация аналогична информации, предоставляемой sysinfo(2) при вызове с помощью команды SI_PLATFORM.

n_type: NT_AUXV. Эта запись содержит массив структур auxv_t, которые были переданы операционной системой в качестве информации о запуске динамическому компоновщику. Вспомогательная векторная информация определяется в .

Следуя этим записям, для каждого активного (не зомби) облегченного процесса (LWP) в процессе старый сегмент NOTE содержит запись с prstatus_t структура, а также другие необязательные записи, описывающие LWP, как показано ниже:

n_type: NT_PRSTATUS. Эта структура содержит сведения, представляющие интерес для отладчика из операционной системы, такие как общие регистры, расположение сигналов, состояние, причина остановки, идентификатор процесса и т. д. Структура prstatus_t определена в .

n_type: NT_PRFPREG. Эта запись присутствует только в том случае, если LWP использует аппаратное обеспечение с плавающей запятой. Он содержит регистры с плавающей запятой. Структура prfpregset_t определена в .

n_type: NT_GWINDOWS. Эта запись присутствует только на машине SPARC и только в том случае, если системе не удалось сбросить все окна регистров в стек. Он содержит все незаполненные окна регистров. Структура gwindows_t определена в .

n_type: NT_PRXREG. Эта запись присутствует только в том случае, если машина имеет дополнительное состояние регистра, связанное с ней. Он содержит дополнительное состояние регистра. Структура prxregset_t определена в .

n_type: NT_PSINFO. Эта структура содержит информацию, представляющую интерес для команды ps(1), такую как статус процесса, использование ЦП, значение nice, управляющий терминал, идентификатор пользователя, идентификатор процесса, имя исполняемого файла и так далее. Структура psinfo_t определена в .

n_type: NT_PSTATUS. Эта структура содержит элементы, представляющие интерес для отладчика из операционной системы, такие как ожидающие сигналы, состояние, идентификатор процесса и т. д. Структура pstatus_t определена в .

n_type: NT_PLATFORM.Эта запись содержит строку, описывающую конкретную модель аппаратной платформы, на которой был создан этот файл ядра. Эта информация аналогична информации, предоставляемой sysinfo(2) при вызове с помощью команды SI_PLATFORM.

n_type: NT_UTSNAME. Эта структура содержит системную информацию, которая была бы возвращена процессу, если бы он выполнил системный вызов uname(2) перед созданием дампа ядра. Структура utsname определена в .

n_type: NT_PRCRED. Эта структура содержит учетные данные процесса, включая реальные, сохраненные и действующие идентификаторы пользователей и групп. Структура prcred_t определена в . За структурой следует необязательный массив дополнительных идентификаторов групп. Общее количество идентификаторов дополнительных групп задается элементом pr_ngroups структуры prcred_t, и структура включает место для одной дополнительной группы. Если pr_ngroups больше 1, за структурой следует элемент pr_ngroups - 1 gid_t; в противном случае дополнительные данные отсутствуют.

n_type: NT_ZONENAME. Эта запись содержит строку, описывающую имя зоны, в которой выполнялся процесс. См. зоны(5). Информация аналогична предоставленной getzonenamebyid(3C) при вызове с числовым идентификатором, возвращенным getzoneid(3C).

структурировать массив ssd

n_type: NT_LDT. Эта запись присутствует только на 32-разрядной машине x86 и только в том случае, если процесс установил локальную таблицу дескрипторов (LDT). Он содержит массив структур типа struct ssd, каждая из которых обычно использовалась для настройки сегментного регистра %gs для получения адреса текущего потока. информационная структура в многопоточном процессе. Структура твердотельного накопителя определена в .

n_type: NT_CONTENT. Эта необязательная запись указывает, какие части образа процесса должны быть включены в основной файл. См. coreadm (1M).

После этих записей для каждого активного и зомби-LWP в процессе новый сегмент NOTE содержит запись со структурой lwpsinfo_t, а также для не-зомби LWP. , запись со структурой lwpstatus_t, а также другие необязательные записи, описывающие LWP, как показано ниже. LWP-зомби — это неотсоединенный LWP, который завершился, но еще не был получен другим LWP в том же процессе.

n_type: NT_LWPSINFO. Эта структура содержит информацию, представляющую интерес для команды ps(1), такую как состояние LWP, использование ЦП, значение nice, LWP-ID и т. д. Структура lwpsinfo_t определена в . Это единственная запись для LWP-зомби.

n_type: NT_LWPSTATUS. Эта структура содержит сведения, представляющие интерес для отладчика из операционной системы, такие как общие регистры, регистры с плавающей запятой, состояние, причина остановки, LWP-ID и т. д. Структура lwpstatus_t определена в >.

n_type: NT_ASRS. Эта запись присутствует только на компьютере SPARC V9 и только в том случае, если процесс является 64-разрядным. Он содержит вспомогательные государственные регистры для LWP. Структура asrset_t определена в .

В зависимости от настроек coreadm(1M) заголовок раздела основного файла ELF может содержать записи для разделов CTF, таблицы символов и таблицы строк. Поля sh_addr устанавливаются на базовый адрес первого сопоставления объекта загрузки, из которого они пришли. Это можно использовать для сопоставления этих разделов с соответствующим объектом загрузки.

Размер основного файла, созданного процессом, может контролироваться пользователем (см. getrlimit(2)).

Файловая система exFAT была разработана с учетом имен файлов Unicode и дополнительных расширений, зависящих от производителя. Для простоты спецификация файловой системы позволяет использовать несколько записей каталога для описания одного файла (таким образом, дополнительные метаданные файла описываются в дополнительных записях каталога).Это решение похоже на расширение VFAT для файловых систем FAT12/16/32, которое было разработано как взлом исходного формата файловой системы (изначально для описания одного файла использовалась только одна запись каталога, поэтому длинные имена файлов реализованы в виде дополнительных записей каталога, «невидимых» для операционных систем без поддержки VFAT).

В файловой системе exFAT типичный файл состоит из следующих записей (именно в таком порядке, без других записей между ними):

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

Первые две записи описывают все метаданные файла (его атрибуты, метки времени, размер данных, первый кластер и т. д.), а записи имени файла содержат строки для формирования имени файла (каждая запись имени файла хранит не более 15 символов Юникода). символов, а имя файла не длиннее 255 символов). Вместе эти записи называются набором записей каталога (и он должен содержать не менее трех записей).

При удалении файла его набор записей каталога помечается как свободный. Этот процесс очень похож на то, что происходит с удаленным файлом в файловых системах FAT12/16/32: первый байт записи каталога изменяется, чтобы пометить его как свободный.

И, конечно же, можно восстановить удаленный файл, когда его набор каталогов и кластеры данных не перезаписаны. Если набор записей каталога частично перезаписан (новыми записями каталога), можно наблюдать следующее:

если запись в файле перезаписывается, метки времени и атрибуты теряются;
если запись расширения потока перезаписывается, первый кластер и размер данных становятся неизвестными, поэтому остаточные данные файла больше не связаны с этим файлом;
если записи имени файла перезаписываются, имя файла теряется.

Теперь давайте посмотрим, что происходит, когда свободные записи каталога перезаписываются в файловых системах FAT32 и exFAT.

Расположение записей каталога, описывающих удаленный файл, два состояния:
– удаленный файл с неповрежденными записями;
– тот же файл с первой записью, перезаписанной новым файлом.

В файловой системе FAT32 (а также в файловых системах FAT12/16) длинные имена файлов сохраняются в записях, предшествующих записи с коротким именем файла (и без пробелов между этими записями). И только запись с коротким именем файла содержит метки времени и указатель на данные файла (его первый кластер), записи с длинным именем файла хранят только символы Unicode, не считая некоторых внутренних метаданных для идентификации и проверки записи (и записи хранятся в обратном порядке : первые символы длинного имени сохраняются в последней записи длинного имени файла, непосредственно перед записью короткого имени).

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

Например, давайте создадим файл со следующим длинным именем:

Тогда давайте удалим этот файл и проверим его имя. То же самое:

Теперь давайте создадим новый файл с коротким именем («1.TXT»). Затем давайте проверим удаленный файл, теперь его имя:

Как видите, пять символов («0.txt») были потеряны, потому что первая запись в каталоге удаленного файла (содержащая последнюю часть длинного имени файла) была перезаписана (см. макет выше). Тем не менее, у нас есть короткая запись имени файла, поэтому мы можем прочитать данные.

Это означает, что мы можем восстанавливать метаданные удаленного файла (кроме полного длинного имени файла) до тех пор, пока его запись с коротким именем файла не будет перезаписана. И его запись с коротким именем файла не будет перезаписана перед записью с длинным именем файла… (Если только мы не рассмотрим некоторые необычные сценарии размещения записей в каталоге.)

В файловой системе exFAT ситуация иная.

Расположение записей каталога, описывающих удаленный файл, два состояния:
– удаленный файл с неповрежденными записями;
– тот же файл с первыми тремя записями, перезаписанными новым файлом.

Здесь записи имени файла хранятся после записи расширения потока (и их порядок обычный: первая запись, следующая за записью расширения потока, содержит первые символы имени файла).

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

Тесты показывают, что драйвер exFAT для Windows не следует этому алгоритму распределения. Вместо этого для относительно небольших каталогов драйвер расширяет массив записей каталога и добавляет новые записи (записывает их в конец расширенного массива). В этом случае удаленные записи каталога остаются нетронутыми.

Однако два драйвера exFAT, найденные в ядре Linux и в операционной системе macOS соответственно, пытаются размещать новые записи ближе к началу массива.

Поскольку файл не может быть описан с использованием менее трех записей каталога, размещение файла, описанного с использованием трех записей каталога, в пробел (пробел между двумя выделенными записями), ранее занятый файлом, описанным с помощью четырех записей каталога, оставляет один свободный каталог. запись без изменений (например, запись «Имя файла, часть 2» в макете выше). Эта запись не может быть выделена, так как для новых файлов требуется три или более непрерывных записей каталога (поэтому эту запись нельзя выделить, пока не будет удален следующий или предыдущий файл).

Это означает, что реализации exFAT, найденные в ядре Linux и операционных системах macOS, как правило, оставляют много записей с именами потерянных файлов в промежутках между выделенными файлами, такие записи содержат частичные (или полные, если повезет) имена файлов ранее удаленных файлы. (Здесь слово «сирота» означает отсутствие соответствующих записей расширений файлов и потоков.)

Такое поведение было подтверждено для Ubuntu 21.10 и macOS Monterey (также я наблюдал его в реальных данных).

Пример (macOS Monterey) приведен ниже.

Вот список файлов в каталоге (как показано в The Sleuth Kit, 4.11.1):

(Всего 255 файлов. Файлы, помеченные как удаленные, не найдены.)

А вот дамп этого каталога в формате HEX (показано только начало каталога):

Дамп той же директории в формате HEX. (Границы записей каталога отмечены зелеными линиями, остаточная запись имени файла отображается как выбранная.)

И, наконец, вот как этот каталог отображается при использовании проекта dfir_ntfs:

После того, как вы приобрели лицензии ArcGIS Navigator, выполните следующие действия, чтобы настроить портал для поддержки приложения Navigator.

Назначить лицензии участникам портала.
Загружайте пакеты мобильных карт с My Esri или создавайте пользовательские пакеты мобильных карт в ArcGIS Pro. Разместите их на веб-сервере.
Зарегистрируйте пакеты мобильных карт на портале.

Затем участники могут войти на портал с помощью приложения Navigator, загрузить пакеты карт для своей работы и перемещаться в автономном режиме. Дополнительные сведения см. в справке ArcGIS Navigator.

Управление пакетами мобильных карт

Пользователи Navigator, выполнившие вход на ваш портал, увидят пакеты мобильных карт, которые вы сделали доступными для загрузки. Вы можете получить пакеты карт, созданные Esri, из My Esri или создать свои собственные пакеты карт в ArcGIS Pro и загрузить их на свой портал. Чтобы сделать пакеты мобильных карт доступными для пользователей приложения Navigator, вы должны зарегистрировать их на своем портале.

Порталы ArcGIS Enterprise поставляются с группой Navigator Maps, принадлежащей esri_nav. Эта группа предварительно заполнена элементами, созданными Esri. Вы можете просматривать содержимое группы Navigator Maps, чтобы увидеть описание каждого элемента, миниатюру и другую информацию.

Выполните следующие действия, чтобы получить доступ к элементам группы Navigator Maps:

Войдите на портал.
Откройте Группы > Группы моей организации.
Нажмите на группу Карты навигатора.

При этом открывается страница элемента для группы.

При первом создании портала эти элементы не связаны ни с какими пакетами карт. Чтобы заполнить элементы содержимым или обновить содержимое элемента, загрузите пакеты карт с My Esri, разместите их на собственном веб-сервере и зарегистрируйте размещенные пакеты на портале.

Используйте инструмент пакетов мобильных карт ( managemmpks ), который устанавливается вместе с Portal for ArcGIS, чтобы зарегистрировать эти пакеты. Вы также можете использовать этот инструмент для обновления, отмены регистрации и внесения в список пакетов мобильных карт на вашем портале по мере необходимости.

Для использования ArcGIS Navigator участникам портала должны быть назначены лицензии Navigator.

Загрузить пакеты мобильных карт, предоставленные Esri

Чтобы загрузить пакеты мобильных карт, предоставленные Esri, выполните следующие действия.

Войдите в My Esri и нажмите Мои организации > Загрузки > Данные и содержимое .
Введите "Навигатор" в текстовом поле поиска и выберите нужный вариант сортировки в раскрывающемся списке "Сортировать по".
Прокрутите список пакетов мобильных карт, чтобы найти нужные файлы.
Нажмите «Загрузить» для каждого пакета мобильных карт, который вы хотите предоставить пользователям приложения Navigator. Скачивайте файлы по одному.
Поместите загруженные пакеты карт в место, доступное через Интернет. Например, если вы используете IIS в качестве веб-сервера, вы можете поместить загруженные файлы в папку c:\inetpub\wwwroot\ или в другое место, настроенное как виртуальный каталог.

URL-адрес веб-сервера, на котором вы размещаете файлы пакетов карт, является базовым URL-адресом, который вы предоставляете при использовании инструмента managemmpks для регистрации пакетов и управления ими.

Откройте диспетчер IIS.
На панели "Подключения" выберите свой сервер в дереве и дважды щелкните "Типы MIME" .
На панели "Действия" нажмите "Добавить" .
В поле "Расширение имени файла" введите .mmpk.
В качестве типа MIME введите application/mmpk .
Перезапустите веб-сервер.

Зарегистрировать пакеты мобильных карт

После того как вы приобрели пакеты мобильных карт и разместили их на веб-сервере, зарегистрируйте их на своем портале. О любых обновлениях пакетов мобильных карт также необходимо сообщать порталу. Ваш портал включает элемент портала для каждого пакета мобильных карт. Регистрация пакетов мобильных карт обновляет эти элементы портала, чтобы они ссылались на URL-адреса файлов .mmpk на вашем веб-сервере.

Вы можете регистрировать пакеты мобильных карт и управлять ими с помощью инструмента managemmpks. Этот инструмент устанавливается вместе с Portal for ArcGIS в

Каталог

\tools\managemmpks. Вам будет предложено ввести имя пользователя и пароль администратора портала при запуске инструмента managemmmpks.

Инструмент managementmmpks позволяет одновременно зарегистрировать на портале один или несколько пакетов мобильных карт. Инструмент принимает в качестве входных данных имена элементов портала, а не имена пакетов карт. Поэтому перед регистрацией вам необходимо знать названия существующих элементов портала. Чтобы получить этот список, вы можете использовать команду --preinstalled с инструментом managemmpks или просмотреть содержимое группы Navigator Maps.

Введите managemmpks --help, чтобы получить справку по синтаксису инструмента.

Как только вы узнаете имена элементов, которые хотите зарегистрировать, выполните следующие действия, чтобы зарегистрировать пакеты карт, размещенные на вашем веб-сервере:

Войдите на компьютер, на котором установлен Portal for ArcGIS.
Откройте окно командной строки, используя параметр "Запуск от имени администратора".
В командной строке перейдите к папке tools\managemmpks в каталоге установки Portal for ArcGIS.
Запустите следующий инструмент managemmpks с командой --register, чтобы зарегистрировать все пакеты мобильных карт, перечисленные в текстовом файле, файле значений, разделенных запятыми, или в виде списка имен элементов пакетов, разделенных запятыми: managemmpks --register --url

При использовании команды --packages необходимо вставлять знаки подчеркивания (_), чтобы заменить пробелы в именах элементов портала, содержащих несколько слов, как показано для элемента Чехия в предыдущем примере.

Если вы используете текстовый файл или файл со значениями, разделенными запятыми (CSV), для регистрации пакетов мобильной карты, вам не нужно заменять пробелы в именах элементов символами подчеркивания. Например, файл может содержать следующие записи:

Пользователи приложения Navigator могут загружать пакеты карт для навигации.

Обновление пакетов мобильных карт

Esri регулярно обновляет пакеты мобильных карт на My Esri. Вы также можете обновить пакеты мобильных карт, созданные вами в ArcGIS Pro. После того, как вы получите эти обновленные файлы и поместите их в каталог файлов пакета мобильных карт, доступ к которому осуществляется через базовый URL-адрес, используйте инструмент managemmpks с командой --refresh для обновления содержимого пакета. Вы можете предоставить текстовый файл или файл CSV, содержащий имена пакетов мобильных карт или список названий элементов, разделенных запятыми. Синтаксис: managemmpks --refresh

В этом примере обновленные пакеты сельскохозяйственных угодий и мобильных карт pop_density были размещены там, где базовый URL-адрес может получить к ним доступ.

Обновляйте содержимое элементов в группе Navigator Maps при появлении новых файлов .mmpk, но не меняйте связанный с ними базовый URL-адрес. После запуска команды --refresh пользователи приложения Navigator увидят, что файлы были обновлены, и смогут загрузить обновленные файлы.

Отмена регистрации пакетов мобильных карт

Чтобы отменить регистрацию пакетов мобильных карт, используйте команду --unregister с инструментом managemmpks. Вы можете указать список пакетов в текстовом или CSV-файле с помощью команды --file или включить список имен элементов, разделенных запятыми, с помощью команды --packages.

В этом примере пакет мобильных карт Албании не зарегистрирован.

При использовании команды --packages необходимо вставлять знаки подчеркивания (_), чтобы заменить пробелы в именах элементов портала, содержащих несколько слов, например Чехия .

В следующем примере показана отмена регистрации пакетов мобильных карт, перечисленных в текстовом файле package_list.txt :

Если вы используете текстовый файл или файл со значениями, разделенными запятыми (CSV), для отмены регистрации пакетов мобильных карт, вам не нужно заменять пробелы в именах элементов символами подчеркивания. Например, файл может содержать следующие записи:

Список всех пакетов мобильных карт

Используйте команду --list с инструментом managemmpks, чтобы создать два списка: один из зарегистрированных пакетов мобильных карт и один из незарегистрированных пакетов мобильных карт. Используйте команду --dir, чтобы указать выходной каталог, в котором будут создаваться текстовые файлы этих списков. Имя файла автоматически генерируется инструментом managemmpks. Затем вы можете использовать эти текстовые файлы в качестве входных данных для регистрации и отмены регистрации файлов .mmpk.

В этом примере список пакетов мобильных карт выводится в каталог C:\temp.

registered-.txt — этот файл содержит имена зарегистрированных элементов.
unregistered-.txt – этот файл содержит имена незарегистрированных элементов.

Список установленных пакетов мобильных карт

Используйте команду --preinstalled с инструментом managemmpks, чтобы получить список пакетов мобильных карт, поставляемых с вашим порталом. Вы можете вывести текстовый файл, содержащий этот список. Затем вы можете использовать текстовый файл в качестве входных данных для регистрации и отмены регистрации файлов .mmpk.

Чтобы получить список пакетов карт в командной строке или терминале, укажите команду --preinstalled, как показано в этом примере.

Если вы хотите вывести список в файл, укажите имя файла, как показано в следующем примере:

Читайте также: