Почему бы вам просто не выполнить какой-то автоматический процесс (например, с помощью cron) для выполнения синхронизации?
У вас может быть задание cron, отслеживающее каталог «Drop box» (или каталоги)), а затем он может запустить сценарий для выполнения репликации за вас.
Или вы можете попросить пользователей отправить файл с некоторыми метаданными, чтобы лучше маршрутизировать файл после его загрузки.
Проще говоря, никогда не позволяйте пользователям «выбирать», куда они идут, лучше попросите их сказать вам «для чего это нужно», и тогда у вас есть сценарии, «знающие», куда идут дела и как их туда доставить.Это довольно прямолинейное веб-приложение, даже с каким-то Perl CGI или чем-то еще.А внутренняя сантехника также проста.
Ответ на комментарий ...
Если у вас есть веб-приложение, выполняющее загрузку в CGI, то вы, как правило, даже не получаете «контроль»запроса до тех пор, пока файл не будет полностью загружен.Вид зависит от того, какую технологию на стороне сервера вы используете.В любом случае, это легко "узнать" с помощью веб-приложения, когда файл полностью загружен.Тогда ваш процесс синхронизации может полагаться исключительно на метаданные, чтобы фактически выполнить работу с файлом, и вы не создадите метаданные до тех пор, пока вы не переместите файл в соответствующую область подготовки и т. Д.
Если вы просто используете FTP или scp для копирования файлов в промежуточные каталоги, то решение есть два, два процесса.Первый отслеживает входящий каталог, второй фактически копирует файлы.
Первый процесс может выглядеть просто так:
cd /your/upload/dir
ls -l > /tmp/newfiles
comm -12 /tmp/lastfiles /tmp/newfiles > /tmp/samefiles
filelist=`awk '{print $9}' /tmp/samefiles`
mv $filelist /your/copy/dir
mv /tmp/newfiles /tmp/lastfiles
Это работает так:
- Захватывает список текущих файлов в каталоге входящей загрузки.
- Использование comm (1) для получения файлов, которые не изменились с момента последнего запуска процесса.
- Использование awk (1) для получения неизмененных имен файлов.
- Использует mv (1) для перемещения файлов в ваш «промежуточный» каталог.
- Наконец, он берет текущий список файлов и делает его последним списком для следующего запуска.
Волшебство здесь - comm (1).'comm -12 filea fileb' дает вам файл, содержащий одинаковые строки между двумя файлами.Если поступает новый файл, его размер будет изменяться по мере его загрузки, поэтому, когда вы в следующий раз запустите 'ls -l', его строка не будет соответствовать новой строке - размер (минимально) будет другим,Таким образом, comm найдет только файлы, даты, имена файлов и размеры которых не изменились.Как только у вас есть этот список, все остальное довольно просто.
Единственное предположение, что этот процесс делает просто то, что в именах ваших файлов нет пробелов (таким образом, awk будет легко работать, чтобы получить имя файла изсписок).Если вы разрешите пробелы, вам понадобится немного более умный механизм для преобразования строки 'ls -l' в имя файла.
Кроме того, 'mv $ filelist / your / copy / dir' предполагаетв именах файлов нет пробелов, поэтому его тоже нужно будет изменить (вы можете свернуть его в сценарий awk, сделав, возможно, вызов system ()).
Второй процесс также прост:
cd /your/copy/dir
for i in *
do
sync $i
mv $i /your/file/youve/copied/dir
done
Опять здесь "без пробелов в предположении имен файлов".Этот процесс опирается на сценарий оболочки синхронизации, который вы написали, который делает правильные вещи.Это оставлено в качестве упражнения для читателя.
После синхронизации файл перемещается в другой каталог.Все файлы, которые там отображаются, были "синхронизированы" должным образом.Вы также можете просто удалить файл, но я склонен этого не делать.Я бы поместил этот каталог, возможно, в программу «Удалять файлы старше недели».Таким образом, если вы столкнетесь с проблемой, у вас все еще будут оригинальные файлы, которые можно восстановить.
Этот материал довольно прост, но он также надежен.
Пока первый процесс выполняется «медленнее», чем загрузка (т. Е. Если вы запускаете его два раза подряд, вы уверены, что размер файла по крайней мере изменится), то время выполнения может составлять каждую минуту , каждый час, каждый день, что угодно. Как минимум, он безопасно перезапускается и самовосстанавливается.
Темная сторона второго процесса - если ваш процесс синхронизации занимает больше времени, чем ваш хрон cron. Если вы запускаете его каждую минуту, а запуск занимает более одной минуты, у вас будет два процесса, копирующих одни и те же файлы.
Если вы синхронизируете процесс "безопасно", вы в конечном итоге просто скопируете файлы дважды ... пустая трата времени, но обычно безвредная.
Вы можете уменьшить это, используя методику, такую как this , чтобы гарантировать, что ваш скрипт копирования не будет запускаться более одного за раз.
В этом вся суть. Вы также можете использовать комбинацию (использование веб-приложения для загрузки с метаданными и использование процесса синхронизации, запускаемого автоматически через cron).
Вы также можете иметь простую веб-страницу со списком всех файлов в / your / copy / dir, чтобы люди могли видеть, синхронизированы ли их файлы. Если файл находится в этом каталоге, он еще не завершил синхронизацию.