Судя по доступным клиентам Linux для WebDAV, я предпочел бы сделать это следующим образом:
Используйте GVFS или один из модулей файловой системы WebDAV (davfs2 или fusedav), чтобы "отобразить" файлы удаленного сервера WebDAV на путь локальной файловой системы.
Используйте встроенную команду cp с параметром -n чтобы указать, чтобы файлы не подвергались ударам в месте назначения. Обратите внимание, что некоторые оболочки, такие как dash в Ubuntu, по умолчанию будут выполнять builtin версию cp , и эта встроенная функция может не поддерживать параметр -n . Для достижения наилучших результатов убедитесь, что вы выполняете версию cp GNU Coreutils, запустив /bin/cp или /usr/bin/cp (в зависимости от того, где находится бинарный файл в вашей конкретной системе).
РЕДАКТИРОВАТЬ: Я неправильно понял ваш оригинальный вопрос.
Я думаю, что вы говорите, что у вас есть ситуация, когда файл file1.txt существует в двух разных путях на сервере WebDAV, и содержимое этих двух файлов абсолютно одинаково. И так как у вас уже есть одна копия файла, вы не хотите загружать вторую или третью копию файла, потому что это тратит пропускную способность?
Ну, со стороны клиента это было бы очень сложно сделать. Вот почему
Вы должны посмотреть, что вы сравниваете, чтобы определить, является ли файл уникальным, и требования / затраты, чтобы сделать это сравнение.
Я предположил (ошибочно), что вы сравниваете путь относительно корня структуры папок WebDAV. Стоимость сравнения равенства путей очень проста: вы просто смотрите на две строки пути, например /dir1/dir2/file1.txt , и смотрите, совпадают ли эти строки. Если они делают, это дубликат. Если они этого не делают, это не так.
Другая вещь, которую вы можете сравнить, это имя файла, игнорируя путь. Так, например, считаете ли вы эти два файла дублирующимися: /dir1/dir2/file1.txt и /dir3/dir4/file1.txt? Ну, если вы сравниваете только по названию, то это будет считаться дубликатами. Тем не менее, мы можем смешивать и сопоставлять различные тесты для дублирования, как нам нравится, чтобы сделать правильный вид теста для нашего варианта использования.
Другие, менее полезные свойства для сравнения включают в себя размер файла, атрибуты (также известные как метаданные), расширение файла и т.д. Эти вещи не дают вам особого смысла с точки зрения способности оценивать дубликаты, потому что в большинстве случаев это Легко создать файл, который имеет те же свойства, что и другой файл, но совершенно другое содержимое, и большинство людей не сочли бы эти два файла дублирующимися, если содержимое отличается.
На мой взгляд, самое важное, что вы можете сравнить - это содержимое файла. К сожалению, с точки зрения клиента WebDAV у вас нет возможности узнать содержимое файла, пока вы уже не загрузили файл. А что касается клиента, содержимое файла может измениться во время или после передачи файла, и в этом случае результаты сравнения дубликатов изменятся, если вы повторно загрузите файл.
Существует два основных способа сравнения содержимого файла: байт за байтом и хеширование. Байт за байтом - это наиболее "гарантированный" способ проверки на наличие дубликатов, но он страдает от ограничения, связанного с тем, что вам нужно сравнивать весь файл, что очень медленно для большого объема данных. Также учтите, что основной алгоритмической сложностью обнаружения дубликатов является O(n^2) , что означает, что вам придется сравнивать содержимое каждого файла с содержимым каждого другого файла, чтобы определить, является ли он дубликатом. Использование криптографического хэша для сравнения файлов может значительно сократить объем данных, которые нужно сравнивать или передавать, но недостатком является то, что вы вводите бесконечно малый шанс того, что два файла могут фактически отличаться, но иметь одинаковый хеш - известный как столкновение хешей.
Но опять же, с точки зрения клиента , невозможно узнать, каково содержимое файла, или даже его хеш, если вы либо:
- Скачать файл с сервера; или же
- Убедите сервер вычислить хеш-значение для вас локально, а затем загрузите хеш.
В первом случае вы загружаете файл, чтобы определить, является ли он дубликатом, чтобы избежать загрузки файла, поэтому вы не можете этого сделать, очевидно - вы тратите пропускную способность, которую пытаетесь избежать, просто выполняя сравнения !
В последнем случае вы можете быть к чему-то. Хэш SHA1 очень большого файла занимает всего пару байтов и представляет крошечную долю от размера большого файла. Было бы довольно практично загружать хэши всех файлов и делать O(n^2) сравнение хэшей, чтобы определить, какой файл загрузить. Тем не менее, вы по-прежнему сталкиваетесь с проблемами состояния гонки, если данные файла изменяются на сервере во время этих сравнений, поэтому необходимо убедиться, что вы учитываете синхронизацию, если это важно для вас.
Итак, вывод:
- Если у вас нет полного программного контроля над сервером WebDAV и вы не можете вносить изменения в его конфигурацию, вы в значительной степени не везете (tm), решая, есть ли у вас уже копия того же содержимого файла, которое хранится в нескольких файлы на сервере, если только администратор сервера не предоставляет какие-либо хеш-файлы для каждого файла на сервере, что может дать вам некоторую степень успеха, если вы можете положиться на хеш-значения.
- Если у вас есть полный контроль программного обеспечения через сервер WebDAV и могут изменить свою конфигурацию, вы можете написать скрипт или программу (или использовать один уже имеющийся) , чтобы создать хэш файл с расширением , такими как, например ,
.sha1sum в том же каталоге, что и каждый файл, размещенный на сервере WebDAV. Это может позволить вам загружать только хэши и сравнивать их при относительно небольшой стоимости полосы пропускания по сравнению с размером файлов, если размер ваших файлов превышает пару килобайт.
