setfattr

Такой программы нет в portage (

attr

Description: Utilities for manipulating filesystem extended attributes
 A set of tools for manipulating extended attributes on filesystem objects, in
 particular getfattr(1) and setfattr(1). An attr(1) command is also provided
 which is largely compatible with the SGI IRIX tool of the same name.

Для ext тоже что-то такое есть, но я не знаю, можно ли писать в атрибуты отсебятину.

Так картинки или файлы?

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

Это совсем не то что нужно.

Это единственный способ. Из этой же оперы NTFS streams. Все остальные способы — комментарии, специфичные для форматов файлов.

Перетащи БД в новую KDE или на новый компьютер. Там же внутри MySQL.

Чоита потеряются? Они же в хомяке хранятся.

> Это единственный способ.

Как ты собрался свойства файловой системы копировать на другой комп?

Как ты собрался свойства файловой системы копировать на другой комп?

rsync

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

Файлы не нужны.

Но, да, отомрут они не скоро.

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

Вспомнил files.bbs, dirinfo и прочее. Правда, не в курсе, как сейчас с этим.

http://knotes.ru/2010/12/nepomuk-backup/

Там Virtuoso

gwenview

умеет прописывать комментарии в exif. Естественно, длина комментария ограничивается спецификацией exif.

В ntfs есть возможность задать комментарий к файлу.

Как с этим делом под линукcовыми ФС?

Иногда жизненно необходимо сделать что-то типа readme к папке.

Нет ли костыля такого костыля чтобы поддерживался файловыми менеджерами?

Помню раньше были файлики типа *.nfo или FILE_ID.DIZ и их подхватывали некоторые просмотрщики.

> Файлы не нужны.

А что вместо?

> Иногда жизненно необходимо сделать что-то типа readme к папке.

Файл README внутри папки создать не получается?

>В ntfs есть возможность задать комментарий к файлу.

Как это сделать? Гугль ничего не знает про это.

Костыль и неудобно. В 90% случаев его содержание сразу нужно просто видеть, а не набивать vim README.

>>Гугль ничего не знает про это.

4.2

Alternate Data Streams же.

> А что вместо?

Как некий транспорт, низкоуровневый механизм работы с накопителем, они несомненно сохранятся.

Изменится работа с данными вообще. Хотя это и будет нескоро. Прежде всего работа будет происходить не непосредственно с сырыми данными а с, если можно так выразиться, содержанием. Грубо это можно сравнить с векторизацией растра: с векторной картинкой можно легко работать, например сравнивать или отображать миниатюру или фрагмент, а исходный растр при этом хранить и, по мере необходимости, использовать. Если мы, скажем, при этом понимаем ещё и каково содержание этого изображения, то довольно большое количество обращений к исходному материалу становится не нужным, значительная часть работы будет происходить прямо с метаданными.

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

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

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

Дык придумали же расширенные атрибуты. В OS/2 в них стандартно хранятся десктопные иконки и длинные имена. Их даже архиваторы поддерживают. Рульная вещь, в них удобно контрольную сумму хранить и всякое прочее. Почему в линуксах практически не используются, диву даюсь, хотя есть гайдлайны для имён расширенных атрибутов, например.

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

Столкнулся с такой неоходимостью когда появилось примерно 1Tb данных (картинок, видео, аудиокниг), которые нужно как-то разместить чтобы потом быстро найти. Конфепция директорий здесь ущербна. Наилучший способ - ключевые слова. Костыль - делать диретории с названием ключевых слов и линки данных в каждую из этих директорий. Данные легко ищутся через find. Касательно комментариев. Если посмотреть на данные, то это в основном mp3 (аудиокниги), avi/mpg... (видеоуроки, короткие ролики), html (сохраненные страницы), pdf, немного картинок. AFAIK в mp3 и exif отлично сохраняются комменты, в остальных - под вопросом. Но если можно в файле сохранять комменты, то и nepomuk отлично это подхватит и вопрос с копированием решен.

I hope this helps.

А вообще, наверное это я туплю:

http://en.wikipedia.org/wiki/Extended_file_attributes
" extended attributes are usually limited in size to a value significantly smaller than the maximum file size. Typical uses can be storing the author of a document, the character encoding of a plain-text document, or a checksum."

http://www.linux.org.ru/forum/talks/4947376
Может это правда выход?

Эмм, кстати, в свойствах файлов и папок гнома есть поле под заметки. Как это реализовано?

>Перетащи БД в новую KDE или на новый компьютер. Там же внутри MySQL.

Угу. А если я файлик в консоли скопирую?

>Вспомнил files.bbs, dirinfo и прочее.

Самый распространённый стандарт был - descript.ion

Правда, не в курсе, как сейчас с этим.

Под Linux - никак. Под виндой, вроде, старые инструменты работают.

> > Перетащи БД в новую KDE или на новый компьютер. Там же внутри MySQL.

Угу. А если я файлик в консоли скопирую?

Честно говоря, я вас не понимаю.

Плюс я ошибся. Это akonadi хранит данные в MySQL, а не nepomuk.

>Иногда жизненно необходимо сделать что-то типа readme к папке.

Файл README? ;)

...

С каталогом, как раз, всё просто. С файлами - хуже.

...

Я обычно просто вместе с файлом file.ext создаю текстовый файлик file.ext.txt, где и храню всё, что нужно.

>а не набивать vim README.

А F3 в mc нажать? :)

>> Почему в линуксах практически не используются, диву даюсь

А кто запрещает? Используй.

>в mp3 и exif отлично сохраняются комменты, в остальных - под вопросом

В HTML комментарии прекрасно сохраняются в виде <!-- комментарий --> :)

>Эмм, кстати, в свойствах файлов и папок гнома есть поле под заметки. Как это реализовано?

~/.local/share/gvfs-metadata

>Честно говоря, я вас не понимаю.

Если я пропишу комментарий к файлу средствами akonadi или nepomuk, что там у вас используется и потом перенесу этот файл в другой каталог минуя KDE (в консоли по mv, или в mc по F6) - комментарий за файлом останется?

Я не пользуюсь nepomuk, комменарии к файлам ставлю крайне редко, поэтому понятия не имею. :-)

Да, и файлы средствами KDE тоже копирую в исключительных случаях. И это практически единственное исключение --- SMB. Если вместе с SMB есть SSH, то пользую SSH через Konsole. :-)

А кто запрещает? Используй.

Это примерно как использовать приборы на 110 вольт. Никогда не забывать, что кругом 220, таскать с собой понижающий трансформатор и т. д. Но всё равно спасибо, что не запрещаете :)

Спасибо

Аааа! Работает!!!

kroz@lix:~/tmp> attr -s description -V "Home of Daniel Robbins" Coffee_House.png 
Attribute "description" set to a 22 byte value for Coffee_House.png:
Home of Daniel Robbins

kroz@lix:~/tmp> attr -l Coffee_House.png 
Attribute "description" has a 22 byte value for Coffee_House.png

kroz@lix:~/tmp> attr -q -g description Coffee_House.png 
Home of Daniel Robbins

Потребовалось перемонтировать ФС с аттрибутом user_xattr (ReiserFS).

kroz@lix:~/tmp> mount | grep home
/dev/sda7 on /home type reiserfs (rw,noatime,data=journal,acl,user_xattr,barrier=flush)

Good news:
rsync с ключем -X или --xattrs сможет бекапить такие файлы.
То, что nepomuk по слухам поддерживает расширенные аттрибуты, решает проблему с поиском! Viva KDE!
Любое перемещение/переименование с помощью mv, mc, Dolphin сохраняет extended attributes по крайней мере в рамках одного тома.

Bad news:
Любое копирование с помощью cp, mc, Dolphin игнорирует extended attributes :(

Спасибо топикстартеру что заставил покопаться в этом направлении.

Теперь осталось добавить поддержку других языков в этих атрибутах и добавить поддержку этих атрибутов в Nepomuk, чтобы он прямиком туда теги писал )

для картинок есть EXIF, для музыки - теги, для видео - тоже всякая инфа вшивается

Вот единого фронтенда к этому не встречал, да

> Иногда жизненно необходимо сделать что-то типа readme к папке.

Приведи примеры.

Попросил создателей Midnight Commander сохранять расширенные аттрибуты при компировании :)

Ticket 2468

Под пример подходят все случаи употребления файла readme.

Небольшие правки:

rsync и cp поддерживают расширенные аттрибуты. В Gentoo нужно проследить чтобы для rsync и coreutils был установлен USE-флаг xattr (глобальный).

Чтобы cp сохранял расширеннные аттрибуты нужно добавить ключ --preserve=xattr

А я вообще уже дописал в /etc/bash/bashrc

alias cp="cp --preserve=xattr"

> Под пример подходят все случаи употребления файла readme.

Так README не нужен.