LINUX.ORG.RU
Форум — Development  

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

 , , ,


0

1

Здравствуйте. Пишу файловый менеджер в рамках проекта окружения рабочего стола и возник вопрос. Я хочу реализовать теги (как в Mac OS X). У меня активно используется JSON, но я так полагаю, что быстро работать это не будет (файлов может быть много помечено тегом во всей файловой системе, и надо при переходе в каждую директорию проверять наличие файла в списке файлов, помеченных тегом). Пришла в голову идея использовать для этого базу данных. Подскажите, пожалуйста, какую именно лучше использовать, какая будет работать быстрее и с какой будет проще работать в Qt? Спасибо.

★

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

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

emorozov ☆
()
Ответ на: комментарий от thm

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

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

alex1101 ☆
()
Последнее исправление: alex1101 (всего исправлений: 1)
Ответ на: комментарий от thm

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

Vsevolod-linuxoid ★★★★★
()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 1)
Ответ на: комментарий от dataman

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

thm ★
() автор топика
Последнее исправление: thm (всего исправлений: 1)
Ответ на: комментарий от thm

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

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

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

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

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

dataman ★★★★
()
Ответ на: комментарий от thm

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

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

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

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

QsUPt7S ★
()
Последнее исправление: QsUPt7S (всего исправлений: 1)
Ответ на: комментарий от thm

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

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

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

cobold ★★★★★
()

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

dimgel ★★★★★
()

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

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

hargard ★★
()

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

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

hobbit ★★★★★
()

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

thesis ★★★★★
()

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

annulen ★★★★★
()

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

crutch_master ★★★★★
()
Ответ на: комментарий от emorozov

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

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

annulen ★★★★★
()
Ответ на: комментарий от thm

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

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

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

alex1101 ☆
()
Ответ на: комментарий от dataman

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

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

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

sergej ★★★★★
()

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
);

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 2)
Development