|
|
ru.unix- RU.UNIX ---------------------------------------------------------------------- From : Vladimir Bormotov 2:5020/400 06 Nov 2000 10:50:34 To : Valentin Nechayev Subject : Re: Как понять, что файл с дыpами? --------------------------------------------------------------------------------
Hi, Valentin!
>>>>> "VN" == Valentin Nechayev <netch@carrier.kiev.ua> writes:
AS>> Еще pаз. Hа уpовне абстpакции "файл" накаких "дыp" нет, есть вполне
AS>> легальное сpедство быстpенько создать нужное количество нулей
AS>> (lseek). Hа уpовне файловой
VN> Есть два метода посмотреть на то, что получается, когда в файле дыра.
VN> Один такой, как Вы говорите. Другой такой, как я говорю. Почему я
VN> отрицаю осмысленность первого варианта? Потому что он
VN> 1) чреват раздуванием при копировании без учета возможности дыр,
Что значит раздувание? У файла есть размер? Когда мы копируеем, размер
сохраняется? Аааа, у файла ДВА РАЗМЕРА? А какой нам более важен?
Hа второй кладем, потому что непортабельно? Или таки прохивиаем это на
уровень сдандарта, и делаем syscall?
VN> 2) чреват недопустимым сжатием файла в случае копирования, которое не
VN> учитывает (и не может портабельно учитывать при нынешнем состоянии
VN> дел) реально занятое место вместо дыр,
Почему недопустимым? Вполне допустими. Один из размеров остается
неизменным. "реально занятое место" получаеся путем несложного вычитания.
Почему мы реально это не можем проверить? Потому что это не стандартно, и
непортабельно.
VN> 3) чреват недопустимо долгими чтениями в случае больших дыр и
VN> необходимости поиска реально существующих данных.
Почему недупустимо? Вполне допустимо. Размер файла ооооон какой большой.
"Долго чтение" это сильно скзано - будет больше fread, которым драйвер fs
бедут возвращать нули... Зато все честно. Еслиб дыр не было, было-бы еще
более долгое чтение "в случае необходимости поиска реально существующих
данных". Собвенно дыры сделаны не для этого, и пытаться "растянуть
функциональность API" в данном случае чревато.
VN> Да, каждый из этих факторов ничтожен по сравнению с другими проблемами
VN> мира unix, но в случае проблем, определенных сабжектом и областью
VN> разговора, они становятся существенными.
В случае, когда каждая программа не умничает, а остается на своем уровне
абстракции, это совершенно несущесвенно. Чем хорош юникс - более-мение
четко отделены мухи от котлет. И не нужно мешать все в кучу.
VN> Более того, я считаю первый вариант идеологически кривым, потому что
VN> он не учитывает реальные возможности произвольного (то есть и вне
VN> существующих областей) прямого доступа к файлу.
unix учитывает реальные возможности произвольного доступа к железу?
Hет? А почему? Давайте мне API. И чтоб это было портабельно.
Бредово звучит? Вот почти так-же бредово звучит "произвольный доступ к
файлу". В смысле то, что "это будет недопустимо долгим".
VN> Второй же вариант этим не страдает, но требует признания
VN> идеологической кривости первого (что сделать в этой эхе многие
VN> неспособны и они будут спорить до последнего) и дополнительных средств
VN> определения этих самых дыр.
Да все способны. Вопрос HУЖHО ЛИ ЭТО? Проще забить на дыры, и вперед.
[skip]
VN> О чем и говорю: сделав реальное поведение таким, что при записи за
VN> конец образуется зона нулей, тем самым авторы unix сделали выбор в эту
VN> сторону. А вот _закончить_, сделать завершенное решение они не
VN> сделали.
Вопрос, зачем это заканчивать?
Было сделано _часное_ решение, ничтожно малого класса задач.
Зачем из этого раздувать API? Какая из этого будет реальная польза?
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.unix/2541acd36a87.html, оценка из 5, голосов 10
|