Идентификатор файла что это
Обновлено: 07.07.2024
Операнд идентификатор файла дополняет возможности опознавания файла и присваивается ему пользователем при создании. Этот операнд может состоять из 1 - 17 символов, включая возможные пробелы, и должен ограничиваться апострофами. [6]
Блок идентификатора файла ( метка формата 1) именует файл и среди прочего описывает организацию файла, дату создания и срок хранения. Метка содержит также адрес файла или максимум три адреса, если файл занимает более чем одну непрерывную область памяти ( экстент) на устройстве прямого доступа. Поле адреса метки файла указывает первый и последний цилиндры и дорожки, выде-ленные для экстента. Она может содержать описания и адреса до тринадцати других экстентов. В этом случае метка формата 1 ссылается на метку формата 3, сформированную для данного файла. [7]
Операнд идф1 - исходный идентификатор файла , который будет изменен на новый. Должны быть указаны все три составляющие идентификатора файла. Каждая составляющая может быть задана именем или звездочкой. В последнем случае переименовывается каждый файл, удовлетворяющий остальным составляющим указанного идентификатора. [8]
В поле ключа размещается уникальный идентификатор файла . В ОС ЕС он представлен в коде ДКОИ. [9]
Операнд иф тф рф определяет идентификатор файла , записи которого обрабатываются. [10]
Коды возврата: 20 - идентификатор файла недействительный; 28 - файл не найден. [11]
Коды возврата: 20 - идентификатор файла недействительный; 24 - режим файла недействительный; 28 - файл на указанном диске не найден; 36 - диск недоступен. [12]
Регистр 1 записи содержит реквизит идентификатор файла , который может быть произвольным. Но наиболее целесообразно использовать систему кодирования, обеспечивающую однозначную связь между задачами, программами и файлами этих задач. [13]
Используется для прекращения поиска по идентификатору файла . В байтах 7 - 8 указывается число свободных входов в Оглавлении тома. В байтах 9 - 12 содержится адрес альтернативных дорожек, выделенных как запасные взамен дефектных, а в байтах 13 - 14 указывается их число. [14]
С каждым файлом в ПДО связывается идентификатор файла , состоящий из трех частей: имени, типа и режима. [15]
есть ли способ однозначно идентифицировать файл (и, возможно, каталоги) для времени жизни файла независимо от перемещений, переименований и изменений содержимого? (Windows 2000 и позже). Создание копии файла должно дать копии собственный уникальный идентификатор.
мое приложение связывает различные метаданные с отдельными файлами. Если файлы изменены, переименованы или перемещены, было бы полезно иметь возможность автоматически обнаруживать и обновлять файл объединения предпринимателей.
FileSystemWatcher может предоставить события, которые сообщают о таких изменениях, однако он использует буфер памяти, который может быть легко заполнен (и события потеряны), если многие события файловой системы происходят быстро.
хэш бесполезен, потому что содержимое файла может измениться, и поэтому хэш изменится.
Я думал об использовании даты создания файла, однако есть несколько ситуаций, когда это не будет уникальным (т. е. когда несколько файлов скопированный.)
Я также слышал о файле SID (Security ID?) в NTFS, но я не уверен, что это сделает то, что я ищу.
Если вы называете GetFileInformationByHandle, вы получите идентификатор файла в BY_HANDLE_FILE_INFORMATION.nFileIndexHigh / Low. Этот индекс уникален в пределах Тома и остается неизменным, даже если вы перемещаете файл (в пределах тома) или переименовываете его.
Если вы можете предположить, что используется NTFS, вы также можете рассмотреть возможность использования альтернативных потоков данных для хранения метаданных.
вот пример кода, который возвращает уникальный индекс файла.
подхода () - это то, что я придумал после немного исследований. ApproachB () - это благодаря информации в ссылках, предоставленной Маттиасом и Рубенсом. Учитывая конкретный файл, оба подхода возвращают один и тот же индекс файла (во время моего базового тестирования).
некоторые предостережения от MSDN:
поддержка идентификаторов файлов-это файл конкретной системы. Идентификаторы файлов не гарантированно быть уникальным с течением времени, потому что файловые системы можно использовать повторно их. в некоторых случаях, идентификатор файла на файл может меняться со временем.
в файловой системе FAT идентификатор файла генерируется из первого кластера содержащий каталог и Байт смещение в каталог запись для файла. Некоторые продукты дефрагментации изменяют это смещение байта. (Окна в окна дефрагментация не.) Таким образом, жир идентификатор файла может меняться со временем. Переименование файл в файле FAT система может также измените идентификатор файла, но только если новое имя файла длиннее старого один.
в файловой системе NTFS файл сохраняется тот же идентификатор файла, пока он не будет удален. Вы можете заменить один файл другим файл без изменения идентификатора файла использование функции ReplaceFile. Однако, идентификатор файла файл замены, а не замененный файл, сохраняется как идентификатор файла результирующий файл.
первый смелый комментарий выше беспокоит меня. Неясно, относится ли это утверждение только к FAT, оно, похоже, противоречит второму выделенному жирным шрифтом тексту. Думаю, дальнейшее тестирование-единственный способ убедиться.
[Update: в моем тестировании индекс/id файла изменяется, когда файл перемещается с одного внутреннего жесткого диска NTFS на другой внутренний жесткий диск NTFS.]
пользователь также упоминает уникальную идентификацию каталога. Этот процесс немного более запутан, чем получение уникальной информации для файла; однако это возможно. Он требует, чтобы вы позвонили в соответствующий CREATE_FILE функции какой конкретный флаг. С этой ручкой вы можете вызвать GetFileInformationByHandle функция в Эше ответ.
этой kernel32.dll импорт:
Почему нельзя упорядочить по ссылке, если в ней содержится дата создания?
Как уже было описано, guid изначально был придуман для РАСПРЕДЕЛЕННЫХ систем, в которых ПРОБЛЕМА УНИКАЛЬНОСТИ идентификаторов решена полным ОТКАЗОМ ОТ АВТОИНКРЕМЕНТА в пользу СЛУЧАЙНЫХ чисел и специальных техник. GUIDы случайны и неповторяемы по определению и в этом его достоинство и недостаток. Например, в предопределенных элементах и произвольных идентификаторах используется Random GUIDs (Version 4). В "типизированных" же Time-Based GUIDs (Version 1).
Можно ли вытащить время из гуида?
Можно. Но не нужно.
bdb62d89-cede-11e4-b12b-d4ae52b5e909
Алгоритм:
дата содержится в первых символах, bdb62d89-cede-11e4 которые нужно переставить задом наперед: 11e4-cede-bdb62d89
первый символ отбрасываем, убираем "лишние" знаки "-"(тире)
интервал в десятых долях микросекунд (HEX) получается равным: интервал16= 1E4CEDEBDB62D89
переводим его в десяничный интервал интервал10 = HexToDec(интервал16);
в результате получаем: интервал10 = 136 461 344 788 852 105
находим интервал в секундах: интервалСек = интервал10 / 10 000 000;
Делаем сдвиг даты от [3]
Почему части времени идут "задом-наперед"?
"Так сложилось" ;)
Например потому что guid'ы появились задолго до того, как до них добрались руки ietf и баз данных.
Или потому что платформа написана на C, а не на Java, а как мы знаем из асемблера архитектура x86 имеет little-endian byte order.
Или, как говорит википедия, использовалось 2 варианта: для передачи по сети "on-wire" "network" (big-endian) byte order, а для хранения "native" (little-endian) byte order.
В любом случая я не знаю как там было и можно только догадываться.
[2] [3]
Если отчет из одной конфигурации копипастой тащу в другую - ID сохранится его?(в моей его не было) (c) 2michael
Ответ: При копировании объекта из одной конфы в другую _копипастом_ внутренний гуид меняется!
НО: при сравнении объединении этого не видно!, так как происходит сопоставление по имени.
НО: это не касается и предопределённых данных! Если добавлять их вручную, а потом конфу разработки сравнить-объединить с боевой - возникнут дубли в справочнике!
В edt же есть режим сравнения только по guid.
При замене отчета в дереве конфигурации командой "Заменить на внешнюю обработку, отчет. " меняется ли внутренний идентификатор объекта (отчета)? (с) Pandoch upd:02.07.20
Ответ: Нет, гуид при замене из файла остаётся прежним
Другая вариация вопроса: Есть две разные конфы. Но в них есть одинаковый объект метаданных например документ "Покупка". Как можно получить внутренний идентификатор этого объекта в обеих базах, используемый в сравнении и объединении, чтобы удостовериться, что этот объект, не зависимо от имени, замениться, а не дублируется ? Как я понял ЗначениеВСтрокуВнутр() дает не тот ID который нужен мне.
При каждой выгрузке во внешний отчет/обработку guid генерируется заного. При загрузке из файла - востанавливается. Это позволяет хоть 10 раз выгрузить отчет/обработу во внешний файл, и каждый из этих файлов можно будет открыть параллельно в клиенте.
ЗначениеВСтрокуВнутр() выдает идентификатор прикладного типа, а не внутреннего объекта метаданных. Помимо внутреннего идентификатора у каждого объекта метаданных есть идентификаторы типов. Например ОтчетМенеджер.<Имя отчета> и ОтчетОбъект.<ИмяОтчета>:
Все типы имеют свои идентификаторы, но при загрузке через "Заменить на внешнюю обработку, отчет. " они, так же как и идентификатор метаданных, заменяются на текущие.
Например - загрузка в отчет ABCАнализПокупателей внешнего отчета ДебиторскаяЗадолжность.epf вызовет лишь добавление суффикса (такой отчет уже есть в конфигурации), а все идентификаторы остаются прежними.
Скрин до загрузки - после загрузки:
Идентификаторы не изменились.
Почему используется "перевернутый" формат UUID внутри 1с?
<Объект не найден> (26:80f408002771598b11e7a3f0a3a64c3b)
Не знаю. Знаю только что первая цифра соответствует имени таблицы в sql: Reference26 -> ВидыНоменклатуры
[1]
Есть же спецификация?
Есть.
Расшифровываю:
Timestamp - это 60-битное число, содержащее количество 100-наносекундных интервалов с 15 октября 1582 г.
Часть low обнуляется каждые 2^32 / 10^7 / 60
7 минут, часть mid через 1 год, часть hi сами представляете.
Version - старшие 4 бита в седьмом октете, содержат тип гуида.
0x0001 1 time-based version
0x0010 2 DCE Security version (POSIX UIDs)
0x0011 3 name-based version (MD5 hashing)
0x0100 4 randomly generated version
0x0101 5 name-based version (SHA-1 hashing)
Clock Sequence - используется чтобы избежать появления дубликатов, когда часы переводятся назад или меняется идентификатор узла. Если предыдущее значение счетчика известно - то увеличивается на единицу, иначе берется случайное число.
Node - содержит физический MAC-адрес сервера. Дада, проверьте ipconfig /all ;)
Примеры? Есть их у меня.
Мы же "программисты", накодим функции:
Проверим ссылку обычного документа:
Проверим ссылку, сформированную вручную:
Проверим работу счетчика "уникальности":
Можно даже так:
Какой мак-адрес у меня, вы уже знаете ;)
ps: под "упорядочить по ссылке" везде имеется ввиду сортировка в порядке создания ссылок и вообще в каком-либо порядке, отличном от сравнения в побитовом бинарном формате хранения бд.
Ну вот и все.
Надеюсь, теперь мысль о том, чтобы "упорядочить по ссылке", я из вас вытряхнул окончательно.
В данной теме я рассмотрю четыре вида метаданных, которые могут быть прикреплены к файлу или каталогу средствами файловой системы NTFS. Я опишу, в каких целях можно использовать тот или иной тип метаданных, приведу пример его применения в какой-либо технологии Microsoft или стороннем программном обеспечении.
Речь пойдёт о точках повторной обработки (reparse points), идентификаторах объектов (object id) и о других типах данных, которые может содержать файл помимо своего основного содержимого.
Object Id
Идентификатор объекта это 64 байта, которые можно прикрепить к файлу или каталогу. Из них первые 16 байт позволяют однозначно идентифицировать файл в пределах тома и обращаться к нему не по имени, а по идентификатору. Остальные 48 байт могут содержать произвольные данные.
Идентификаторы объектов существуют в NTFS со времён Windows 2000. В самой системе они используются для отслеживания расположения файла, на который ссылается ярлык (.lnk). Допустим, файл, на который ссылается ярлык, был перемещён в пределах тома. При запуске ярлыка он всё равно откроется. Специальная служба Windows в случае, если файл не найден, произведёт попытку открыть файл не по его имени, а по заранее созданному и сохранённому идентификатору. Если файл не был удалён и не покидал пределы тома, он откроется, а ярлык снова будет указывать на файл.
Идентификаторы объектов использовались в технологии iSwift Антивируса Касперского 7-ой версии. Вот как описана эта технология: Технология разработана для файловой системы NTFS. В этой системе каждому объекту присваевается NTFS-индентификатор. Этот индентификатор сравнивается с значениями специальной базы данных iSwift. Если значения базы данных с NTFS-индентификатором не совпадают, то объект проверяется или перепроверяется, если он был изменен.
Впрочем, переизбыток созданных идентификаторов вызывал проблемы со сканированием диска стандартной утилитой проверки chkdsk, она происходила слишком долго. В следующих версиях Антивируса Касперского отказались от использования NTFS Object Id.
Reparse Point
В файловой системе NTFS файл или каталог может содержать в себе reparse point, что переводится на русский язык как «точка повторной обработки». В файл или каталог добавляются специальные данные, файл перестаёт быть обычным файлом и обработать его может только специальный драйвер фильтра файловой системы.
В Windows присутствуют типы reparse point, которые могут быть обработаны самой системой. Например, через точки повторной обработки в Windows реализуются символьные ссылки (symlink) и соединения (junction point), а также точки монтирования томов в каталог (mount points).
Reparse-буфер, присоединяемый к файлу это буфер, имеющий максимальный размер 16 килобайт. Он характеризуется наличием тега, который говорит системе о том, к какому типу принадлежит точка повторной обработки. При использовании reparse-буфера собственного типа ещё необходимо задавать в нём GUID в специальном поле, а в reparse-буферах Microsoft он может отсутствовать.
Какие типы точек повторной обработки существуют? Перечислю технологии, в которых используются reparse point'ы. Это Single Instance Storage (SIS) и Cluster Shared Volumes в Windows Storage Server 2008 R2, Hierarchical Storage Management, Distributed File System (DFS), Windows Home Server Drive Extender. Это технологии Microsoft, здесь не упомянуты технологии сторонних компаний, использующие точки повторной обработки, хотя такие тоже есть.
Extended Attributes
Расширенные атрибуты файла. Про них был мой предыдущий топик. Здесь стоит упомянуть только то, что под Windows эта технология практически не применяется. Из известного мне программного обеспечения только Cygwin использует расширенные атрибуты для хранения POSIX прав доступа. У одного файла на NTFS могут быть или расширенные атрибуты, или буфер точки повторной обработки. Одновременная установка и того и другого невозможна. Максимальный размер всех расширенных атрибутов у одного файла составляет 64 Кб.
Alternate Data Streams
Дополнительные файловые потоки. Про них знает уже, наверное, каждый. Перечислю основные признаки этого вида метаданных: именованность (то есть у файла может быть несколько потоков, и у каждого своё имя), прямой доступ из файловой системы (их можно открывать, используя формат «имя файла, двоеточие, имя потока»), неограниченный размер, возможность запуска процесса прямо из потока (и возможность реализовать через это бесфайловый процесс).
Так пользователю даётся дополнительная защита от необдуманного запуска программ, полученных из интернета. Это лишь одно применение потоков, а так в них можно хранить самые разные данные. Упомянутый Антивирус Касперского хранил там контрольные суммы каждого файла, но позже от этой технологии тоже по какой-то причине отказались.
Что-нибудь ещё?
Есть ещё идентификатор безопасности, плюс стандартные атрибуты файла, к которым нет прямого доступа, несмотря на то, что они тоже реализованы как потоки файлов. И они, и расширенные атрибуты, и reparse и object id — всё это потоки файла с точки зрения системы. Напрямую изменять идентификатор безопасности, показанный на следующей картинке как ::$SECURITY_DESCRIPTOR смысла нет, пусть его изменением занимается система. К другим типам потоков сама система не даёт прямого доступа. Так что на этом всё.
Просмотр содержимого object id, точек повторной обработки, а также работа с расширенными атрибутами и альтернативными файловыми потоками возможна с помощью программы NTFS Stream Explorer, а также через системную консольную утилиту fsutil.
Уникальный идентификатор файла (object id) это буфер данных размером 64 байта, однозначно идентифицирующий файл в пределах локального тома NTFS. Он может присутствовать или отсутствовать у каждого файла на диске NTFS, а также имеется у каждого тома. Если он присутствует у файла, то он может быть открыт по этому идентификатору, даже если неизвестен путь.
Уникальный идентификатор хранится в файловой записи NTFS в специальном системном потоке с именем ::$OBJECT_ID. Этот системный поток не может быть прочитан напрямую. Так, попытка прочитать его консольной командой more потерпит неудачу:
У тома NTFS существует специальный файл $ObjId, находящий в специальном каталоге $Extend. Этот файл отвечает за поддержку идентификаторов object id. Дополнительная информация в статье «Специальные файлы NTFS».
Идентификатор состоит из четырёх GUID, которые определены в виде структуры OBJECTID_ATTRIBUTE:
- ObjectId
Идентификатор объекта файловой системы. Уникален в пределах тома. - BirthVolumeId
Идентификатор тома, на котором был создан файл. - BirthObjectId
Идентификатор файла при создании. Значение может отличаться от ObjectId. - DomainId
Зарезервировано. Не используется.
Поле ObjectId собственно и является идентификатором файла, а три других поля — дополнительные. Их содержимое можно в совокупности рассматривать просто как буфер данных размером 48 байт, в котором можно хранить произвольную информацию.
Просмотр содержимого идентификатора файла можно произвести в программе NTFS Stream Explorer. Для этого нужно открыть в ней файл, найти в списке потоков $OBJECT_ID и открыть его двойным кликом. Откроется окно просмотра, в котором можно увидеть содержимое четырёх GUID.
В операционной системе Windows 7 идентификатор появляется у файла, если создать обыкновенный ярлык, указывающий на него. После этого файл можно переместить в любое место в пределах тома. При запуске ярлыка файл не потеряется, он откроется из нового расположения. При запуске ярлыка система сначала пытается запустить файл по пути, который прописан в ярлыке. Если по этому пути файла уже нет, выполняется получение нового пути файла по его идентификатору и успешное открытие, если файл не покидал пределы диска.
Управление идентификаторами файлов в системе происходит с помощью WinAPI функции DeviceIoControl. Для некоторых операций потребуются привилегии SE_BACKUP_PRIVILEGE и SE_RESTORE_PRIVILEGE, а файлы нужно открывать с флагом FILE_FLAG_BACKUP_SEMANTICS.
Для создания или получения существующего идентификатора файла есть код FSCTL_CREATE_OR_GET_OBJECT_ID.
Если у файла нет идентификатора, он будет создан и помещён в Obj, если идентификатор есть, он будет прочитан и тоже помещён в Obj.
Если необходимо создать файловый идентификатор вручную, то есть полностью самостоятельно задать все 64 байта, не доверяя генерацию идентификатора системе, нужно воспользоваться методом записи данных в идентификатор через FSCTL_SET_OBJECT_ID
Идентификатор можно удалить. Делается это при помощи кода FSCTL_DELETE_OBJECT_ID.
Расширенную часть идентификатора (поле Extended структуры OBJECTID_ATTRIBUTE) можно переписать своими собственными данными. Для этого есть код FSCTL_SET_OBJECT_ID_EXTENDED. Таким образом становится возможно использовать object id как хранилище небольшого объёма метаданных.
Такую операцию позволяет выполнять NTFS Stream Explorer, начиная с версии 1.06. На картинке расширенная часть, подсвеченная жёлтым, переписана значениями, загруженными из внешнего файла:
Читайте также: