Вышла первая версия opensource клона Windows NT

Irsi (*) (2003-02-13 15:49:28.354) Да уж.. спасибо... "расширинную информацию" хранить.. которая будет потеряна при любой попытке передать файл на другой компьютер... т.е. которая кроме как для локальной ОС никому нафиг не нужна...

2dead_knight: читай выше, а? Уже все было сказано по этому поводу... И как передовать чтоб сохранялась, и почему она все-таки нужна...

2Irsi (*) (2003-02-13 16:46:45.738)

Читал... про то как передавать - ничего нет... Ты предлагал архиваторы.. я убедился !практически!, что это предложение лажа, по сети передача так же невозможна... Ну какие еще предложения?...

2dead_knight: ну почему уменя все работает? ну что я не так делаю? :)

2Irsi (*) (2003-02-13 17:21:04.307)

Читай dead_knight (*) (2003-02-11 19:13:00.071) - что я делаю не так?

А еще жду ответов на dead_knight (*) (2003-02-13 12:12:21.031)

Почти Хармс

откажите ему в удовольствии
сидеть на скамейке
сидеть на скамейке
откажите ему в удовольствии
сидеть на скамейке
и мечтать о потоках, windows-only непременно
о доках несовместимых и впаяных мертво
в раздел на винте и о толстой еврейке

Навеяло под влиянием восторженного мечтательного кретинизма ирси. :)

2AVL2: БЛЯТЬ! Кто сказал что windows-only??? Какие мечты в жопу? Это прогноз и если он сбудется ты все альтернативщику будут сосать, если разумеется не подготовятся к данному развитию событий... Мне обсолютно похуй сколько будет занимать leenjux на рынке десктопов - ~0.5% как сейчас, или 0.0005%, после того как вообще перестанет воспринимать большинство файлов, созданых в винде. А после того как leenux сервер начнет поганить виндузячие файлы, он вылетит и с серверного рынка как пробка из бутылки... Мне это похуй - я просто делаю доброе дело, предупреждаю Вас красноглазых... Не хотите слушать - ну и черт с Вами, идите в жопу...
Хотя в качестве платы за разяснения я неплохо повесилися с другой стороны...:)

Ирси обидился ...

2anonymous (*) (2003-02-13 18:14:31.285): нет. :)
Я уже объяснял __как__ я здесь развлекаюсь... Это тоже часть того развлечения...:)

Кстати для неверующих - http://www.zdnet.ru/?ID=296094
"Представитель компании признал, что Microsoft планирует предложить комплекс приложений с кодовым названием Office 11 только для Windows 2000 с Service Pack 3 и Windows XP."
Не думаю что это означает начала активного использование многопоточности в NTFS, но что это подготовка к оной - однозначно имхо.

>А после того как leenux сервер начнет поганить виндузячие файлы, он
>вылетит и с серверного рынка как пробка из бутылки...
А может иметь место быть и другой вариант событий. Пользователи прочухают, что файлы нового охфиса не пересылаются по мылу, не архивируются (вернее при архивации ломаются), не закачиваются по фтп, не отдаются по http протоколу и разозляться на мс и новый охвис. Будут все чаще и громче обсуждать возможность и необходимость перехода на опеноффис и искать возможности конвертации многопоточного документа в однопоточный. Появится много утилиток, как шареваре, фриваре так и опен соурс, для конвертации. Потом МС выпустит сервис пак для охфиса, который даст возможность сохранять документы в однопоточном файле, но будет уже поздно. Люди окончательно перестанут доверять мс и заговорят о создании стандарта для текстовых процессоров, спреадшитов и т.д., в качестве которого, в первом приближении будет выступать опен оффис.

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

А Ирси сначала правильные вещи говорил - НТФС не последний ацтой, но с потоками его немного занесло.

"Я уже объяснял __как__ я здесь развлекаюсь... Это тоже часть того развлечения...:)" --
кричал со слезами на глазах и вымученной улыбкой на искусаных губах Ирси.
:))

2del:
1. По мылу они пересылаться будут, если отправлять и принимать их с помошью Outlok/Outlok Express разумеется. :) То же относится про загрузку/выгрузку по ftp/http - если на клиентской части живет IE, а не серверной IIS, то все будет ок.
2. Архивация - если архивировать/разархивировать средствами виндов, то все будет ок (начиная с ХР винды сами поддерживают зипы).
3. Про утилитки - согласен, появятся обязательно. Только они будут не нужны, ибо уже сейчас Office умеет сохранять свои файлы в XML... Правда XML это хитрая штука - это из тех стандартов на котором можно сделать свой формат на 100% соотвествующий стандарту и тем не менее - ни с кем толком не совместимый...:)
4. Да формат для обмена бизнес-данными на основе XML есть, открытый, сделан групой фирм во главе с... Microsoft! ;) Более того - есть формат для обмена текстовыми данными, открытый, rtf называется, то же не без участия Microsoft делался... А толку то? Все равно по сети доки ходят в полный роост.

Ты пойми - юзеру насрать на все высокие материи, у него простой подход "если это не совместимо с продукцией мелкософта, то это гавно, выкинь его". Можно сколько угодно доказывать обратное, но факт остается фактом и игнорировать его имхо глупо. Прошу обратить внимание - я него что это хорошо или правильно, я говорю что этот факт имеет место быть и мы вынуждены с ним считаться... Подождите, пройдет немного времени и совместимость с микрософт будет казаться не менее обязательной и естейственной чем совместимость с х86 (тоже то еще уебище, но однако - победило...)

2Irsi (*) (2003-02-13 20:51:36.94)
Погодите, а как Вы упакуете многопоточный файл в http и ftp streams?

2 Irsi (*) (2003-02-13 20:51:36.94)

imho UNIX-like системам не придется сильно заморачиватся, что-бы не поганить виндовым клиентам файлы ;)

Возьмем ту-же самбу, что ей мешает на запрос виндовой машины записать что-то в поток stream1 файла file1 создать файлик с именем "file1:stream1" и использовать его для хранения информации о потоке. Если клиент попросит открыть file1:stream1 то просто напросто будет открыт файла "file1:stream1" а не file1. Для большинства unix-овых файловых систем запрещено использовать в имени только два символа - это "/" и "\000", так что с двоеточием проблем не будет ;) При вызове readdir (или как он там в данном случае называется) - просто не отображать файлы содержащие ":" в имени... Особого гемора имхо не будет тут...

Если взять тот-же HTTP - то тут как я понимаю дело упрется в запросы типа

GET /index.html:favicon HTTP/1.0

Тут тоже подобное решение весьма подойдет, а если веб-сервер еще и насильно не показывает список файлов если не нашел индекса, то тут вообще даже модернизировать код того-же апача/роксена/другого_www_сервера не придется - просто нафлудил файла с именами

index.html

index.html:DATA --симлинк--> index.html

index.html:stream1

index.html:stream2

итд, и все ;)

остается еще ftp, там подобным образом тоже можно будет выкрутится ;)

А так - даже на вскидку щас не вспомню по какому еще протоколу UNIX может служить файлопомойкой ;)

А тем, кто использует linux как десктоп - им пожалуй будет н@$р@tь на многопоточность вообще ;)

> А так - даже на вскидку щас не вспомню по какому еще протоколу UNIX может служить файлопомойкой ;)

Тобишь как таковых протоколов мноооого, просто я на вскидку не всмоню что еще винда понимать умеет бедненькая ;))

-- imho UNIX-like системам не придется сильно заморачиватся, что-бы не поганить виндовым клиентам файлы ;)

Ирси очередной раз обосрали с ног до головы с потоками на фс, а он все пытается представить все так, будто он так развлекается %-) Эксгибисионист %-)
Ничего, щаз што-нибудь придумает %-) Скажет, что использовать ':' идеологически неверно %-)

"если в вашей фс нет потоков, то она устарела по определению" (с) ирси, рекламный отдел микрософта.

2sseREGa: man samba или как там правильно БЛЯ!!!! Лезут бля спорить, а сами не в курсе что самба уже поддерживает многопоточные файлы...:)
По остальномы ты прав вообщем, и это есть ответ для del, но там тоже боюсь будет все не совсем просто... Наверняка на первых порах будут клины, потом их решат как принято на скорую руку, потом выяснится что эти решения сильно ресурсоемки...
Правда еще одно замечание - <filename>:DATA или поток номер 0, это равнозначно просто <filename>... Вы явно не прочитали, что раньше в этой ветке говорилось про то как обеспечивать совместимость программ не расчитанных на многопоточность в FS с оной FS... А там четко говорилось что если прога не запрашивает имя/номер потока в явном виде то ей всегда отдается поток по умолчанию, который и есть либо нулевой, либо DATA, либо data fork, либо... вообщем зависит от реализации...:)
Еще раз - Вы только что подтвердили мой тезис, который упорно отрицался противниками многопоточных FS во всех предыдущих дискуссиях, а именно тот что совместить данные с многопоточных FS с существующими протоколами передачи файлов и однопоточными FS особой проблемы нет и для этого надо приложить __минимум__ усилий. :) Когда я коворил это - красноглазые возникали, когда я подал эту проблему несколько иначе - стали убеждать меня что я дурак, моими же аргументами...:)
Но с другой стороны прав я и в той мессаги, на которую Вы отвечали - усилия, хоть и минимальные приложить придется. А поскольку никто не желает этого делать зарание, проблема все-таки возникнет. Обвинят во всем разумеется мелкософт...:) Но сначала скрипя зубами вытащат занозы чтоб работало, потом начнут искать пути повышения производительности, придут к идеи многопотчной ФС (точнее - подсмотрят), слелают кое-как и объявят это своим величайшим достижением, проигнорировав тот факт что тот же мелкософт сделал это лет за 10 до них...:)
Ну и как мне на это реагировать? Разумеется ничего окромя бурного веселья у меня эта ситуация не вызывает...:)

>Ну и как мне на это реагировать? Разумеется ничего окромя бурного веселья у меня эта ситуация не вызывает...:)

Ну-ну. Очень напоминает: "А они мне кричат "пидарас", а мне приятно. Очень я славу люблю." 8-)

2anonymous (*) (2003-02-14 10:59:39.596): угу... только если проводить аналогии с тем анекдотом, то получается зеркально - выступаем перед стадионом с пидорасами...:)

Кстати FAT еще рано списываь со счетов. FAT32 мжет гарантировать неплохой data-integrity:
(далее цитирую письмо от Albert Cahalan <albert@users.sf.net>)

The FAT32 layout can support full data integrity
via the phase-tree algorithm. (like Tux2 uses)
This is better than most forms of journalling.
I'll guess the FAT32 layout got the necessary
features to allow safe FAT16-->FAT32 conversion
and/or defragmentation.

The FAT32 superblock (boot sector) contains:

__u32 fat32_length;// sectors/FAT
__u16 flags; // bit 8: fat mirroring, low 4: active fat
__u8 version[2]; // major, minor filesystem version
__u32 root_cluster;// first cluster in root directory
__u16 info_sector; // filesystem info sector

All in one atomic write, one can...

1. change the active FAT
2. change the root directory
3. change the free space count

That's enough to atomically move from one phase to the next.
You create new directories in the free space, and make FAT
changes to an inactive FAT copy. Then you write the superblock
to atomically transition to the next phase.

In a bit more detail:

Set bit 8 of "flags" (A_BF_BPBExtFlags to Microsoft) to
disable FAT mirroring. Then the low 4 bits are a 0-based
value that indicates which copy of the FAT should be used.

Assume we have 2 copies of the FAT, as is (was?) common.
I'll call them X and Y. When we mount the filesystem,
we disable FAT mirroring and mark FAT X active.

Now we can make changes to FAT Y without affecting
filesystem integrity. Windows will not use FAT Y. As is
usual with the phase-tree algorithm, we use free space
to create a new structure beside the old one.

Time for a phase change:

We have FAT Y, currently inactive, updated on disk.
FAT X is active; it describes the current on-disk state.
We have a new root directory on disk, sitting in free space.
We have a new filesystem info sector on disk, sitting in free space.

We write one single sector, then:

FAT X becomes inactive, and will not be used by Windows.
FAT Y becomes active; it describes the new on-disk state.
The old root directory is marked free in FAT Y. Good!
The old filesystem info sector is marked free in FAT Y. Good!

Once the superblock goes to disk, FAT X may be written to.

Ирси, ты бы чем постоянно оправдываться, просто не ходил бы там, где тебя все знают... :)

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

1) Что показывает ls -l * (dir с полным листингом) в директории с многопоточными файлами.
2) Как переслать многопоточный файл с одной машины на другую как есть. Например, из аутлука в бат. Куда девать fat?
3) Как можно узнать, какие потоки есть в файле и потереть ненужные (dir + del + touch)

Пока что потоки можно применять исключительно для хранения информации, не имеющей смысла за пределами данной FS. к примеру, для хранения ACL или квот. Но в XFS все это есть в EA. Иконки? уже сомнительно.

Куда интересней выглядят appsdir.

2AVL2:
1. А что ты хочешь чтоб он показывал? Я не понял вопроса...
2. Куча вариантов. По мелкомягкой сети (в родной реализации) - проблем нет. Бат известен своей кривизной, он даже хтмл почту толком не понимает, с имапом проблемы, и вообще - что вы хотите от этого убожества... А вообще надо файлы зиповать... :)
3. Сложный вопрос...:) Вообщем для фара был плагин для манипуляции с потоками на NTFS, но я его ни разу не использовал за ненадобностью...:)

На счет "Пока что потоки можно применять исключительно для хранения информации, не имеющей смысла за пределами данной FS" ты неправ имхо, правильней сказать "Пока что потоки применяются в основном для хранения информации, не имеющей смысла за пределами данной FS". В основном - потому что расширенная информация о файле, типа автора и т.д. вполне приминима и полезна за пределами данной FS.
Про сомнительность хранения иконок в отдельном потоке - ты опять забыл что это УЖЕ применяется около 20ти лет и подход однозначно доказал свою эффективность. Так же как доказал свою эффективность принцип хранения текста в одном (основном) потоке, а его оформления - в другом. Более того - это первое применение которые радостно применяю разработчики, когда им в руки попадается многопоточная FS...:)

>угу... только если проводить аналогии с тем анекдотом, то получается зеркально - выступаем перед стадионом с пидорасами...:)

Ирси, у тебя и так проблемы с логикой, а когда начинаешь оправдываться, то и остатки пропадают 8-)

2anonymous (*) (2003-02-14 14:25:01.99): у меня с логикой все ок, в отличае от онанимусов... А онанимусы парни простые - поскольку им аргументированно возразить нечем, более того - они просто не понимают о чем речь идет, но тем не менее сказать что-то хочется... Ну а поскольку по делу не выходит надо наехать и изобразить что они такие умные и все понимают...:) Смешно, ей богу...:) И самое смешное в том что они просто не осознают какими идиотами они выглядят...:)

"Правда еще одно замечание - <filename>:DATA или поток номер 0, это равнозначно просто <filename>... Вы явно не прочитали, что раньше в этой ветке говорилось про то как обеспечивать совместимость программ не расчитанных на многопоточность в FS с оной FS... "

Так я же сказал что

index.html:DATA --симлинк--> index.html (или наоборот можно ;)

2sseREGa: ааа, для особо умных и правильных... ну да - можно, согласен...:)

Irsi, ты забываешься. Скорость обновления ПО замедлилась. Скорее мы услышим все больше ропота - "да ну нахер это Микрософт, у которого следующие версии не совместимы с предыдущими, возьмем лучше тот же openoffice".

2anonymous (*) (2003-02-14 15:32:26.193): угу, согласен. Но пока действует закон Мура ничего принципиально не изменится... А его обещали удеживать на плаву еще лет 10... Так что еще минимум лет 10 мы будем наблюдать теперяшнею схему обновления железа и софта... Потом - посмотрим, в компьтерной индустрии делать прогнозы на 10 лет и более - дело очень неблагодарное. :) 10 лет - это практически вечность по меркам этой индустрии...

>1. А что ты хочешь чтоб он показывал? Я не понял вопроса...
я понятия не имею, как можно выдать информацию о директории (многопоточном файле) так, чтобы это было оденовременно детализировано и кратко. В разных случаях нужна разная информация. Так что выдает dir?
>2. Куча вариантов. По мелкомягкой сети (в родной реализации) - проблем нет.
Совсем ополоумел? win2k и winxp (?) ставится на fat. Я должен узнать, что там у получателя за файловая система, чтобы отправить ему обычный док? По поче тоже необходимо спросить, каким клиентом пользуется получатель? зиповать все подряд? Эх, жаль, что МС твоими советами и прогнозами не пользовалась и никогда не воспользуется. Давно бы прогорела :)
>3. Сложный вопрос...:)
вот-вот. и пока такая элементарщина будет "сложным вопросом", ничего кроме акл и квот в потоках не будет...


А как элегантно сделано в гнумерик или еще лучше в опенофис - файл это уже зип со всем необходимым внутри. Кому хошь посылай такой "многопоточный" документ и все его получат и прочтут.

А разве Irsi способен понять преимущества зазипованного файла перед поточным? Для его обезъянного уровня развития это фантастика какая-то.

2AVL2:
1. А я вообще не понимаю как может быть одновременно детализировано и кратко. Это как в бане - "Рабиновичь, выб либо крестик сняли, либо трусы одели" :))))
Я не понимаю какую информацию в "детализированным и кратком" выводе команды dir/ls Вы хотите полусить... Список в студию, потом посмотрим...:)
2. Так по сети он передасться нормально - проблемы с потерей потоков возникнут при записи на фат. :) Впрочем в случае с локальным диском (многопоточный файл с нтфс пытаемся копировать на фат) оно ругается и предупреждает что молде потеряешь все потоки, окромя основного... Что там по сети будет - не проверял, по идее тоже обязано ругнуться...
3. Яж имхо ответил на "сложный" вопрос...:)

Ага, элегантно... только ресурсы жрет на порядок сильней :)

2anonymous (*) (2003-02-14 15:56:46.691): ага... преимущества яблок перед апельсинами...:)))
Блин, но почему как онанимус так ламерьё полное, за редким исключением?

2Ирси: один хуй все будут сохранять файлы в формате 97-го ворда

Господа, может Ирси завидует Герману Иванову? Тот за пару недель приобрел больше славы, чем Ирси за все года. Теперь наверствывает, наш прикормленный клоун.

2anonymous (*) (2003-02-14 16:14:18.382): да ну - если у юзверя хватит мозгов изменить дефолтные настройки своего ворда для формата сохранения файла по умолчанию, то он изменит их не на формать 97го ворда, а на rtf... Но по засилю doc-file можно смело сказать что 99% юзврей даже не задумываются над этим...:)
Так что будет как я предсказывал...:)

Абшибаешься. Если какой-то поставщик-недоумок завтра будет присылать клиентам прайсы и договоры в супер-многопоточном файле, которые ехель97 правильно не откроет, то хер чего он продаст! ТОчно так же, если кто-то выпендрится и пришлёт стар-кальк.

2PitStop: ой, ну не сразу разумеется... но в течение года все переползут, поверь. Проходили уже и не раз.

Раньше не было серьезной альтернативы. Теперь-то есть. Причем не только дешевше, но и идеологически более правильная.

2anonymous (*) (2003-02-14 18:39:05.88): а поздно...:) На идеологическию правильность бизнесу вообще насрать...:)

где же поздно, когда самое время?

2sseREGa, 2Irsi:
Нет, симлинк с file.txt на file.txt:DATA не поможет. Если мы сказали
GET /file.txt HTTP/1.0
Мы должны получить _ВСЕ_ потоки файла. Ну в http это как-то решается введением нового mime типа, или траханьем с multipart, НО по ftp протоколу это невозможно никак без сильной его ревизии.
Так что со стандартными протоколами тут промашка. Не будет же гейц создавать mshttp и msftp. :)

Дальше-больше

echo Main Data > myfile.txt
echo Stream 1 Data > myfile.txt:stream1
more < myfile.txt
Main Data
more < myfile.txt:stream1
Stream 1 Data

В эксплорере на него правой кнопкой давим, Send To -> Compressed (zipped) folder, этот фолдер открываем, правой кнопкой на наш файл в этом фолдере, Copy, идем в другую диру, Paste.

more < myfile.txt
Main Data
more < myfile.txt:stream1
The system cannot find the file specified.

А вы говорите зиповать...
Виндовс ХР проф. Сервис пак, АФАИК, поставлен.

2irsi
> man samba или как там правильно БЛЯ!!!!
Извини, но МУДАК ТЫ БЛЯ !!! Живи себе, но не отравляй жизнь другим людям "дурнопахнущей субстанцией", все твои аргументы уходят на $#%%#.

Да, да! Что там с Samba'ой?! Поподробней плз!

2 Irsi (*) (2003-02-14 17:12:16.669)
Ну-ну. Все побегут за пиратскими дисками с новым охфисом, в то время как у многих еще стоит 95-я, ну в лучшем случае 98-я в паре с 97-ым охфисом. До сих пор. И их всё устраивает.
Так что нет. Не побегут. Притом, что покупатели люди как правило более бедные чем поставщики и очень часто не в столице обитают. Вот так.

уЛ, БНГЛНФМН, Ъ ВРН-РН ОПНОСЯРХК (ДЮБМН ЯЧДЮ МЕ ГЮЦКЪДШБЮК, РНКЭЙН ЯЕЦНДМЪ МЮЯЙНПН ОПНЯЛНРПЕК, ВРН РСР ОНМЮОХЯЮКХ), МН МЕЙНРНПНЕ БПЕЛЪ МЮГЮД РСР ЛМНЦН ЦНБНПХКХ, ВРН ТЮИКНБШЕ ОНРНЙХ ЩТТЕЙРХБМЕЕ √ НРЙПШРХЕ ТЮКЮ ОПНХЯУНДХР РНКЭЙН ПЮГ. рЮЙ БНР, ОНЯЛНРПЕК Ъ ОНЛНЫЭ ОН .Net, РЮЙ РЮЛ МЮОХЯЮМН, ВРН НРЙПШБЮРЭ ОНРНЙХ МЮДН ОСРЕЛ ОЕПЕДЮВХ Б ТСМЙЖХЧ CreateFile МЮГБЮМХЪ ТЮИКЮ Б БХДЕ МЮГБЮМХЕ_ТЮИКЮ:ХЛЪ_ОНРНЙЮ, МЮОПХЛЕП, Test.txt:VersionInfo. яОПЮЬХБЮЕРЯЪ, ЦДЕ РСР НДМН НРЙПШРХЕ ТЮИКЮ ДКЪ БЯЕУ ОНРНЙНБ? пЮАНРЮ ХДЕР ЙЮЙ АСДРН ЩРН НАШВМШЕ ТЮИКШ. йЯРЮРХ, РЮЛ БПНДЕ ЙЮЙ ЩРН ДЮФЕ НРЛЕВЮЕРЯЪ: ╚In most cases, you can treat streams as if they were regular files≈for example, to delete a stream resort to DeleteFile()╩. рЮЙНЕ НЫСЫЕМХЕ ВРН ОПНЯРН ТЮИКНБ МЮ ДХЯЙЕ АНКЭЬЕ, ОПНЯРН МЕ БЯЕ НРНАПЮФЮЧРЯЪ Б dir Х Р.О. лНФЕР Х МЮ МХГЙНЛ СПНБМЕ РЮЙ Х ПЕЮКХГНБЮМН? уНРЪ, ЛНФЕР Ъ НЬХАЮЧЯЭ, Х ЕЯРЭ ДПСЦХЕ ТСМЙЖХХ ДКЪ ПЮАНРШ Я ОНРНЙЮЛХ? хКХ, ЛНФЕР, ЯНАХПЮЧРЯЪ ББЕЯРХ МНБНЕ API? йЯРЮРХ, ЛМЕ НДМЮФДШ ДНБЕКНЯЭ МЕЛМНЦН ОНПЮАНРЮРЭ МЮ VMS. рЮЙ РЮЛ БПНДЕ ВРН-РН ОНУНФЕЕ АШКН. йЮФДШИ ТЮИК ЛНЦ ХЛЕРЭ МЕЯЙНКЭЙН БЕПЯХИ Х Б ОНКМНЕ МЮХЛЕМНБЮМХЕ ТЮИКЮ МСФМН АШКН БЙКЧВЮРЭ ЩРНР МНЛЕП БЕПЯХХ. еЯКХ МНЛЕП БЕПЯХХ МЕ СЙЮГШБЮРЭ, МН АПЮКЮЯЭ ОНЯКЕДМЪЪ БЕПЯХЪ ТЮИКЮ.

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

Так вот, посмотрел я помощь в .Net, так там написано, что открывать потоки надо путем передачи в функцию CreateFile названия файла в виде название_файла:имя_потока, например, Test.txt:VersionInfo.

Спрашивается, где тут одно открытие файла для всех потоков? Работа идет как будто потоки это обычные файлы. Кстати, там вроде как это даже отмечается: "In most cases, you can treat streams as if they were regular files, for example, to delete a stream resort to DeleteFile()". Такое ощущение, что просто файлов на диске больше, просто не все отображаются в dir и т.п. Может и на низком уровне так и реализовано? Хотя, может я ошибаюсь, и есть другие функции для работы с потоками? Или, может, собираются ввести новое API?

Кстати, мне однажды довелось немного поработать на VMS. Так там вроде что-то похожее было. Каждый файл мог иметь несколько версий и в полное наименование файла нужно было включать этот номер версии. Если номер версии не указывать, то бралась последняя версия файла.

> Кстати, мне однажды довелось немного поработать на VMS. Так там вроде > что-то похожее было.

Во-первых, это было узкоспециализировано -- только версия и только для автоматического архивирования

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

В-третьих, все эти файлы с версями -- это РАЗНЫЕ файлы, а не один пельмень

VMS-версионирование можно сравнить с тем, как JBuilder ведет bak-файлы

> Кстати, мне однажды довелось немного поработать на VMS. Так там вроде > что-то похожее было.

Во-первых, это было узкоспециализировано -- только версия и только для автоматического архивирования

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

В-третьих, все эти файлы с версями -- это РАЗНЫЕ файлы, а не один пельмень

VMS-версионирование можно сравнить с тем, как JBuilder ведет bak-файлы

> Кстати, мне однажды довелось немного поработать на VMS. Так там вроде > что-то похожее было.

Во-первых, это было узкоспециализировано -- только версия и только для автоматического архивирования

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

В-третьих, все эти файлы с версями -- это РАЗНЫЕ файлы, а не один пельмень

VMS-версионирование можно сравнить с тем, как JBuilder ведет bak-файлы