На самом деле я искал решение на подобии того о чём написал miksoft .

Процитирую свой первый поста (а то тема ушла в сторону от моего вопроса):
Может есть какие-то виртуальные хранилища (виртуальные диски) которые расчитаны именно на хранение большого количества мелких файлов? Или работающие с архивом как с диском? (пусть даже в ущерб скорости)

И ещё раз повторюсь - единственная пока идея которая у меня была в мыслях - это использовать сжаты образы.
Можно сделать образ диска в .ISO, а у UltraISO есть режим - "Опция сжать ISO". Полученный образ будет иметь расширение .ISZ.
Но я не смогу дописать файлы в такой фал :(

miksoftа почему вы не хотите использовать СУБД под эту задачу?
и экономия места будет, и всякие дополнительные плюшки появятся...
Как человек более 13 лет работающий с MySQL, я первым же делом перегнал все данные в базу данных. И если мне самому среди этих 10 миллионов надо найти какие-нибудь данные (по содержимому или по дате или по названию) - я ищу в базе данных...
Но программа-обработчик работает только с физическими файлами (это я говорил в первом посте).

GatorЭээ... Может быть, на внешнем диске?
С подобранными опытным путём ФС, кластером и прочее.

А если их объединять по к.-н. признаку (а-ля дата, клиент)
в один большой txt или bin файл "с разделителями-метаданными"?

Ну, приблуду написать, которая бы их склеивала по расписанию и выдавала on demand.

Очень не хотелось бы упираться в железо и брать отдельные диски только для хранения файлов. Думал что есть виртуальные контейнеры. Но народ здесь вроде как написал что под Windows есть тоже самое как под UNIX, но названия не прозвучало...

А если держать всё соединённом в файле (у меня сейчас паралельно в базе данных хранится) а потом в нужный для программы период это опять превращать в физические файлы - то будет уходить жутко много времени на самих дисковых операциях. Попробуй удалить 10 тысячь файлов - это пол минуты займёт, а объём-то всего в пол мегабайта.

Dimitry SibiryakovТы лучше процитируй в чём твоя проблема. В занимаемом месте или медленной работе?
А зачем цитировать второй раз? Я ведь говорил - проблема в занимаемом месте и медленном формировании списка файлов. Если заходим в архив, то список создаётся тысячекратно быстрей. Ну и тоже самое если скажем данные перекидываю на SSD (причём у меня ХР, по этому потоковая скорость чтения с SSD OCZ Vertex 3 составляет всего 35Мб/с, но за счётс нулевой скорости доступа - просто летаю), следовательно и если данные хранились бы в каком-нибудь контейнере - скорость тоже была многократно выше.

К сожалению пока единственный толковым предложением из всей ветки было про WM c линусом...
Но не ужели ничего подобного под винду нету?

Ну нету желания ради этого отдельный диск (тем более SSD) покупать.
Всякими драйверами типа STACKER ещё в 1993-ем году пользовался, которые под DOS'ом виртуальный диск с компрессией из файла делали. Не ужели за 20 лет не продвинулась тема?

А по поводу собственного файла контейнера - это конечно оптимальнейший способ с точки зрения экономи пространства, но ещё раз повторю - превращать блоки информации в файлы, это гиблое дело по времени (даже без учёта того что под это придётся софт писать). Просто зайди у себя в папку c:\document and settings\user\cookies и посмотри сколько она открывается (а у тебя там и 10 тысячь файлов нету), а потом попробуй её стереть... А теперь представь что из 10 миллионов...

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

Начну с того что в поисках контейнеров я наткнулся на ImDisk Virtual Disk Driver .
Программа бесплатная и занимает 300кб, по этому решил попробывать.
Стало гораздо легче контролировать занимаемые размеры...
Напомню что тестирую на одном каталоге в котором 8000 текстовых файлов размером 40-90 байт. Сам каталог занимает 508кб, при этом виндоус говорит что физически на диске занимает 34Мб, однако как вчера выяснилось - физически занимает чуть больше 10Мб.

Теперь просто расскажу тезисно что меня удивило в ходе тестов:

1) Изначально создал контейнер размером 5Мб - в него вместилось 1900 файлов.
Увеличил контейнер до 10Мб - в него поместилось более 6000 файлов.
Тоесть не пропорционально.
Всё влезло только в контейнер размером 13Мб (именно с ним дальше и проводились все экперементы)
При этом практически никакой разницы от размера кластера: 512 или 4096 байт
Если кластер 512 байт - то после заполнения остаётся 268кб свободного места.
Если кластер 4096 байт - то после заполнения остаётся 280кб свободного места.
Значит прав Basil A. Sidorov , говоря что Файлы размером до, примерно, полутора килобайт NTFS хранит прямо в каталожной записи.

2) Вчера на предложение пользователя k-nike поставить в виндоусе галочку "Сжимать данные" я говорил что это ни как не влияет (свободное место не увеличилось ни на байт). Хотя пользователь Dimitry Sibiryakov говорил что Винда не дура, она объедки в один кластер свалит.
На самом деле оказалось НАОБОРОТ!
Если ставить галочку на существующий каталог - то действительно изменений нет (очевидно виндоус просто видит что лучше не будет и не трогает файлы)
Но ситуация меняется если я вначале создам каталог, поставлю ему галочку "Сжимать данные" и потом начну копировать туда файлы (или сразу при формате скажу что этот диск со сжимаемыми данными).
Вы думаете будет больше свободного места? Нет! Всё наоборот.
В контейнер размером 13Мб влезает всего 1300 файлов (если размер кластера 512 байт).
В контейнер размером 13Мб влезает всего 180 файлов (если размер кластера 4096 байт).
После этого Total Commander говорит что диск переполнен.
Однако если мы после этого будем нажимать на кнопку "Обновить", то увидим, что свободное место на диске в течении 5 секунд будет увеличиваться и с нуля байт поднимется до 9Мб, после чего можно опять дописывать файл (он опять скажет что место кончилось, потом ждём 5-7 секунд и дописываем файлы).
Предпологаю что когда идёт копировани в область где данные должны сжиматься - виндоус налету пытается сжимать файлы что связано с выделением под это дело дополнительных объёмов или дописывания специальных шапок. Но после того как копирование прекратилось, у виндоуса появляется возможноть работы над ошибками, он проверяет что записал и понимает что там небыло смысла сжимать и возвращает файлы к первоначальной форме или освобождает зарезервированное пространство (удивительно что ему на это надо более 5 секунд).

3) Если на диск 13Мб записать 8000 файлов и удалить их, то на диске останется только 3Мб свободного места! (в не зависимости от размера кластера). Туда можно будет опять записать эти 8000 файлов (поскольку они занимают всего 508кб) но записать файл размером 4Мб туда уже не выйдет (тотал коммандер скажет что нет свободного места).
Я попробывал сделать полное заполнение свободного места через разбиение на части (которое есть в тотал коммандере) и оно создало только 2 файла - один на 3Мб, второй 0 байт. Удаляешь их, и видим что диск пустой, свободно 3Мб из 13Мб.
Если зайти на диск через Auslogics Disk Defrag Professional, то видишь что там есть:
$MFT - 8Mb
$MFT::BITMAP - 1Kb
$LogFile - 2Мб

3)

miksoftInterSkyВсякими драйверами типа STACKER ещё в 1993-ем году пользовался, которые под DOS'ом виртуальный диск с компрессией из файла делали. Не ужели за 20 лет не продвинулась тема?Сейчас жив близкий класс ПО - шифрованные диски (TrueCrypt и прочие).
Возможно, что-нибудь из них вам подойдет.
В этом плане мой ImDisk (Virtual Disk Driver) оказался гораздо лучше, потому что он ничего не шифрует и если взглянуть на соедержимое самого контейнера, то он состоит из пустот и текста, тоесть сам контейнер можно по крайней мере сжать как средствами виндоуса (и тогда он "На диске" занимает 3Мб вместо 13Мб), так и заархивировать при переносе и тогда он занимает вообще около 1Мб. Тоесть это уже прогресс в плане занимаемого места.
В то время как контейнер шифрованного диска уже не сжать...

Но просто домумал - Если фриварные контейнеры занимают 300кб, неужели никто за столько лет не повторил аналог STACKER?