Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Системное программирование и WinAPI > Уникальный идентификатор файла

Автор: freezeman 6.4.2012, 13:01

Всем привет! Подскажите, пожалуйста, в структуре BY_HANDLE_FILE_INFORMATION есть два параметра nFileIndexLow и nFileIndexHigh младший и старший идентификатор файла, что означает младший/старший? Я же могу однозначно идентифицировать конкретный файл по этим параметрам?

Автор: 12usver12 6.4.2012, 13:16

в мсдне, вроде как , исчерпывающе описано  Цитата(msdn) http://msdn.microsoft.com/en-us/library/windows/desktop/aa363788(v=vs.85).aspx

Автор: freezeman 6.4.2012, 13:18

Цитата(12usver12 @ 6.4.2012,  13:16) в мсдне, вроде как , исчерпывающе описано  Цитата(msdn) http://msdn.microsoft.com/en-us/library/windows/desktop/aa363788(v=vs.85).aspx Плохо...как тогда по-другому идентифицировать файл, кроме пути к нему на диске? Добавлено через 5 минут и 36 секунд Если сделать MD5 или CRC16? Для работы программы критична скорость работы, то есть получение хэша файла не скажется ли сильно на производительности?

Автор: 500mhz 6.4.2012, 13:43

Где идентифицировать? На диске или как процесс? Добавлено через 3 минуты и 2 секунды Сорри ступил ))) "на диске" Ну если файловая система ntfs то можно инфу некую о файле в поток записать )

Автор: freezeman 6.4.2012, 13:52

Цитата(500mhz @ 6.4.2012,  13:43) Где идентифицировать? На диске или как процесс? Добавлено @ 13:46 Сорри ступил ))) "на диске" Ну если файловая система ntfs то можно инфу некую о файле в поток записать ) Я вот подумал, что не нужно делать хэш всего файла, а только пути к нему, так и быстрее проверять...

Автор: 12usver12 6.4.2012, 13:57

Цитата(freezeman) Плохо  читаем плохо. ничего сложного, для идеального решения тебе нужно сформировать этот Id через 128-битовое число:   Цитата(msdn) The identifier (low and high parts) and the volume serial number uniquely identify a file on a single computer. To determine whether two open handles represent the same file, combine the identifier and the volume serial number for each file and compare them.

Автор: Akira 6.4.2012, 13:57

Нет, ничего такого нет, все делают контрольные суммы. Если файл не большой то оверхеда практически нет. 12usver12 Не надежно, кто даст гарантию, что у Васи будет работать.

Автор: freezeman 6.4.2012, 14:02

Цитата(12usver12 @ 6.4.2012,  13:57) Цитата(freezeman) Плохо  читаем плохо. ничего сложного, для идеального решения тебе нужно сформировать этот Id через 128-битовое число:   Цитата(msdn) The identifier (low and high parts) and the volume serial number uniquely identify a file on a single computer. To determine whether two open handles represent the same file, combine the identifier and the volume serial number for each file and compare them. А это тогда что? Цитата File IDs are not guaranteed to be unique over time, because file systems are free to reuse them.

Автор: freezeman 6.4.2012, 14:22

Цитата(500mhz @ 6.4.2012,  13:43) Где идентифицировать? На диске или как процесс? Добавлено @ 13:46 Сорри ступил ))) "на диске" Ну если файловая система ntfs то можно инфу некую о файле в поток записать ) Нет, немного не поняли вы вопрос, мне нужно идентифицировать уникально файл. Получил по HANDLE файла его путь, но сравнение будет выполняться долго. Если у параметров файла был бы уникально его идентифицирующий, то нет проблем все нормально, но нет  Скорее всего лучше будет использовать CRC16 для кодирования имени файла, а потом сравнивать только полученные ключи...

Автор: 500mhz 6.4.2012, 14:36

а если 2 одинаковых файла а имена только разные?

Автор: freezeman 6.4.2012, 14:43

Цитата(500mhz @ 6.4.2012,  14:36) а если 2 одинаковых файла а имена только разные? Я думал над этим, тогда придется делать хэш по содержимому файла, но мне кажется, что при большом объеме времени много уходить будет...

Автор: Akira 6.4.2012, 14:58

freezeman >> CRC16 Ты пытаешься экономить на спичках можешь спокойно использовать CRC32  или MD5.   По поводу содержимого файла, а если файл часто используем и дописывается?

Автор: 500mhz 6.4.2012, 15:03

Akira а если у меня коллекция mkv фильмов по 1,5 гига каждый, каждый раз считать crc или md будет накладно.

Автор: freezeman 6.4.2012, 15:10

Цитата(Akira @ 6.4.2012,  14:58) freezeman >> CRC16 Ты пытаешься экономить на спичках можешь спокойно использовать CRC32  или MD5.   По поводу содержимого файла, а если файл часто используем и дописывается?   А я не знаю скорость работы, что лучше CRC16, CRC32 или MD5. Если у файла изменяется содержимое, это никак не влияет на работу. Этот измененный файл просто не будет учитываться, потом вытеснится из памяти (если вы помните мою предыдущую тему "Виртуальная память", поймете о чем я), и если требуется опять туда будет занесен. Хотя, если стоит подумать о изменении файла в ОП сразу после изменения содержимого файла, но это потом, если успею...

Автор: 500mhz 6.4.2012, 15:13

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

Автор: freezeman 6.4.2012, 15:17

Цитата(500mhz @ 6.4.2012,  15:03) Akira а если у меня коллекция mkv фильмов по 1,5 гига каждый, каждый раз считать crc или md будет накладно. Конечно, накладно. Во-первых, есть ограничение на объем и такие файлы не будут учитываться, скорее всего, если только оперативки гигов 16 не будет... Во-вторых, скорее всего откажусь от хэширования всего содержимого, как подчеркнул Akira, если часто изменяется содержимое файла, то хэш меняется, что требует дополнительного времени на контроль этого момента. Если файлы с одинаковым содержимым и разными именами, то просто обходить путем проверки хэша  на момент проверки Добавлено через 4 минуты и 33 секунды Цитата(500mhz @ 6.4.2012,  15:13) На мой взгляд самое удобное при наличии NTFS как файловой системы просто пронумеровать файлы к примеру и каждому файлу присвоить уникальный номер с записью этих данных в поток. Таким образом файл можно будет изменять, переносить, делать что угодно, идентификатор останется неизменным. Но как их нумеровать? Просто таблицу соответствия или есть функция winapi? Хорошая идея, кстати, если только нумерация не собьется

Автор: 500mhz 6.4.2012, 15:22

freezeman,  http://otvety.google.ru/otvety/thread?tid=0e956353239996eb а в каспере не дураки сидят ))) используй потоки и будет тебе счастье

Автор: freezeman 6.4.2012, 15:28

Цитата(500mhz @ 6.4.2012,  15:22) freezeman,  http://otvety.google.ru/otvety/thread?tid=0e956353239996eb а в каспере не дураки сидят ))) используй потоки и будет тебе счастье Хорошая идея. Я могу запустить отдельный поток который будет выполнять нумерацию файла, или же в процессе доступа к этому файлу (У меня идет перехват обращений к файлам). Но в любом случае, как проводить идентификацию iSwift?

Автор: Akira 6.4.2012, 15:31

500mhz >> а если у меня коллекция mkv фильмов по 1,5 гига каждый, каждый раз считать crc или md будет накладно. И я о том же, тем более содержимое может меняться. >> а в каспере не дураки сидят ))) Глядя на исходники каспера я бы так не утверждал.   А так, да, потоки можно заюзать.

Автор: freezeman 6.4.2012, 15:34

Цитата(Akira @ 6.4.2012,  15:31) 500mhz >> а если у меня коллекция mkv фильмов по 1,5 гига каждый, каждый раз считать crc или md будет накладно. И я о том же, тем более содержимое может меняться. >> а в каспере не дураки сидят ))) Глядя на исходники каспера я бы так не утверждал.   А так, да, потоки можно заюзать. А вы видели исходники?))

Автор: 500mhz 6.4.2012, 15:39

не, ты не понял не многа видимо, потоки в НТФС это не потоки в процессе. это определенного вида данные которые привязаны к файлу. размер и тип не ограничен, хоть гигабайт.  я вижу это так, есть директория с файлами, пробегаемся по всем файлам и нумеруем от 1 до Х, номер файла пишем в поток. вот тут внятно написано http://alexeivasin.com/post/ntfs-ads.aspx Добавлено через 1 минуту и 35 секунд Akira    меня на форуме каспера уже давно забанили за креатив.

Автор: freezeman 6.4.2012, 15:47

Цитата не, ты не понял не многа видимо, потоки в НТФС это не потоки в процессе. да, не понял;) Думал к конкретному файлу указать уникальный ID в параметрах что-ли. Цитата это определенного вида данные которые привязаны к файлу. размер и тип не ограничен, хоть гигабайт.  А как вы думаете, не получится ли это слишком затратно для системы? Просто у меня этих обращений к файлам будет ооочень много...

Автор: Akira 6.4.2012, 15:50

freezeman >> А вы видели исходники?))   Ога, тот еще трэш один клиф.сус доставляет не говоря об остальном.   Нет, не будет, хотя для твоей задачи достаточно поти и имени. 500mhz Мну тоже забанен, что еще можно от ахтунг лаба ожидать.

Автор: freezeman 6.4.2012, 15:54

Цитата(Akira @ 6.4.2012,  15:50) freezeman >> А вы видели исходники?))   Ога, тот еще трэш один клиф.сус доставляет не говоря об остальном.   Вспомнил ролик презентации)) http://www.youtube.com/watch?v=_hOmQy4H6CM Видимо эта побочный эффект их кода    Хотя, что антивирус все равно №1, не сомневаюсь...

Автор: 500mhz 6.4.2012, 16:00

http://www.youtube.com/watch?v=XIgnVqLBSw4 этот круче )

Автор: freezeman 6.4.2012, 16:07

Цитата(500mhz @ 6.4.2012,  16:00) http://www.youtube.com/watch?v=XIgnVqLBSw4 этот круче ) Аххаахх, нужно было бы ещё добавить спец. эффекты на подобии в убойного футбола    Но все же, может и корявый код, но они лидеры на рынке в России точно, а может и в их числе в мире.

Автор: 12usver12 6.4.2012, 16:39

Определись что тебе нужно: 1) Уник. id файла по его местоположению в системе    - тогда покатит контрольная сумма пути файла (учитываем что в crc  есть коллизии, вероятность небольшая но все же) 2) Уник  id файла по местоположению + содержимому - тогда лучше использовать эти индексы Цитата(Akira) Не надежно, кто даст гарантию, что у Васи будет работать С чего решили, что ненадежно ? в msdn это не написано, это же не использование недокументированных функций. XP включительно и выше должно быть надежно. Цитата File IDs are not guaranteed to be unique over time, because file systems are free to reuse them. In some cases, the file ID for a file can change over time. In the FAT file system, the file ID is generated from the first cluster of the containing directory and the byte offset within the directory of the entry for the file. Some defragmentation products change this byte offset. (Windows in-box defragmentation does not.) Thus, a FAT file ID can change over time. Renaming a file in the FAT file system can also change the file ID, but only if the new file name is longer than the old one. In the NTFS file system, a file keeps the same file ID until it is deleted. You can replace one file with another file without changing the file ID by using the ReplaceFile function. However, the file ID of the replacement file, not the replaced file, is retained as the file ID of the resulting file. я так понимаю, что не гарантируется если FAT система, а их процент ничтожно маленький. p.s. ни разу не пробовал данный метод, но для коротких промежутков времени должно быть нормально, как мне кажется.

Автор: Akira 6.4.2012, 17:14

12usver12 >> С чего решили, что ненадежно? Да хотя бы из-за ховнософта. Были прициденты в практике, поэтому не надеюсь на Васю, что у него все в порядке на компе.

Автор: freezeman 6.4.2012, 17:33

Цитата Определись что тебе нужно: 1) Уник. id файла по его местоположению в системе    - тогда покатит контрольная сумма пути файла (учитываем что в crc  есть коллизии, вероятность небольшая но все же) 2) Уник  id файла по местоположению + содержимому - тогда лучше использовать эти индексы Я пока не решил, если смогу за выходные реализовать второй вариант, если нет, то первый сделаю, он проще... Цитата Цитата File IDs are not guaranteed to be unique over time, because file systems are free to reuse them. In some cases, the file ID for a file can change over time. In the FAT file system, the file ID is generated from the first cluster of the containing directory and the byte offset within the directory of the entry for the file. Some defragmentation products change this byte offset. (Windows in-box defragmentation does not.) Thus, a FAT file ID can change over time. Renaming a file in the FAT file system can also change the file ID, but only if the new file name is longer than the old one. In the NTFS file system, a file keeps the same file ID until it is deleted. You can replace one file with another file without changing the file ID by using the ReplaceFile function. However, the file ID of the replacement file, not the replaced file, is retained as the file ID of the resulting file. я так понимаю, что не гарантируется если FAT система, а их процент ничтожно маленький. Нужно точно будет проверить, если это так, то зачем все усложнять? Есть идентификатор файла и всё, и все эти хэши, альтернативные потоки только нагружать будут..

Автор: xvr 8.4.2012, 18:58

У ID в отдельном файловом потоке есть недостаток - этот поток запросто может потеряться при каком нибудь копировании файла

Автор: freezeman 8.4.2012, 22:57

Цитата(xvr @ 8.4.2012,  18:58) У ID в отдельном файловом потоке есть недостаток - этот поток запросто может потеряться при каком нибудь копировании файла Да еще и усложняет это задачу слишком, лучше будет просто хэш пути к файлу+время последнего изменения

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)