Альтернативные потоки данных NTFS — хорошая или плохая идея?

Я хотел бы хранить некоторые связанные с приложениями метаданные для файлов, а альтернативные потоки данных NTFS (AltDS) позволили бы мне хранить эти метаданные непосредственно в файлах, а не в отдельной базе данных.

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

Но кроме того, хранение дополнительных данных в файле может стать очень расточительным, поскольку AltDS остается, даже если мое приложение удалено. Это похоже на десятилетие назад, когда люди использовали «Очистители реестра» для удаления ненужных записей из реестра после удаления программы, чтобы их система работала быстрее (и менее стабильно, когда очиститель слишком много очищал ...).

Мне просто интересно, для чего их можно разумно использовать? Должны ли они быть полностью оставлены для использования Microsoft Apps? Или существует какая-то общая политика, какие типы приложений могут их использовать (кроме вредоносных программ)?

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

Подводя итог приведенным пунктам:

Плюсы:

  • Метаданные перемещаются вместе с файлом, поэтому нет необходимости распознавать их по хешированию или имени файла.
  • Работает со всеми типами файлов, даже с файлами .txt, где невозможно хранить какие-либо данные в самом файле.

Минусы:

  • Only works on NTFS which may not be the default file system in future Windows Versions
    • Although it would surprise me if MS doesn't automatically convert them if they ever get WinFS together
  • AltDS остаются, даже если мое приложение удалено
  • Вопросы конфиденциальности
  • Fragile
    • Most USB Sticks are FAT32. Many private file servers are Linux. Downloading a file from the internet should only transfer the file but not the streams. In short: It's rather easy to lose them.

architecture ntfs
person Community    schedule 30.12.2009    source источник

Ответы (8)


arrow_upward
4
arrow_downward

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

Прежде всего, как вы заметили, потоки AD работают только в NTFS. Если есть вероятность, что вам нужно будет хранить эти метаданные в файловой системе FAT, вам понадобится какой-то запасной механизм. Современные ПК, вероятно, будут иметь внутренние жесткие диски в формате NTFS, но большинство флэш-накопителей USB, с которыми вы сталкиваетесь, по-прежнему имеют формат FAT. Имейте это в виду, если ваши пользователи будут хранить файлы данных на флэш-накопителях.

Кроме того, я не могу придумать никаких технологических причин, чтобы избегать потоков AD, но я бы все равно опасался их использования. Люди склонны нервничать по поводу приложений, которые «скрывают» от них данные, независимо от намерений. Рассмотрим фиаско Sony с руткитами и так далее. Я не говорю, что ваше приложение настолько плохо, но люди (особенно менее технически подкованные) могут не заметить разницы. Тем не менее, я допускаю, что они могут иметь действительное применение для вашего приложения. Конечно, проблема оставления потоков AD после удаления все еще очень реальна. Возможно, вы захотите предоставить людям, запускающим деинсталлятор, возможность запустить программу для поиска на своих дисках и очистки любых оставшихся потоков.

Кроме того, помните принцип KISS. Действительно ли использование потоков AD является самым простым способом эффективного решения проблемы хранения метаданных вашего приложения? Если это так, возможно, потоки AD — хорошая идея, но если нет, я бы серьезно подумал о другом подходе.

person Community    schedule 30.12.2009
comment
Спасибо. Данные представляют собой метаданные для системы управления документами. Это в основном что-то для меня и в раннем планировании, но я наткнулся на AltDS и, хотя, чтобы собрать некоторые мнения. Скрытие части данных на самом деле является хорошим моментом. Лишь очень немногие пользователи на самом деле пытаются защитить себя от вредоносных программ (практически все готовы установить дерьмо, если у него есть симпатичный талисман), но большинство людей быстро вмешиваются, когда кто-то называет приложение вредоносным ПО, даже если это необоснованно. - person Michael Stum; 30.12.2009

arrow_upward
6
arrow_downward

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

person Community    schedule 30.12.2009

arrow_upward
3
arrow_downward

Я могу придумать одну вескую причину, по которой не их использовать, и это небольшая заметка из их "руководство по использованию":

Альтернативные потоки данных — это строго функция файловой системы NTFS и может не поддерживаться в будущих файловых системах. Однако NTFS будет поддерживаться в будущих версиях Windows NT.

А теперь... судя по тому, как это сформулировано, технически вы в безопасности. Но если Microsoft когда-нибудь решит заменить/объявить устаревшую NTFS — а в какой-то момент они были довольно близки — вам придется постараться обновить свое программное обеспечение, чтобы оно работало на более новых машинах.

Какой бы маловероятной ни казалась такая возможность сейчас, я думаю, что это менее маловероятно, чем внезапно обнаружить, что вы не можете подключить базу данных SQLCE или XML-файл, хранящийся в AppData пользователя.

Сказав это, я уверен, что есть несколько сценариев, оправдывающих использование ADS. На мой взгляд, это один из тех случаев, когда, если вы не абсолютно уверены в том, что это правильный инструмент, то, скорее всего, это неправильный инструмент.

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

P.S. Очистители реестра больше не используются? Почему мне никто не сказал!?

person Community    schedule 30.12.2009
comment
Хорошая точка зрения. Да, WinFS должна была заменить NTFS, но, насколько я понял, WinFS по-прежнему поддерживает метаданные (поскольку это, по сути, SQL-сервер, встроенный в ОС). Что касается ID3 и EXIF: они хранятся в самом файле, но это хороший момент. Я не проверял, что произойдет, если я загружу файл, который обслуживается с сервера NTFS через IIS в файловую систему NTFS — я надеюсь, что это убьет AltDS, но не проверял. Мое использование будет похоже на EXIF, это для системы управления документами, где я хочу, чтобы данные (на самом деле просто GUID) перемещались при перемещении файла. - person Michael Stum; 30.12.2009

arrow_upward
2
arrow_downward

Альтернативные потоки данных важны для NTFS и всегда будут поддерживаться. Когда файл, к которому они прикреплены, удаляется, они также удаляются, так что не беспокойтесь о том, что они «остаются».

Как уже говорили все остальные, есть проблемы с резервным копированием, копированием в другую файловую систему и паранойей в отношении ADS.

person Community    schedule 24.08.2010

arrow_upward
1
arrow_downward

Если ваше приложение может работать без этих данных, например, воссоздавая их по мере необходимости, потоки данных вполне приемлемы.

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

person Community    schedule 30.12.2009

arrow_upward
1
arrow_downward

Плохая идея для вас, плохая идея для MS. Я думаю, что они действительно были попыткой конкурировать с файловой архитектурой ветвления данных и ресурсов Mac в те дни. Если файлы Mac FS могут иметь 2 форка, то у нас будет неограниченное количество «форков», и, возможно, мы со временем поймем, как их использовать.

person Community    schedule 30.12.2009
comment
Я думал о тех. Насколько я понимаю, Mac OS использует вторую вилку для метаданных, таких как дескрипторы приложения и типа для файлов (поскольку она не зависит от расширений файлов), что позволяет нам сказать, что я хочу открыть этот файл .txt с помощью этого редактора, но этот другой файл .txt с другим редактором. Это работает, потому что он аккуратно интегрирован с Finder, в то время как проводник Windows, кажется, использует AltDS только для надоедливого сообщения «Не могу выполнить этот файл, поскольку он из интернет-сообщения». - person Michael Stum; 30.12.2009
comment
@MichaelStum: вторая вилка старого файла Mac OS содержит неиерархический набор ресурсов, каждый из которых имеет 32-битный тип (обычно представленный четырьмя печатными символами ASCII), 16-битный идентификатор, необязательное имя, и произвольное количество данных (думаю до двух гигов). Файлы приложений часто содержат все в ветке ресурсов и ничего в вилке данных, хотя бывают и исключения. Некоторые текстовые редакторы хранят необработанный текст в ветке данных, а такие вещи, как позиции табуляции, в вилке ресурсов. Некоторые приложения хранят все в вилке ресурсов своих документов. - person supercat; 02.03.2012
comment
Собственно, ADS были добавлены в NTFS специально для совместимости с форками MacOS, а не для того, чтобы конкурировать с ними. Существовали инструменты для перевода веток ресурсов в ADS с одинаковыми именами и наоборот, чтобы избежать потери данных при перемещении файлов между операционными системами. - person Ti Strga; 26.04.2014

arrow_upward
1
arrow_downward

Добавление AltD в файл как способ связать вокруг него строку, специфичную для приложения, имеет проблему, о которой вы говорите: отсутствие очистки. И если файл получает копии, ваши материалы следуют за ним. В этом случае хранение отдельной базы данных, вероятно, будет более целесообразным.

С другой стороны, если файл в значительной степени находится под вашим собственным контролем, тогда, если AltDs — эффективный способ выполнить эту работу, продолжайте.

person Community    schedule 30.12.2009

arrow_upward
0
arrow_downward

Чего я до сих пор НЕ слышал, так это использования AltDS в приложениях, где ДОЛЖНА быть скрыта определенная информация (например, медицинские приложения), в то время как нежелательно скрывать другую информацию.

Причина, по которой я ЛЮБЛЮ AltDS, заключается именно в этом: я могу разработать систему медицинской визуализации, в которой я храню медицинские изображения в открытом виде (т. е. в формате BMP) без каких-либо сведений о пациенте, потому что я могу хранить их в AltDS. Бинго. Преимущество: Если кто-то скопирует файлы на флешку, то все, что он получит, это BMP без информации о пациенте.

Резервное копирование/восстановление всегда неприятно — мое решение состояло в том, чтобы перейти к проприетарному формату файла для резервной копии, где информация о пациенте кодируется/зашифровывается в том же файле, что и (необработанный) BMP.

Наконец, если вы храните скрытую информацию в формате XML, ваше приложение может исчезнуть, но информация все еще там. Информация должна быть связана с самим файлом, а не с приложением. Вероятно, это должно храниться где-то еще.

В целом я L-O-V-E AltDS. Отсутствие поддержки ОС (не могу увидеть данные AltDS), отсутствие общих/общедоступных знаний (кто? что? реклама? какая реклама) и тот факт, что мне не нужно беспокоиться об этой дополнительной информации, которую нужно хранить. синхронизация с основным файлом (гм, Stream) позволяет мне проектировать и реализовывать действительно надежные системы. Резервное копирование - это облом - особенно Джолиет должен был быть разработан для обработки этих AltDS - но я могу с этим смириться.

Просто мои 2с (ну может 3с...).

person Community    schedule 20.12.2010
comment
Если флэш-накопитель отформатирован в NTFS, AltDS идет с ним, но вся информация в нем все равно должна быть зашифрована. Но ваш сценарий именно тот, который я имел в виду: прикрепить метаданные, сохраняя при этом сам файл неизменным/неповрежденным. - person Michael Stum; 21.12.2010
comment
То, как это было написано, очень беспокоит меня как инженера по безопасности. Альтернативные потоки данных не являются функцией безопасности, и то, что вы не видите их в проводнике Windows, не означает, что они являются барьером безопасности или их нельзя просмотреть. Если вы шифруете метаданные, это нормально, но полагаться на то, что они недоступны через проводник или иногда не копируются вместе с файлом, — очень опасные меры безопасности. - person Peter Oehlert; 30.12.2010
comment
ака безопасность через неизвестность. Я содрогаюсь при мысли о том, что любой, кто знает, как напечатать :space_dude_alien's_secret_stuff в конце моих рентгеновских растровых изображений, может легко получить медицинские данные Закона о конфиденциальности ... - person Ti Strga; 26.04.2014