Алгоритм для определения идентификационных данных файла
Вы можете просто использовать состояние «использование», которое автоматически создаст и закроет соединение.
public object getQueryScaller(string sqlQuery)
{
object value = null;
using (SqlConnection conn = new SqlConnection(_connectionString))
{
using (SqlCommand cmd = new SqlCommand(sqlQuery, conn))
{
conn.Open();
value = cmd.ExecuteScalar();
}
}
return value;
}
Это автоматически решит проблему соединения, и вам не нужно будет о ней заботиться. просто передав параметр в функцию как оператор SQL, и он будет работать.
8 ответов
Как насчет того, чтобы хранить некоторые случайные целые числа ri и искать байты (ri модификация n), где n является размером файла? Для файлов с заголовками можно проигнорировать их сначала и затем сделать этот процесс на остающихся байтах.
Если Ваши файлы на самом деле довольно отличаются (не только различие в единственном байте где-нибудь, но и скажите, что отличающийся по крайней мере 1%), то случайный выбор байтов заметил бы это. Например, с 1%-м различием в байтах, 100 случайным байтам не удалось бы заметить с вероятностью 1/e ~ 37%; увеличение числа байтов, на которые Вы смотрите, заставляет эту вероятность понизиться экспоненциально.
Идея позади использования случайных байтов состоит в том, что они по существу гарантируются (хорошо, вероятностно говоря), чтобы быть столь же хорошими как любая другая последовательность байтов, кроме они не восприимчивы к некоторым проблемам с другими последовательностями (например, оказывающийся смотреть на каждый 256-й байт формата файла, где тот байт требуется, чтобы быть 0 или что-то).
Еще некоторый совет:
- Вместо того, чтобы захватить байты, захватите большие блоки для выравнивания по ширине стоимости поиска.
- Я всегда предлагал бы смотреть на первый блок или так файла. От этого можно определить тип файла и такой. (Например, Вы могли использовать
fileпрограмма.) - По крайней мере, взвесьте стоимость/преимущество чего-то как CRC всего файла. Это не так дорого как реальная криптографическая хеш-функция, но все еще требует чтения всего файла. Позитивный аспект - это, заметит однобайтовые различия.
Сделайте первый 128k, другой 128k в метке 1 МБ, другой 128k в метке 10 МБ, другой 128k в метке 100 МБ, другой 128k в метке 1000 МБ, и т.д. Поскольку размеры файла становятся больше, и становится более вероятно, что Вы сможете отличить два файла на основе одного только их размера, Вы хешируете меньшую и меньшую часть данных. Все под 128k заботится о полностью.
При объединении несколько слоев сравнения должны быть самыми быстрыми и масштабируемыми через диапазон файлов, которые Вы обсуждаете.
Первый уровень индексации является просто длиной файла.
Второй уровень является хешем. Ниже определенного размера это - хеш целого файла. Кроме того, да, я соглашаюсь с Вашей идеей алгоритма выборки. Проблемы, что я думаю, могли бы влиять на скорость выборки:
- Чтобы постараться не поражать расположенные с равными интервалами заголовки, которые могут быть очень подобными или идентичными, необходимо ступить в несоответствующее число, например: кратные числа начала или последовательных начал.
- Избегайте шагов, которые могли бы закончить тем, что встретились с обычными рекордными заголовками, поэтому если Вы получаете то же значение от своих демонстрационных байтов несмотря на другое местоположение, попытайтесь корректировать шаг со стороны другого начала.
- Справьтесь с аномальными файлами с большими фрагментами идентичных значений, или потому что они не кодируются изображения или просто заполняются пустыми указателями.
Хотите верьте, хотите нет, я использую галочки в течение прошлого времени записи для файла. Это столь дешево, как это добирается, и я должен все еще видеть столкновение между различными файлами.
Какие байты я должен выбрать для образца?
Я думаю, что попытался бы использовать некоторую арифметическую прогрессию как Числа Фибоначчи. Их легко вычислить, и у них есть уменьшающаяся плотность. Маленькие файлы имели бы более высокое демонстрационное отношение, чем большие файлы, и образец все еще пробежится через пятна в целом файле.
Ну, сначала необходимо изучить более глубоко то, как работают файловые системы. С какими файловыми системами Вы будете работать? Большинство файловых систем поддерживает вещи как жесткие ссылки и гибкие ссылки, и поэтому информация "имени файла" не обязательно хранится в метаданных самого файла.
На самом деле это - смысл наращиваемой многоуровневой файловой системы, что можно расширить его различными способами, сказать для поддержки сжатия или шифрования. Это - то, о чем "vnodes" - все. Вы могли на самом деле сделать это несколькими способами. Часть этого очень зависит от платформы, на которую Вы смотрите. Это намного более просто в системах UNIX/Linux, которые используют понятие VFS. Вы могли реализовать свой собственный слой на роще ext3, например, или что имеет Вас.
** После чтения Ваших редактирований, разветвитель больше вещей. Файловые системы уже делают это, как упомянуто прежде, с помощью вещей как inodes. Хеширование, вероятно, будет плохой идеей не только, потому что это дорого, но и потому что два или больше предварительных изображения могут добавить то же изображение; то есть то, что два совершенно различных файла могут иметь то же хешированное значение. Я думаю, что Вы действительно хотите сделать, использовать метаданные этого, файловая система уже выставляет. Это было бы более просто в системе с открытым исходным кодом, конечно.:)
Эта работа кажется, что могла быть эффективнее реализована на уровне файловой системы или с некоторым свободным приближением системы управления версиями (оба?).
Для рассматривания исходного вопроса Вы могли сохранить базу данных (размер файла, байты хешированный, хеш) для каждого файла и попытаться минимизировать число байтов, хешированных для каждого размера файла. Каждый раз, когда Вы обнаруживаете коллизию Вы или имеете идентичный файл, или Вы увеличиваете длину хеша для движения только мимо первого различия.
Существует, несомненно, оптимизация, которая будет сделана и ЦП по сравнению с компромиссами ввода-вывода также, но это - хорошее начало для чего-то, что не будет иметь ложных положительных сторон.
Если вы можете отказаться от требования общего доступа Linux и ограничиться NTFS, то альтернативные потоки данных NTFS станут идеальным решением, которое:
- не требует какого-либо хеширования;
- переживает переименование; и
- выживает при перемещениях (даже между разными томами NTFS).
Подробнее об этом можно прочитать здесь . Обычно вы просто добавляете двоеточие и имя для своего потока (например, ": meta") и пишете в нем все, что хотите. Поэтому, если у вас есть каталог «D: \ Movies \ Terminator», запишите свои метаданные, используя обычный файловый ввод-вывод, в «D: \ Movies \ Terminator: meta». Вы можете сделать то же самое, если хотите сохранить метаданные для определенного файла (в отличие от всей папки).
Если вы предпочитаете хранить свои метаданные где-то еще и просто иметь возможность обнаруживать перемещения / переименования в тот же том NTFS, вы можете использовать вызов API GetFileInformationByHandle (см. MSDN /en-us/library/aa364952(VS.85).aspx), чтобы получить уникальный идентификатор папки (объедините элементы VolumeSerialNumber и FileIndex). Этот идентификатор не изменится, если файл / папка будет перемещена / переименована на том же томе.