md5_file
файл. 1 гб. хочется верифицировать, но md5_file слишком уж избыточно
хотелось бы как-то вроде md5(file_get_contents(первый мбайт).file_get_contents(последний мбайт))
только вот что взять за $offset у file_get_contents -непонятно, так как размер файла в разных файловых системах-разный, и, соответственно, ответ будет зависеть от этого, что не айс.
Есть, конечно, вариант с курсором бегать.. а еще есть идеи?
хотелось бы как-то вроде md5(file_get_contents(первый мбайт).file_get_contents(последний мбайт))
только вот что взять за $offset у file_get_contents -непонятно, так как размер файла в разных файловых системах-разный, и, соответственно, ответ будет зависеть от этого, что не айс.
Есть, конечно, вариант с курсором бегать.. а еще есть идеи?
filesize() Ну и имхо такого будет недостаточно для идентификации Ещё в нагрузку бы проверку crc прикрутить.
filesize() нельзя, так как он разный в разный файловых системах.
в смысле для одного и того же файла результат будет разный в разный файловых системах
Цитата: RootPass
в смысле для одного и того же файла результат будет разный в разный файловых системах
С какой стати?
В разных файловых системах (с разным размером кластера) файл может занимать разный объём (разное количество кластеров), но размер файла от этого не изменится.
С такой стати.
Народ, это в два счета проверяется. filesize() это не характеристика файла.
Народ, это в два счета проверяется. filesize() это не характеристика файла.
Цитата: RootPass
С такой стати.
Народ, это в два счета проверяется. filesize() это не характеристика файла.
Народ, это в два счета проверяется. filesize() это не характеристика файла.
*facepalm*
Цитата: RootPass
С такой стати.
Народ, это в два счета проверяется. filesize() это не характеристика файла.
Народ, это в два счета проверяется. filesize() это не характеристика файла.
То есть md5 хэш у файла одинаковый в разных ОС и ФС, а размер разный?
:facepalm:
господитыбожемой. запускаем, проверяем, идем читать учебник.
специально для facepalm любителей.
невинда
Size: 1286874
MD5: d9a365b4ef0afd88108fb5e08bf2f7a6
винда
Size: 1309687
MD5: d9a365b4ef0afd88108fb5e08bf2f7a6
use Digest::MD5;
$ctx = Digest::MD5->new;
open(FILL,"test.txt");
$ctx->addfile(*FILL);
my $filesize = -s "test.txt";
print "Size: $filesize\n";
print "MD5: ".$ctx->hexdigest."\n";
специально для facepalm любителей.
невинда
Size: 1286874
MD5: d9a365b4ef0afd88108fb5e08bf2f7a6
винда
Size: 1309687
MD5: d9a365b4ef0afd88108fb5e08bf2f7a6
use Digest::MD5;
$ctx = Digest::MD5->new;
open(FILL,"test.txt");
$ctx->addfile(*FILL);
my $filesize = -s "test.txt";
print "Size: $filesize\n";
print "MD5: ".$ctx->hexdigest."\n";
Если задуматься хоть на минуту, можно понять, почему так.
В бинарном режиме файл открывай, а не в текстовом.
господи. файл открывается для md5, для получения размера файла ФАЙЛ не открывается. код смотрите.
binmode(FILL);
результат тот же.
binmode(FILL);
результат тот же.
Проверь свои файлы.
:facepalm:
:facepalm:
уважаемый, вы бы хоть не позорились еще больше.
md5 одинаковый. видите? что это значит? вы не понимаете.
md5 одинаковый. видите? что это значит? вы не понимаете.
Код:
#!/usr/bin/perl
my $filesize = -s $ARGV[0];
print "Size: $filesize\n";
my $filesize = -s $ARGV[0];
print "Size: $filesize\n";
вы не понимаете. Ни-че-го. текстовый файл смотрите, да.
Текстовый файл.
[COLOR="white"]ПыСы хватит тут тролить.[/COLOR]
[COLOR="white"]ПыСы хватит тут тролить.[/COLOR]
Аникейшик вы. Вот жопу оторвать и прочитать, почему так-не судьба? Так и останетесь неучем.
Где прочитать-то?Ты не написал,где это читать,с какой стати разные размеры
Единственное,что могу предположить–сжатие NTFS
Единственное,что могу предположить–сжатие NTFS
Аргументированных доводов уже не осталось?
:trollface:
@pixo $oft, GetFileSize даже со сжатием возвращает реальный размер файла, а не сжатый, не думаю что перловский или пхпшный интерпретатор для получения размера файла использует GetCompressedFileSize. Темболее у тс'а файл под виндой больше чем под никсами. Единственное что я могу предположить - под виндой файл сохраняется с 0x0d0a для переноса а у никсов 0x0a отсюда и разный размер. Тогда непонятно почему мд5 одинаковое.
:trollface:
@pixo $oft, GetFileSize даже со сжатием возвращает реальный размер файла, а не сжатый, не думаю что перловский или пхпшный интерпретатор для получения размера файла использует GetCompressedFileSize. Темболее у тс'а файл под виндой больше чем под никсами. Единственное что я могу предположить - под виндой файл сохраняется с 0x0d0a для переноса а у никсов 0x0a отсюда и разный размер. Тогда непонятно почему мд5 одинаковое.
RootPass, т.е. ты хочешь сказать, что в файл было записано N байт, и в какой-то другой файловой системе вместо N байт в нем станет M? :) Кто его порежет, расскажи?
P.S. Коль уж на то пошло, покажи свой файл, на котором у тебя такие классные результаты получаются.
P.S. Коль уж на то пошло, покажи свой файл, на котором у тебя такие классные результаты получаются.
Могу хамовитому учёному топикстартеру посоветовать почитать про fopen и, что важно, fseek...
Я вот только не знаю, сжирает ли fopen весь файл в опреативу или просто открывает его для чтения\записи не занимая памяти, а лишь пристваивая переменную и обеспечивая обращение к файлу последующими командами...
Вижу так:
1. Открываем файл для чтения
2. Читаем первые 1024 байта
3. Перемещаемся fseek'ом в конец -1024 байта
4. читаем их.
5. объединяем строки
6. добавляем в конец размер файла (размер самого файла не зависит от ОС. ЗАвисит только занимаемое место за диске, т.е. filesize() один и тот же будет).
7. Считаем MD5...
В целом, неплохая верификация...
А вообще мне понравилась теория про блуждающие байты, саморазрастающиеся файлы. Скайнет не дремлет...
Я вот только не знаю, сжирает ли fopen весь файл в опреативу или просто открывает его для чтения\записи не занимая памяти, а лишь пристваивая переменную и обеспечивая обращение к файлу последующими командами...
Вижу так:
1. Открываем файл для чтения
2. Читаем первые 1024 байта
3. Перемещаемся fseek'ом в конец -1024 байта
4. читаем их.
5. объединяем строки
6. добавляем в конец размер файла (размер самого файла не зависит от ОС. ЗАвисит только занимаемое место за диске, т.е. filesize() один и тот же будет).
7. Считаем MD5...
В целом, неплохая верификация...
А вообще мне понравилась теория про блуждающие байты, саморазрастающиеся файлы. Скайнет не дремлет...
Alexander92,да мы вообще тупые,ты чо.Да ты в корне неправ!Файл никто не порежет,в другой ФС он просто разрастётся:)
Та да, куда уж нам такое понять. :)
Кто последний в очереди за попкорном?
Поупражнялись в остроумии, товарищи аникейщики? Ок.
[ATTACH=CONFIG]5093[/ATTACH][ATTACH=CONFIG]5094[/ATTACH]
вот два скрина. что мы видим? два совпадающих мд5, два разных размера.
О чем нам говорит два одинаковых мд5? о том, что эти файлы могут быть разными с вероятностью 1/(256 в 16-ой степени), как гласит нам тервер(если не поняли, что я написал-просто поверьте или читайте про мд5). так что эти файлы одинаковы.
Теперь к вопросу, почему размеры разные. Потому что filesize(), -s, ls -l и прочее не ставят курсор в начало файла, и делают ++, как вам кажется.
Любой из вас(ну не любой, конечно, а кто еще не потерял способность учиться) может написать для *nix свою filesystem. ноу проблем. и в ней размер все файлов может быть 1 байт. Бога ради. или 1 мбайт. нивапрос. (count)+1-да пожалуйста. размер файла вообще не для вас. Он для других целей.
Поэтому в разных файловых системах размер файла будет разный. Потому что это разные файловые системы! а вот мд5 одинаковый. потому что он считается, а не спрашивается.
Понимаете?
[ATTACH=CONFIG]5093[/ATTACH][ATTACH=CONFIG]5094[/ATTACH]
вот два скрина. что мы видим? два совпадающих мд5, два разных размера.
О чем нам говорит два одинаковых мд5? о том, что эти файлы могут быть разными с вероятностью 1/(256 в 16-ой степени), как гласит нам тервер(если не поняли, что я написал-просто поверьте или читайте про мд5). так что эти файлы одинаковы.
Теперь к вопросу, почему размеры разные. Потому что filesize(), -s, ls -l и прочее не ставят курсор в начало файла, и делают ++, как вам кажется.
Любой из вас(ну не любой, конечно, а кто еще не потерял способность учиться) может написать для *nix свою filesystem. ноу проблем. и в ней размер все файлов может быть 1 байт. Бога ради. или 1 мбайт. нивапрос. (count)+1-да пожалуйста. размер файла вообще не для вас. Он для других целей.
Поэтому в разных файловых системах размер файла будет разный. Потому что это разные файловые системы! а вот мд5 одинаковый. потому что он считается, а не спрашивается.
Понимаете?
все, дальше вам на opennet.
У вас дикие представления о файловой системе, если вы считаете, что файл размером в 1 байт-это где-то на винте 8 битов лежат.
У вас дикие представления о файловой системе, если вы считаете, что файл размером в 1 байт-это где-то на винте 8 битов лежат.
Цитата: RootPass
У вас дикие представления о файловой системе, если вы считаете, что файл размером в 1 байт-это где-то на винте 8 битов лежат.
Странно... Я всегда думал, что 1 байт - это 8 бит... Оказывается - нет...
Что вы вообще знаете о файловых систмах, кластерах??
Цитата: RootPass
все, дальше вам на opennet.
У вас дикие представления о файловой системе, если вы считаете, что файл размером в 1 байт-это где-то на винте 8 битов лежат.
У вас дикие представления о файловой системе, если вы считаете, что файл размером в 1 байт-это где-то на винте 8 битов лежат.
Молодой человек, почему вы игнорировали то, что я вам выше сказал?
Ваша задача была бы интересной, если бы пошла по другому пути. Например, можно было бы рассуждать об использовании внешних утилит для подсчёта контрольной суммы (md5sum), как вариант можно эту задачу вообще вынести в отдельный процесс, который помечал бы файл как прошедший верификацию или проваливший её. Это было бы интересно, тут можно было бы думать об экономии ресурсов, об отложенных вызовах.
Вы же упрямо решили пойти по ложному пути, зачем? Вам так проще решить задачу? Прислушайтесь к тому, что вам говорят. Здесь у многих достаточный опыт, чтобы с улыбкой смотреть на ваш гонор. Между тем, предлагаю оставить глупости и заниматься делом.
Цитата:
Я всегда думал, что 1 байт - это 8 бит... Оказывается - нет...
Между прочим, это общепринято, что 1 байт = 8 бит. Когда-то давно было, что 1 байт = 6 бит.
Цитата: Kesano
Странно... Я всегда думал, что 1 байт - это 8 бит... Оказывается - нет...
Что вы вообще знаете о файловых систмах, кластерах??
Что вы вообще знаете о файловых систмах, кластерах??
1 байт -это 8 бит, это факт.
Вы вообще прочитали, что я написал? То есть вам кажется, что для хранения файла в 1 байт размером - вам 8 бит понадобится на винте? Вы неправы.
Цитата: RootPass
Любой из вас(ну не любой, конечно, а кто еще не потерял способность учиться) может написать для *nix свою filesystem. ноу проблем. и в ней размер все файлов может быть 1 байт. Бога ради. или 1 мбайт. нивапрос.
Т.е. вы считаете, что разработчикам операционок было настолько крепко нечего делать, что они чисто for fun делали какой-то левый размер файла? Обычно нормальные люди, говоря слово "размер", подразумевают таки размер.
Нет, но я еще раз вам повторяю-на всем многообразии файловых систем, да даже на 5 основных используемых файловых систем совпадение не гаранируется, ну поймите вы это.
Цитата: Romik
Молодой человек, почему вы игнорировали то, что я вам выше сказал?
Ваша задача была бы интересной, если бы пошла по другому пути. Например, можно было бы рассуждать об использовании внешних утилит для подсчёта контрольной суммы (md5sum), как вариант можно эту задачу вообще вынести в отдельный процесс, который помечал бы файл как прошедший верификацию или проваливший её. Это было бы интересно, тут можно было бы думать об экономии ресурсов, об отложенных вызовах.
Вы же упрямо решили пойти по ложному пути, зачем? Вам так проще решить задачу? Прислушайтесь к тому, что вам говорят. Здесь у многих достаточный опыт, чтобы с улыбкой смотреть на ваш гонор. Между тем, предлагаю оставить глупости и заниматься делом.
Ваша задача была бы интересной, если бы пошла по другому пути. Например, можно было бы рассуждать об использовании внешних утилит для подсчёта контрольной суммы (md5sum), как вариант можно эту задачу вообще вынести в отдельный процесс, который помечал бы файл как прошедший верификацию или проваливший её. Это было бы интересно, тут можно было бы думать об экономии ресурсов, об отложенных вызовах.
Вы же упрямо решили пойти по ложному пути, зачем? Вам так проще решить задачу? Прислушайтесь к тому, что вам говорят. Здесь у многих достаточный опыт, чтобы с улыбкой смотреть на ваш гонор. Между тем, предлагаю оставить глупости и заниматься делом.
Я вам и так скажу, когда внешние утилиты лучше встроенных md5 и md5_file. Раздел-на файлах больше 1 мбайта, для файлов под 1 гиг внешние однозначно рулят, для мелких по понятным причинам-встроенные. Тестирование я видел, результаты запомнил. Найду ссылку-скину.
В общем, программку я вам проверочную сделал, причины написал, почему так.
Не верите мне-вперед на opennet или linuxquestions, спросите, верно ли, что во всех filesystem одинаковый размер у одного и того же файла. И напишите, что вы крутой прогер.
Когда тамошая общественность перестанет угорать над вами, может чего-то и уясните для себя.
Кому интересно-пусть учится, остальные-бай, аникейшики.
Не верите мне-вперед на opennet или linuxquestions, спросите, верно ли, что во всех filesystem одинаковый размер у одного и того же файла. И напишите, что вы крутой прогер.
Когда тамошая общественность перестанет угорать над вами, может чего-то и уясните для себя.
Кому интересно-пусть учится, остальные-бай, аникейшики.
Любопытно, любопытно.
В кое-то веке топикстартер брызжет слюной, а месные нервно курят в сторонке!?
Вам, уважаемый RootPass я бы посоветовал, в первую очередь, проявлять елементарное уважение к окружающим, т.к. именно Вы пришли за ответами в общество.
Меня так сильно заинтересовал обсуждаемый феноменъ, что затряслись коленки, вспотел лоб, и заметно вырос уровень адреналина в крови..
Вот как хочется с размаху удариться в холивар для достижения истины!
Так вот:
Во-первых: Функция, которая возвращает размер содержимого файла, зависящий от ФС совершенно бесполезна для тех целей, для которых её используют. Совершенно очевидный бред.
Во-вторых: Если Вы считаете, что это размер, распределённого пространства на винте (т.е. целое число кластеров), то Вы опять-таки неправы. Никогда, ни при каких обстоятельствах (кроме багов и случаев любительских ФС `for fun`) размер кластера не может быть не кратным размеру сектора (512 байт), т.е. нечетным (в часности). А у Вас в примере размер файла - 1309687 даже нечетный. Возможно мои суждения ошибочны, но это маловероятно.
Как уже заметил `arrjj`, такому гиганту мысли, как Вы, не нужно объяснять, что в качестве EOL в винде используется CR+LF, в *nix (кроме mac) LF и CR у мака. В вашем примерчике, производится неявное пред-преобразование (текстовый режим CR+LF (0x0D0A) -> LF (0x0A ~ '\n')). А потому и получается одинаковый результат на выходе.
Стоит заметить очевидное для нас необразованных - у шелла винды (диалог `свойства`) есть два поля: `Размер` и `На диске`. Первый показывает фактический `полезный объём` данных в файле, который не зависит ни от чего, кроме `фактического полезного объёма данных в файле`. Второй же показывает использованное файлом дисковое пространство + еще кое-что (опционально).
Для справки стоит заметить, что функция GetFileSize получает в качестве первого аргумента дескриптор файла (т.е. файл обязательно открывается перед получением размера). Как уже было замечено, существует также функции GetCompressedFileSize, а также FindFirstFile/FindNextFile/FindClose, которые позволяют, явно не открывая файл, получить его размер.
Но я готов поставить на кон свой левый носок, что perl во всех его реализациях использует в причинном контексте исключительно GetFileSize или враппы этой функции из других библиотек (в частности стд. библиотеки С). Пруфлинк пришлю позже, когда изволю перелопатить исходники. ;)
Рассудительный человек не превращается в епилептика, когда слышит что он неправ, а осмысляет спорный вопрос с семикратным вниманием. Так, что не считайте своей личной победой то, что вам удалось ввести в ступор целую группу людей.
[ATTACH=CONFIG]5098[/ATTACH][ATTACH=CONFIG]5099[/ATTACH][ATTACH=CONFIG]5101[/ATTACH][ATTACH=CONFIG]5100[/ATTACH][ATTACH=CONFIG]5096[/ATTACH]
В кое-то веке топикстартер брызжет слюной, а месные нервно курят в сторонке!?
Вам, уважаемый RootPass я бы посоветовал, в первую очередь, проявлять елементарное уважение к окружающим, т.к. именно Вы пришли за ответами в общество.
Меня так сильно заинтересовал обсуждаемый феноменъ, что затряслись коленки, вспотел лоб, и заметно вырос уровень адреналина в крови..
Вот как хочется с размаху удариться в холивар для достижения истины!
Так вот:
Во-первых: Функция, которая возвращает размер содержимого файла, зависящий от ФС совершенно бесполезна для тех целей, для которых её используют. Совершенно очевидный бред.
Во-вторых: Если Вы считаете, что это размер, распределённого пространства на винте (т.е. целое число кластеров), то Вы опять-таки неправы. Никогда, ни при каких обстоятельствах (кроме багов и случаев любительских ФС `for fun`) размер кластера не может быть не кратным размеру сектора (512 байт), т.е. нечетным (в часности). А у Вас в примере размер файла - 1309687 даже нечетный. Возможно мои суждения ошибочны, но это маловероятно.
Как уже заметил `arrjj`, такому гиганту мысли, как Вы, не нужно объяснять, что в качестве EOL в винде используется CR+LF, в *nix (кроме mac) LF и CR у мака. В вашем примерчике, производится неявное пред-преобразование (текстовый режим CR+LF (0x0D0A) -> LF (0x0A ~ '\n')). А потому и получается одинаковый результат на выходе.
Стоит заметить очевидное для нас необразованных - у шелла винды (диалог `свойства`) есть два поля: `Размер` и `На диске`. Первый показывает фактический `полезный объём` данных в файле, который не зависит ни от чего, кроме `фактического полезного объёма данных в файле`. Второй же показывает использованное файлом дисковое пространство + еще кое-что (опционально).
Для справки стоит заметить, что функция GetFileSize получает в качестве первого аргумента дескриптор файла (т.е. файл обязательно открывается перед получением размера). Как уже было замечено, существует также функции GetCompressedFileSize, а также FindFirstFile/FindNextFile/FindClose, которые позволяют, явно не открывая файл, получить его размер.
Но я готов поставить на кон свой левый носок, что perl во всех его реализациях использует в причинном контексте исключительно GetFileSize или враппы этой функции из других библиотек (в частности стд. библиотеки С). Пруфлинк пришлю позже, когда изволю перелопатить исходники. ;)
Рассудительный человек не превращается в епилептика, когда слышит что он неправ, а осмысляет спорный вопрос с семикратным вниманием. Так, что не считайте своей личной победой то, что вам удалось ввести в ступор целую группу людей.
[ATTACH=CONFIG]5098[/ATTACH][ATTACH=CONFIG]5099[/ATTACH][ATTACH=CONFIG]5101[/ATTACH][ATTACH=CONFIG]5100[/ATTACH][ATTACH=CONFIG]5096[/ATTACH]
Цитата: Kesano
Странно... Я всегда думал, что 1 байт - это 8 бит... Оказывается - нет...
Не всегда. И даже не обязательно. Вообще количество бит в байте может быть любым, все зависит от архитектуры. И так уж исторически сложилось, что одной из самых массовых стала архитектура с 8-тным байтом. Кстати, для определенности некоторые называют его октедом, что бы явно подчеркнуть, что это именно восьмибитный байт.
Ну и по традиции я как всегда кидаю ссылку на очень малоизвестные сайты, которые помогают раскрыть суть вопроса
http://ru.wikipedia.org/wiki/Байт
http://ru.wikipedia.org/wiki/Байт
Цитата: RootPass
1 байт -это 8 бит, это факт.
Вы вообще прочитали, что я написал? То есть вам кажется, что для хранения файла в 1 байт размером - вам 8 бит понадобится на винте? Вы неправы.
Вы вообще прочитали, что я написал? То есть вам кажется, что для хранения файла в 1 байт размером - вам 8 бит понадобится на винте? Вы неправы.
Я вообще не шарю в перле и не до конца понимаю, что вы хотите написать...
Но и вашего сообщения, я просто прошу вас определиться: Что вы хотите выяснить?
1. Размер файла.
2. Занимаемое на жёстком диске место.
Размер файла в 99,9% является постоянным, потому что это комплектный набор байтов, обуславливающий его содержимое.
Занимаемое место на диске - переменное значение, а потому вычислять его глупо.
Выдуманная вообще проблема, если бы размер файла менялся на разных ос\файловых системах, такая замечательная вещь как торренты не работала бы вообще, потому что там всё на хэшах...
Я похоже зря провел несколько лет работая в областях хранения и восстановления информации :)
Цитата:
$md5->addfile($io_handle)
The $io_handle will be read until EOF and its content appended to the message we calculate the digest for. The return value is the $md5 object itself.
The addfile() method will croak() if it fails reading data for some reason. If it croaks it is unpredictable what the state of the $md5 object will be in. The addfile() method might have been able to read the file partially before it failed. It is probably wise to discard or reset the $md5 object if this occurs.
In most cases you want to make sure that the $io_handle is in binmode before you pass it as argument to the addfile() method.
The $io_handle will be read until EOF and its content appended to the message we calculate the digest for. The return value is the $md5 object itself.
The addfile() method will croak() if it fails reading data for some reason. If it croaks it is unpredictable what the state of the $md5 object will be in. The addfile() method might have been able to read the file partially before it failed. It is probably wise to discard or reset the $md5 object if this occurs.
In most cases you want to make sure that the $io_handle is in binmode before you pass it as argument to the addfile() method.