Использование БД в файловом менеджере

Отлично, теперь ещё и менеджеру файлов нужна будет какая-нибудь MariaDB 😄

А как тогда решить проблему с тегами?

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

Для чего вообще нужны такие теги?

идея использовать для этого базу данных

И правильно!

какую именно лучше использовать

SQLite

с какой будет проще работать в Qt?

http://katecpp.github.io/sqlite-with-qt/

Или использовать sqlite_orm.

Можно использовать расширенные атрибуты файловой системы, например.

Я про цветные теги в Finder. Сомневаюсь, что атрибутами их можно реализовать.

Спасибо, посмотрю.

Почему нельзя? Храни в атрибутах слова «red», «yellow», «green» и т.д. А менеджер файлов пусть их переводит в теги соответствующего цвета.

Можно вместо слов сразу код цвета хранить.

Можно, почему нет. В том же Chrome и Chromium на Linux по умолчанию в атрибутах попросту пишется адрес сайта, с которого был скачан файл — то есть в них можно указывать произвольный текст.

RGB код лучше.

Да, этот вариант, естественно, лучше. Попробую.

Вопрос только в другом. А работают ли эти атрибуты универсально во всех файловых системах (ext*, vfat, …)?

Не надо так делать. Сразу вспомнился антивирус Касперского, который засирал NTFS-streams файлов своей инфой.

нужно еще больше семантических велосипедов!!1

https://www.xmodulo.com/kde-semantic-desktop-nepomuk-baloo.html

Но, если делать бэкапы, теги, действительно, пропадут. + надо пробивать содержимое каждой открываемой директории по БД. Или есть какой-то другой вариант?

1. Какова цель? ФМ сугубо для личного использования или нет? Со своими файлами поступайте, как угодно, а вмешательством в свои файлы пользователи будут очень недовольны.

2. Не все ФС имеют расширенные атрибуты.

3. В Far, например, есть возможность добавлять описания к файлам. Они хранятся в файле descript.ion (или другом) каждой папки.

надо пробивать содержимое каждой открываемой директории по БД

Да. А плюс в том, что по запросу можно получить список всех файлов с заданными тегами. В подходе с descript.ion это невозможно.

1. И для личного, и для людей. Понял, буду использовать БД.
2. Тем более, потому что поддержка нужна везде.
3. Да, забыл. Список файлов с тегом тоже нужен.

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

Тут несколько системных противоречий возникает.

Если хранить метаданные в не обеспечиваемом самой фс хранилище (база данных, .directory файлы в каталогах (так поступает например Dolphin в KDE), и т.д.), то обеспечить перенос этих метаданных с файлами можно только в утилитах которые про эти метаданные знают.

С другой стороны, хранилища метаданных обеспечиваемые самой фс, такие как extended attributes, или ntfs streams, обеспечат автоматический перенос метаданных, при условии, что фс накопителя-реципиента тоже умеет в extended attributes, а программа копирования это всё учитывает. Но возникает другая проблема: эти данные становятся мешающим мусором, если пользователь откажется от использования программы, или файлы будут перенесены между машинами, где на машине-приёмнике не установлена программа умеющая в такие метаданные.

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

А как тогда решить проблему с тегами?

Посмотреть, как Dolphin сохраняет xattrs (extended attributes) и использовать что-то наподобии Baloo.

Если ты будешь использовать БД, то

• переустановка системы, тэги потеряны
• диск с другой системы не подключишь
• старый диск может и не открыться потому что в новом ФМ поменялась структура БД

Ну а в макос это как решено? Небось через те же xattrs, а там где они не поддерживаются срёт в директорию каким-нить скрытым файлом

Глянь TMSU. Но если очень хочется самому и базу, то плюсую SQLite: embedded, на десктопах и смартфонах используется всеми кому не лень как раз в похожих сценариях.

1. А можешь рассказать, хотябы слов в 50, зачем эти теги нужны, кроме как для отравки файликов на печать из дубового однопанельного «эксплорера», не умеюещего как dolphin в move to../copy to...?

2. Зачем городить json или БД, если можно просто накидать линков в ~/.local/share/fmname/tags/tagname?

Пишу файловый менеджер

Почему-то никто на это не стриггерился. А что вообще в этом ФМ планируется сделать, кроме тегов? Он будет проводникообразным или наоборот, двухпанельным, а может, что-то третье?..

Не нужно отдельную БД, выше привели примеры почему, используй xattrs если очень хочется тегов

А что, все остальное в твоем гипотетическом ФМ уже настолько чудесное, что теперь можно всерьез заняться обвешиванием его бессмысленной херотенью?

Ну вот я стриггерился.

Он будет полупроводником.

Почему-то никто на это не стриггерился

Да вообще, позор какой-то.

Отлично. Можно будет собрать из него транзистор.

Тут данные вида «ключ-значение», значит подойдёт любая бд, позволяющая хранить такие данные. Можно взять что-то типа bdb или Tokyo Cabinet. SQLite, в принципе, не плохой вариант, но для быстрого извлечения значений по ключам придется создавать индекс.

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

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

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

libmdbx же.

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

Поэтому да, это не самый надёжный вариант, но отдельная база или файл это ещё хуже с т.з. переносимости.

Можно пойти третьим путём и внаглую добавлять числовой код тега прямо в имя файла, перед точкой с расширением. Т.е. будет что-то вроде golaya-dafni-kin-nude-xxxznamenitosti-20231106-265.webp, где числовой код тега (265) мало что меняет в UX.

Не надо так делать. Сразу вспомнился антивирус Касперского, который засирал NTFS-streams файлов своей инфой

надо, тот сам засирал, а тут пользователь хочет и лично указывает чем нужно засрать.

по крайней мере это точно лучше чем база :)

Вам вот всё шуточки, а переделывать будет ТС.

После того, как ★ на Гитхабе не досчитается и донатов не получит.

HTFS предоставляет возможность создания нескольких stream для файлов.

Что это такое?

А вот что.
Создаёте текстовый файл размером 1 байт и создаете в нём 10 stream по 1TB.

Файловые менеджеры будут бодро рапортовать, что файл размером один байт.

Попробуйте сделать дубль этого "одного байта".

Streams могут быть ЧЕМ УГОДНО!

Малюсенькая выдержка из моего class, для работы с файлами.

HANDLE     FindFirstStreamTransactedW(                     // Enumerates the first stream in the specified file or directory as a transacted operation
 __in  LPCWSTR             lpFileName, 
 __in  STREAM_INFO_LEVELS  InfoLevel, 
 __out LPVOID              lpFindStreamData, 
 __in  DWORD               dwFlags, 
 __in  HANDLE              hTransaction
);

HANDLE     FindFirstStreamW(                               // Enumerates the first stream in the specified file or directory.
 __in  LPCWSTR             lpFileName, 
 __in  STREAM_INFO_LEVELS  InfoLevel, 
 __out LPVOID              lpFindStreamData, 
 __in  DWORD               dwFlags
);

#endif                                                     // #if ( _WIN32_WINNT > 0x0601 ) 

BOOL       FindNextFile(                                   // Continues a file search from a previous call to the FindFirstFile or FindFirstFileEx function
 __in  HANDLE             hFindFile, 
 __out LPWIN32_FIND_DATA  lpFindFileData
);

#if ( _WIN32_WINNT > 0x0601 )                              // Windows Server 2008

BOOL       FindNextStreamW(                                // Continues a stream search started by a previous call to the FindFirstStreamW function.
 __in  HANDLE  hFindStream, 
 __out LPVOID  lpFindStreamData
);

#endif                                                     // #if ( _WIN32_WINNT > 0x0601 ) 

BOOL       Close(                                          // Close file or stream
 HANDLE  hStream = NULL
);

BOOL       GetPosition(                                    // Get value the current value of the file pointer
 HANDLE  hStream = NULL
);