Выкладывайте идеи, как осуществить не вынося файл наружу
можно резать конечно кусочки с гнать их в гзип потоком, но при возникновении коллизии можно потерять кусок.
Пока кубатурю, давайте идеи.

Флешку на 32 Гб не предлагать?

http://narod.yandex.ru/ - один файл 2 Гб

сначала хотел написать про поток, но потом прочитал топик. чего ты боишься там потерять?

(3)+ резать вообще не надо, прямо сразу жать

В общем, реж файл на 22 куска по 1-му гигу, и как только один файл испечешь, то тут же его сливай на файло обменик

(3)http://lurkmore.to/Ни_единого_разрыва

а вообще непонятно, где этот файл? где-то в сети? или тебе его куда-то в сеть надо положить?

(1) нет
(4) предлагаю проделать и выложить описание действий

ужас. и где люди такие проблемы находят при таких скромных рессурсас... :)

(5) файлообменники не укладываются в условие сабжа

(7)Гдето в Инете, на удаленку :)

(10)Ты поясни, ты куда и откуда качаешь?
Ну по сабжу явно не локально :)

(7) в сабже все написано
Сжать файл 21 Гб при наличии свободного места 1.7 Гб ... не вынося файл наружу

(12) все происходит в пределах локальной файловой системы

(13)Не вынося файл наружу, чего ты от него хочешь получить?

(14)Конечный результат?

Типо распаковать его?

(14) тогда не понял, просто травишь на него что тебе больше нравится, и всё

+(13) т.е. имеется файл на фс размером 21 Гб, и имеется на той же фс 1.7 Гб свободного места
нужно сжать в гзип не прибегая к внешним ресурсам

(0) оперативки сколько на машине?

(20) 1 Гб

(19) а, результат типа больше 21 гига?

в смысле 1.7

(19) типа упаковывать с удалением "использованного" куска из оригинала? ...какмикадзе  :)
вообще это "вопрос на засыпку" или "реальная задача"?

(19)А сейчас он чем сжат?

он издевается)))

(26) да не, в принципе, задача интересная

(24) как бы реальная, но и на засыпку

(25) ничем

у меня в телефоне флеха 32г  неужели трудно найти временный диск   чето похоже на прикол

ну если это, к примеру, файл  txt - порезать его на 22 куска да и заархивировать каждый

Если ни чем, то частично сжимая, удаляй :)
Напиши свой gzip ;)

почему на 22 у него еще оперативы 1 гиг)))

(30)Ну, человеку делать нечего в конце рабочего дня :)

(30) а если оно в датацентре в германии?

разделить файл на 20 равных кусков и паковать под присмотром человека с грязной ухмылкой и паяльником в руках, точно ничего не потеряется

бери делай многотомный архив как уже сказали 22 части как только сделалась первая часть лей ее куда нить(и удаляй на диске)  итд

(0) файл-то хорошо сжимаемый?
можно попробовать для начала атрибут "сжатый", глядишь и место освободится

если это в датацентре способ подайдет инет там точно есть))) раз ты подключаешься

Шаги:
1. Выворачиваешь файлы на изнанку, т.е. битики наоборот (оригиналы удаляешь)
2. Упаковываешь файлы (перевертыши) в gzip, начиная с конца (ну если gzip - так не может, то найчи его ;))
3. Наслаждаешься... многими файлами

а может на диски мусор удалить

раз датацент в Германии порно там море

)))

(0) каков прогнозируемый конечный размер файла?

ну в идеале - берем отправляем первый гиг/полгига файла в поток архиватору, осатнавливаемся, потом отрезаем первый гиг, повторяем. но программу всё равно писать надо, потому как я не знаю, как не в сях ставить на паузу поток, а потом что-то еще делать и возвращаться к нему же :)

(22) 20 гиг, видимо

(45)+ и не дай бог что-то пойдет не так :)

открыть в WinHex и на печать)))

(47)+ хотя если выходной поток архиватора оперативно сохранять - то восстановить потом можно будет

(45)Резать можно только с конца, как ни крути :)
Хотя ХЗ, если получить доступ к файловой системе, то можно.
Автор не назвал ОС-ь :)

Читаем последние полгига в файл. Файл сохраняем, исходные полгига в  оригинально файле удаляем.
Повторяем пока файл не кончиться.
Пакуем куски в архив, удаляя уже упакованные.

(50) да и пофиг, можно с конца, просто потом немного сложнее клеить

(51)Как понять, кто был первым и когда? :)

(52)Клеить не надо.
Автор хочет gzip - архив и усе, вместо файлов :)

+ Судя по вики wiki:Gzip
Это один файл - один архив :)

(50) +1 та да, кажись речь про nix

(0) ща скрипт дам

теоретически я-бы разделил задачу на три этапа

1. сделать из одного обьекта (файла) много мелких (с проверкой возможности собрать обратно)
тут думаю правильно пойти путем простого изменения фат таблиц (то есть физически данные остаются на своих местах)


2. архивирование собствено этих кусочков
это просто

3. склеивание заархивированых кусков в один большей файл
это наверно сложно, по сколько алгоритм склейки должен идти "кусочками" (сначало кусочки из 2х фрагментов, после склейки, проверяем и удаляем и так далее)

для такой склейки место (включая исходник) должно быть 1.5 от конечного размера

(58) достаточно просто можно в архиватор загнать все маленькие файлы одним потоком

(59) как я понял в архиве должен быть ОДИН файл

(53)А что там понимать?
При разрезании нумеруешь файлы.
При архивации начинаешь с самого большого номера, и по убыванию

(59) ну и еще, практически все архиваторы работают с копией а это 2х запас свободного диска

(59) Gzip вроде  не умеет  много файлов в один

(60) я так и сказал, по очереди отправляем файлы в поток - для архиватора это выглядит как один файл

(60)Ну можно по очереди читать маленькие файлы и поток подавать на архиватор.
При конце каждого файла удалять его.

(60) Только ему придется после архивирования кусочком исходные куски удалять.

*кусочков

(62) это в винде. в линуксе же есть входящий и исходящий потоки, в один мы шлем файлы как куски мяса в мясорубку, а из второго - пишем на диск

(66) прямо в процессе можно

(68)+ ничего не мешает нам сделать это на одной тарелке

(62)Что значит с копией? В темпе создают?
Ну а касательно запаса - если разбивать на куски размером в 100мегабайт, и удалять при прочтении, то места с избытком будет.

В аналогичной ситуации я зашёл к админам и спросил флешку, сказал "нужно для работы". Отдали 4-гиговую. Быстро и без выноса мозга.

Если у вас всё так плохо (заставляют чинить БП, не дают на апгрейд) - шли резюме, у нас постоянно набирают сотрудников. Зеленоград, 20 км от остальной части Москвы. Если хорошо шаришь в аналоговой или цифровой обработке - тем более приходи.

(51) +1

исходный файл один, выходной файл так же один

можно конечно сплитнуть и покусочно, как в сабже и сказано
но интереснее "прозрачно" и без компиляций, думаю как трансатнуть не с конца, а сначала

скинемся абрахамсу на флешку 32 гига?

могу подарить, но ехать далеко

вспомнилась попа и фортачка....

(74) конечный файл куда девать будешь? / сколько он места займет? файловая система какая

Держи скрипт на bash
Первый параметр - имя входного файла. Второй - количество блоков по 1K, третий - префикс набора архивов. По-умолчанию outfile в текущем каталоге.

Должно сработать. Но у тебя будет только одна возможность это проверить, ибо исходный файл режется в 0 :)



#!/bin/bash

file=$1
bc=${2-10000}
outprefix=${3-outfile}
fsize=`ls -l $file | awk '{print $5}'`
sp=0
bend=0
bn=$(($fsize/($bc*1024)))
for ((c=$bn;c>=0;c--)); do
 let sp=c*bc
 let bend=(c+1)*bc*1024
 let tosize=sp*1024
 echo \($c\) Starting at block $sp \( $tosize\) ending at offset $bend
 dd if=$file bs=1K skip=$sp count=$bc | gzip -f > $outprefix$(($c+1)).gz
 truncate -s $tosize $file
done

(80) это для smaharbA, что было изначально запрошено в (0)

(80)+ в общем если вторым параметром задать миллион, то скрипт будет последовательно с конца архивировать каждый гигабайт исходного файла, а потом его отрезать.
Чтобы обратно потом распаковать такой архив надо выполнить команду

for f in {1..n}; do gzip -d -f -c outfile$f.gz >> unpacked_file_name; done

где n - максимальный номер архива.

Вопроса небыло еще ,а зачем он хочпет так сделать ,файлик утащить куда нить ?

(80) это может быть значительно просче, сплит и потоком все куски в гзип, поправи трункат на обрезку с начала файла

(82) нужен обычный архив, что бы файл продолжал работать в составе системы

(0)
mount -t tmpfs -o size=xxxM tmpfs /mnt/tmpfs/

неее ?

+(86)
еще вариант
chattr -c /home/bigfile.this

(86) и что это даст если размер файла превышает размер памяти и свободного пространства в десятки раз ?

сплитнуть можно так, а если перлом то можно обойтись без временных файлов и гзипать прямо в имеющийся файл и вконце отрезать
#!/bin/sh

file=xxx
prefix=${file}.$$
x=0
size=`wc -c ${file} | cut -d' ' -f1`
split=$((1024 * 1024 * 10))
x=$((${size} / ${split} + 1))
while [ ${size} -ge ${split} ]; do
   tail -c ${split} ${file} > ${prefix}.`printf '%010d' ${x}`
   size=$((${size} - ${split}))
   truncate -s ${size} ${file}
   x=$((x-1))
done
mv ${file} ${prefix}.`printf '%010d' ${x}`
for x in ${prefix}.*; do
   cat ${x}
   rm ${x}
done | gzip -c > ${file}.gz

Жму - жду.

(84) не видел у truncate возможности обрезки с начала файла.
(85) А вот это непонятно. Исходный файл нельзя резать? Или нужен один архивный файл в итоге?
(89) Согласен. Тоже можно. Но менее эффективно чем сразу делать
tail -c ${split} ${file} | gzip -c > ${prefix}.`printf '%010d' ${x}`.gz
Потому как фактически вначале надо скопировать 21Гб, а потом только сжать. А если сжимать по кускам - копирования лишнего не будет.

(91) нужен единый файл, перлом делается трункат и от начала, родной трункат переписывается вполне и на обрезку начала

(92) Для чего нужен единый файл? Для передачи по сети?
Если уж очень хочется получить один файл в конечном итоге, то кучу фрагментов можно собрать в один
for x in ${prefix}.*; do
  cat ${x}
  rm ${x}
done | tar cf > ${file}.gz.tar

(93) для продолжения работы приложения с ним как если бы он не был сжат

(94) Для работы с файлом, как с единицей хранения информации, или для работы с файлом с целью модификации/чтения данных из него?

это файлы ВМ

(93) только не "tar cf > ${file}.gz.tar"
а tar czf > ${file}.tar.gz

но мне не нужен тар, нужен простой гзип или бзип

В общшем в  (0) ищуются острые ощущения. Например любой сбой с случае данной операции (например отключение питания) и исходный файл более не востановиться. цена вопроса - любой внешний носитель на 20 гигабайт - начиная от 800 рублей.

(98) Вы уверены о 800 руб и возможности подключения носителей вообще ?

(99) не встречал устройств с объемов данных в 21 гиг, которые бы туда попали вручную ->  эта информация занесена из вне - > существует интерфейс с внешними устройсвами -> надо искать внешнее устройство с свободным объхемом памяти и копировать туда.

+ в случае метода из (89) никакой сбой не повлияет на данные

(100) см (96)

(96) т.е. задача - сжать файлы VM, чтобы она продолжила работать с ними в сжатом виде?

а теперь решите обратную задачу
заведомо известно, что свободное место + размер сжатого достаточны для получения распакованного экземпляра.

(103) она может работать со сжатыми в гзип
можно конечно было смонтировать какую нибудь гозип (расширяемую) и кусками писать в нее, но не всегда есть возможность использования сжатых ФС в виде файлов, по тому и интереснее в регулярный файл.

(104)... но свободного места меньше, чем размер распакованного? :)

(105)
твой вариант Btrfs со сжатием и не выноси мозг...

+(107)
причем судя по вечной нехватке ресурсов на всех машинах :)

(107) и как поможет btrfs ? после отправки очередного куска делать ресайз и дефраг ?