Программирование[9]

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

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

Естественно что питоновский подход сравнивая имя и размер с датой онли легче чем проверяя одинаковость файла.

moonfangtopich написал 5 минут назад:

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

 

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

Если "одинакового размера с длинным одинаковым началом", то нет 

блять я вам алгоритм дал 4 часа назад идите реализовывайте

На самом у нас тут миниатюра из ирл

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

А кант допустим выкатил хорошее решение, то всеравно боссу насрать на решение.

Так что победа за крысой очевидно  Учимся и мотаем на ус 

одинаковый размер и мтайм -> файлы одинаковые

разные размеры -> файлы разные

одинаковые рамзеры, разные мтаймы -> побайтовое сравнение чанков

эта хуйня будет лучше и быстрей, чем взятие хешей, во всех случаях, кроме случая с огромными файлами, у которых одинаковые начала и почему-то совпал размер (сами прикинете шанс, что это и есть наш случай?)

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

GoldRobot said 5 minutes ago:

на качество ему насрать

а ты докажешь, что здесь есть проблемы с качеством, подгавкивающая бездарность?

пацан попросил скрипт для удаления файлов

@

обсуждение на 10 страниц про сложность алгоритма и эдж кейсы

вся суть суть программистов из снг

100 копий порнофильма с разными концовками. Нужно проверить на дубликаты

moonfangtopich написал 17 минут назад:

одинаковый размер и мтайм -> файлы одинаковые

разные размеры -> файлы разные

одинаковые рамзеры, разные мтаймы -> побайтовое сравнение чанков

 

эта хуйня будет лучше и быстрей, чем взятие хешей, во всех случаях, кроме случая с огромными файлами, у которых одинаковые начала и почему-то совпал размер (сами прикинете шанс, что это и есть наш случай?)

 

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

GoldRobot написал 21 минуту назад:

на качество ему насрать

а ты докажешь, что здесь есть проблемы с качеством, подгавкивающая бездарность?

ты можешь и хэш брать от первых например 10 метров, лол

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

ну тогда пузырек имба

разрабы баз данных тоже видимо дауны, раз для больших количеств строк почему-то джоинят мердж джоином или хэш джоином, а не нестед лупами

глупые наверное

moonfangtopich написал 19 минут назад:

а ты докажешь, что здесь есть проблемы с качеством, подгавкивающая бездарность?

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

было бы что доказывать

питоновский подход такой питоновский подход

Kant написал 10 минут назад:

ты можешь и хэш брать от первых например 10 метров, лол

Тогда должна быть априорная инфа, что у все разных файлов разные первые 10 метров

GoldRobot said 2 minutes ago:

moonfangtopich said 23 minutes ago:

а ты докажешь, что здесь есть проблемы с качеством, подгавкивающая бездарность?

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

было бы что доказывать

 

питоновский подход такой питоновский подход

бля какой же ты безудержно отсталый, просто слов нет

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

============

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

Дегенерат, в документацию залезь того что ты применил, а потом на говно исходи

Боже, какой ты убогий человек

примеров не будет, я правильно понял? ничего удивительного

Один из плюсов питона это хорошая документация по стандартной библиотеке. Жаль питонщики читать не умеют...

У тебя черным по белому написано что сравнивается стата файла, а не файлы.

Цитата

If shallow is true, files with identical os.stat() signatures are taken to be equal. Otherwise, the contents of the files are compared.

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

нет, тыкни меня в ложные срабатывания

ЕДИНСТВЕННЫЙ способ этого достичь - это разным файлам с одинаковым размером программным способом выставить абсолютно одинаковый mtime. этот сценарий к реальности отношения не имеет, во всех остальных случаях скрипт отработает со 100%-ной точностью

твое дело попробовать доказать обратное

на всякий случай кину в топик нож

У меня через touch *.txt не получилось выставить. Это надо реально программным способом выставлять

(Pdb) print(s1)
(32768, 12681, 1590772228.8797364)
(Pdb) print(s2)
(32768, 12681, 1590772228.87924)

Ты буквально сам сейчас написал что бывают случаи когда твой код выдаст неверное говно. Тоесть вот он, не качественный код.

У mtime, как и у любой временной точки, есть разрешение. Оно может быть вплоть до секунд.

Я честно не ебу однозначно от чего оно зависит, и почему бывает по уебански, но в практике моего друга был sftp с разрешением 100мс, откуда они забирали cdr ки какие-то.

Короче, крыс, незнаю чего тебя бомбануло. Я же тебя похвалил вроде, а ты чето заточку точишь и ядом смазываешь. День хуевый?

GoldRobot написал 33 минуты назад:

в документацию залезь

читать сложнее чем писать