>>>>> Иван Лох <l...@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
pgpBjkW7B4SYN.pgp
Description: PGP signature
