>>>>> Иван Лох <loh@1917.com> writes: >>>>> On Sun, Nov 06, 2011 at 12:35:06AM +0700, Ivan Shmakov wrote: >> Несколько не в тему. Вместо удаления повторов, я обычно заменяю их >> одним файлом с несколькими именами (e. g., через ln(1)) >> предварительно проверив совпадение mtime и содержимого. (И, >> конечно, то, что это /различные/ файлы.) >> Эта операция, если выполняется правильно (в частности, что очевидно, >> файлы не должны меняться в процессе проверки), не допускает потери >> данных. > Да, но.... > $ echo "1:1" >site1/passwd > $ echo "1:1" >site2/passwd > $ Поискали > $ rm site2/passwd && ln site1/passwd site2/passwd rm(1) не требуется. ln(1) атомарно изменит второе имя файла так, чтобы оно ссылалось на тот же файл, что и первое. > $ ... > $ echo "2:2" >site2/passwd > $ cat site1/passwd > Оп! Этого ли Вы хотели? Во-первых, такого рода замену я выполняю только в тех директориях, в которых файлы de facto являются read-only. Вроде ~/public/files/ (который у меня вместо ~/Downloads/.) Во-вторых: $ echo 2:2 > site2/passwd.tmp && mv -- site2/passwd.tmp site2/passwd По крайней мере так поступают программы, вроде mv(1), rsync(1), да и некоторые текстовые редакторы, полагаю, при соответствующей настройке. В противном случае несложно оказаться в ситуации, когда старое содержимое уже удалено, а новое не удалось записать по причине, e. g., отсутствия свободного пространства на ФС. Поэтому, такое поведение программы для меня — повод написать отчет в BTS. -- FSF associate member #7257
Attachment:
pgpxRbm3wt0ix.pgp
Description: PGP signature