16.02.12 12:39, Alexander Galanin написав(ла):
Грязная работа по разбору уже сделана авторами libzip, а индекс в памяти —
лично мной в fuse-zip. Осталось только смонтировать архив.
Тогда да, распаковка очень проста (если не нужно реверсить строки пока
ещё идёт добавление). Упаковка сложнее.
On Thu, 16 Feb 2012 09:32:05 +0200
Serhiy Storchaka wrote:
> 15.02.12 21:32, Alexander Galanin написав(ла):
> > Это смотря как распаковывать…
> Не подходит по условию. Раз для топикстартера даже простой внешний
> индекс выглядит «некрасиво», то разбирать бинарный CentralDir и
> создавать индекс
15.02.12 21:32, Alexander Galanin написав(ла):
Это смотря как распаковывать. Если распаковщик будет читать Central
Directory, то там в худшем случае надо пробегаться по списку всех
файлов, размер которого линейно зависит от N (по условию). Однако если
считать CentralDir и положить хотя бы в map (
On Wed, 15 Feb 2012 17:21:20 +0200
Serhiy Storchaka wrote:
> > Пришло в голову, что zip архив позволяет добавлять файлы к архиву, и
> > утилитка для этого дела есть, любезно написанная когда-то Anton
> > Kovalenko:
> > | zipput archive.zip file-name
> > Интересно, какая производительность такого
13.02.12 23:01, Alexey Pechnikov написав(ла):
14 февраля 2012 г. 0:01 пользователь Alexander Galanin
написал:
Раз уж допустимо менять формат входных данных, то почему бы не хранить
информацию в виде россыпи из гзипнутых файлов по N строк?
Чтобы за просто так "порвать" диск? Очень сильно думаю
13.02.12 21:34, Alexey Pechnikov написав(ла):
Кажется, стоит дополнить - разумеется, сжимаются строки ненулевой
длины, но достаточно малые для того, чтобы имело смысл применить
построчное сжатие; скажем, длина строк от 100 до 1000 байт.
Подойдет и вариант поблочного сжатия (например, блоками по
On Tue, Feb 14, 2012 at 05:29:08PM +0400, Alexander wrote:
> а может стоит посмотреть в сторону свойств файловых систем? например, zfs
> умеет сжимать "прозрачно"
Уже предлагали.
--
WBR, wRAR
signature.asc
Description: Digital signature
> Re: Аналог утилиты tac для сжатого файла
> dimas
> Tue, 14 Feb 2012 00:32:02 -0800
> автор, я правильно понимаю. что текстовый файл - это некий очень большой лог,
> генерируемый в постоянном режиме некой coolprog?
Не хотел никого провоцировать, потому не давал описания задачи
автор, я правильно понимаю. что текстовый файл - это некий очень большой лог,
генерируемый в постоянном режиме некой coolprog? по-моему, имеет смысл
натравить на него logrotate, конфиги для него пишутся просто, в мане все
расписано. настроить его, чтобы при достижении определенного размера (500M
On Tue, Feb 14, 2012 at 01:01:04AM +0400, Alexey Pechnikov wrote:
> Чтобы за просто так "порвать" диск? Очень сильно думаю, что в любом
> скриптовом языке fsync зовется после записи каждого файла... так что
> никак не вариант. А вообще хватило бы и двух файлов - с блоками и со
> смещениями блоков
14 февраля 2012 г. 0:01 пользователь Alexander Galanin
написал:
> Раз уж допустимо менять формат входных данных, то почему бы не хранить
> информацию в виде россыпи из гзипнутых файлов по N строк?
Чтобы за просто так "порвать" диск? Очень сильно думаю, что в любом
скриптовом языке fsync зовется п
On Mon, 13 Feb 2012 23:34:30 +0400
Alexey Pechnikov wrote:
> Кажется, стоит дополнить - разумеется, сжимаются строки ненулевой
> длины, но достаточно малые для того, чтобы имело смысл применить
> построчное сжатие; скажем, длина строк от 100 до 1000 байт.
Раз уж допустимо менять формат входных д
Кажется, стоит дополнить - разумеется, сжимаются строки ненулевой
длины, но достаточно малые для того, чтобы имело смысл применить
построчное сжатие; скажем, длина строк от 100 до 1000 байт.
Подойдет и вариант поблочного сжатия (например, блоками по 16...256
килобайт). Как очень простой вариант, м
> > А в типичном нам нужно хранить не полный вектор отступов, а только
> > те, которые еще нужны, а их вряд ли много - один, ну, два.
>
> Так файл-то надо задом наперёд пройти. Так что сначала дойти до конца,
> расставив контрольные точки, а потом идти с конца, когда их можно будет
> исключать.
Н
On Mon, 13 Feb 2012 19:48:10 +0400
Artem Chuprina wrote:
> Ну, в тяжелом случае (файл состоит из одних переводов строки или
> чего-то очень близкого, что можно сжать в один блок) нам все равно
> придется разжать весь файл, если пользоваться zlib, а не лезть в
> структуру уже блока грязными ногами
> > n^2 это в данном случае бесконечность. Понятно, что надо сохранять вектор
> > отступов
> > блоков на первом проходе..
>
> Тут на интересную задачку можно накопать, если не знать про входные данные
> более
> ничего :)
>
> Если хранить вектор отступов, то памяти при работе потребуется M =
>
13.02.2012 17:12, Иван Лох пишет:
n^2 это в данном случае бесконечность. Понятно, что надо сохранять вектор
отступов
блоков на первом проходе..
Тут на интересную задачку можно накопать, если не знать про входные данные более
ничего :)
Если хранить вектор отступов, то памяти при работе потре
On Mon, Feb 13, 2012 at 05:01:16PM +0400, Alexander Galanin wrote:
> 13.02.2012 16:56, Иван Лох пишет:
> >On Mon, Feb 13, 2012 at 06:51:48PM +0600, Andrey Rahmatullin wrote:
> >>On Mon, Feb 13, 2012 at 04:30:12PM +0400, Alexey Pechnikov wrote:
> >>>Большой файл (больше размера ОЗУ и свободного диск
On Mon, Feb 13, 2012 at 04:56:53PM +0400, Иван Лох wrote:
> > > Большой файл (больше размера ОЗУ и свободного дискового пространства)
> > > сжат, например, с помощью gzip или любого другого потокового
> > > упаковщика. Надо его разжать, причем с реверсом строк "на лету", не
> > > читая весь файл в
13.02.2012 16:56, Иван Лох пишет:
On Mon, Feb 13, 2012 at 06:51:48PM +0600, Andrey Rahmatullin wrote:
On Mon, Feb 13, 2012 at 04:30:12PM +0400, Alexey Pechnikov wrote:
Большой файл (больше размера ОЗУ и свободного дискового пространства)
сжат, например, с помощью gzip или любого другого потоков
On Mon, Feb 13, 2012 at 06:51:48PM +0600, Andrey Rahmatullin wrote:
> On Mon, Feb 13, 2012 at 04:30:12PM +0400, Alexey Pechnikov wrote:
> > Большой файл (больше размера ОЗУ и свободного дискового пространства)
> > сжат, например, с помощью gzip или любого другого потокового
> > упаковщика. Надо его
On Mon, Feb 13, 2012 at 04:30:12PM +0400, Alexey Pechnikov wrote:
> Большой файл (больше размера ОЗУ и свободного дискового пространства)
> сжат, например, с помощью gzip или любого другого потокового
> упаковщика. Надо его разжать, причем с реверсом строк "на лету", не
> читая весь файл в память и
Большой файл (больше размера ОЗУ и свободного дискового пространства)
сжат, например, с помощью gzip или любого другого потокового
упаковщика. Надо его разжать, причем с реверсом строк "на лету", не
читая весь файл в память и не сохраняя на диск.
Понятно, что задача выполнима, вопрос, существует л
23 matches
Mail list logo
