NTFS альтернативные потоки данных-хорошая или плохая идея?
Я хотел бы сохранить некоторые связанные с приложением метаданные для файлов, а NTFS Alternate Data Streams (AltDS) позволит мне хранить эти метаданные непосредственно в файлах, а не в отдельной базе данных.
Я просто не чувствую, что это хорошая идея. Я знаю, что это работает только на NTFS, но, по крайней мере, если пользователь копирует/перемещает файлы на диск не NTFS, они получают предупреждение от Windows (да, да, никто не читает предупреждения, я знаю) -
но также, хранение дополнительные данные в файле могут стать очень расточительными, так как AltDS остаются, даже если мое приложение удалено. Это как десять лет назад, когда люди использовали "очистители реестра", чтобы удалить бесполезные записи из реестра после удаления программы, чтобы сделать их систему работать быстрее (и менее стабильной, когда очиститель очистил слишком много...).
Мне просто интересно, что они могут быть достаточно используется? Должны ли они быть полностью оставлены для использования приложениями Microsoft? Или есть что-то вроде общая политика какие типы приложений могут их использовать (кроме вредоносных программ)?
Edit: просто чтобы уточнить, что мой идея была. Я на ранней стадии написания небольшой системы управления документами для себя. Поскольку я хочу иметь свободу перемещения файлов, я хочу хранить метаданные в файле, чтобы, если я перемещаю/переименовываю/изменяю их, мое приложение все равно их распознает. Это могут быть либо все метаданные, либо только GUID, который работает с отдельным база данных.
суммируя точки дано:
плюсы:
- метаданные перемещаются с файлом, поэтому нет необходимости распознавать его через хэширование или имя файла
- работает со всеми типами файлов, даже .txt файлы, где невозможно хранить любые данные в самом файле
плюсы:
- работает только на NTFS, которые не могут быть файловой системой по умолчанию в будущих версиях Windows
- хотя удивило бы меня, если MS не преобразует их автоматически, если они когда-либо получают WinFS вместе
- AltDS остаются, даже если мое приложение удалено
- конфиденциальность
- хрупкие
- большинство USB-накопителей-FAT32. Многие частные файловые серверы под управлением Linux. Загрузка файла из интернета должна передавать только файл,но не потоки. Короче говоря, потерять их довольно легко.
8 ответов
трудно сказать без дополнительной информации о том, какие данные вы храните. Вы, кажется, знаете о некоторых проблемах, связанных с их использованием, поэтому я не уверен, насколько я могу помочь. Вот мои общие мысли об альтернативных потоках данных:
прежде всего, как вы заметили, рекламные потоки работают только на NTFS. Если есть шанс, что вам понадобится сохранить эти метаданные в файловой системе FAT, вам понадобится какой-то резервный механизм. Современные ПК, вероятно, будут иметь NTFS-отформатированные внутренние жесткие диски, но большинство флэш-накопителей USB, с которыми вы сталкиваетесь, по-прежнему отформатированы FAT. Имейте это в виду, если ваши пользователи будут хранить файлы данных на флеш-накопителях.
помимо этого, я не могу придумать никаких технологических причин, чтобы избежать рекламных потоков, но я все еще опасаюсь их использования. Люди, как правило, нервничают по поводу приложений, которые "скрывают" от них данные, независимо от намерения. Рассмотрим фиаско Sony rootkit и так далее. Я не говорю, что твое заявление примерно так же плохо, как это, но люди (особенно менее технически подкованные) могут не различать. Тем не менее, я допускаю, что они могут иметь действительное использование для вашего приложения. Конечно, проблема оставления рекламных потоков после удаления по-прежнему очень реальна. Возможно, вы захотите предоставить людям, запускающим деинсталлятор, возможность запуска программы для поиска их дисков и очистки любых оставшихся потоков.
еще, помню поцелуй принцип. Является ли использование рекламных потоков действительно самым простым способом эффективного решения проблемы хранения метаданных вашего приложения? Если это так, возможно, рекламные потоки-хорошая идея, но, если нет, я серьезно подумаю о другом подходе.
еще один момент: резервное копирование программного обеспечения. Некоторые игнорируют его, некоторые не восстанавливают, а некоторые поддерживают его, но ничего не делают без вашего приказа.
Я могу придумать одну хорошую причину не использовать их, и это маленький лакомый кусочек от их "как использовать" руководство:
альтернативные потоки данных являются строго особенностью файловой системы NTFS и может не поддерживаться в будущих файловых системах. Однако NTFS будет поддерживаться в будущих версиях Windows NT.
сейчас... как это сформулировано, я думаю,технически ты в безопасности. Но если Microsoft когда - либо решает заменить/осудить NTFS - и они подошли довольно близко в какой-то момент-тогда вам придется карабкаться, чтобы обновить программное обеспечение, чтобы оно работало на новых машинах.
Так же маловероятно, как эта возможность может показаться сейчас, я думаю, что это меньше вряд ли чем внезапно обнаружив, что вы не можете подключить базу данных SQLCE или XML-файл, хранящийся в AppData пользователя.
сказав это, я уверен, что есть некоторые сценарии, которые оправдывают использование рекламы. На мой взгляд, это всего лишь один из тех случаев, когда, если вы не абсолютно точно что это правильный инструмент, то это, наверное, неправильно.
прикрепление метаданных к файлам в целом-опасная игра. Просто посмотрите на нечестивый беспорядок, который ID3 и смущающие результаты людей, оставляющих данные EXIF в изображениях.
П. С. чистильщики реестра больше не используется? Почему мне никто не сказал??
альтернативные потоки данных необходимы для NTFS и всегда будут поддерживаться. Когда файл, к которому они прикреплены, удаляется, они также удаляются - поэтому не беспокойтесь о том, что они "торчат"
Как и все остальные, есть проблемы с резервным копированием, копированием в другую файловую систему и паранойей в отношении рекламы.
Если ваше приложение может функционировать без этих данных, например, воссоздавая его по мере необходимости, потоки данных вполне приемлемы.
учитывая, как они используются в windows, я не думаю, что они уйдут в ближайшее время.
плохая идея для вас, плохая идея для MS. я думаю, что они действительно были попыткой конкурировать с архитектурой файлов данных и ресурсов Mac в тот день. Если файлы Mac FS могут иметь 2 вилки, то наши будут иметь неограниченные "вилки", и, возможно, мы в конечном итоге выясним, как их использовать.
добавление AltDs в файл как способ связать строку приложения вокруг него имеет проблему, которую вы цитируете: нет очистки. И если файл получает копии, ваши вещи следуют за ним. В этом случае ведение отдельной базы данных, вероятно, более целесообразно.
Если файл, с другой стороны, очень под вашим собственным контролем, то, если AltDs является эффективным способом выполнить работу, продолжайте.
одна вещь, которую я до сих пор не слышал, - это использование AltDS в приложениях, где определенная информация должна быть скрыта (т. е. медицинские приложения), в то время как желательно не скрывать другую информацию.
причина, по которой я люблю AltDS, именно в этом: я могу создать систему медицинской визуализации, где я храню медицинские изображения в открытом виде (как BMP, т. е.) без каких-либо деталей информации о пациенте, потому что те, которые я могу хранить в AltDS. Бинго. Преимущество: если кто-то копирует файлы в thumb-drive-ну, все, что человек получает, это BMP без информации о пациенте.
резервное копирование / восстановление всегда неприятно - мое решение состояло в том, чтобы перейти к проприетарному файлу-формату на резервной копии, где информация о пациенте закодирована/зашифрована в том же файле, что и (raw) BMP.
наконец, если вы храните скрытую информацию в формате XML, ваше приложение может отсутствовать, но информация все еще там. Информация должна быть связана с самим файлом, а не приложения. Это должно вероятно, хранится где-то в другом месте.
Общий I L-O-V-E AltDS. Отсутствие поддержки ОС (не видно данных AltDS), отсутствие общих/общедоступных знаний (кто? что? Объявления? Какие рекламные объявления) и тот факт, что мне не нужно беспокоиться о том, что дополнительная информация синхронизируется с основным файлом (ahem Stream), позволяет мне разрабатывать и внедрять действительно надежные системы. Резервная копия-облом , особенно Джолиет должен был быть разработан, чтобы справиться с этими AltDS , но я могу жить с он.
просто мой 2c (ну, может быть, 3c...).