Support multiple MIME DB directories
Each installation location (system, common, common/non-packaged,
~/config, ~/config/non-package) can now have a read-only data/mime_db
directory. ~/config/settings/beos_mime is now named mime_db as well. The
contents of all directories makes up the MIME DB. Entries in more
specific locations shadow entries in more general locations. Only the
directory in ~/config/settings is where the registrar writes changes to.
The new layout allows packages to contribute entries to the MIME DB by
simply providing the respective files in data/mime_db. Consequently the
user settings directory is supposed to contain only the things the user
has actually changed.
Seems to work fine as far as tested. A few issues, though:
* The registrar doesn't monitor the directories yet, so it doesn't
notice entry changes due to package de-/activation.
* ATM it is not possible to remove a MIME type that is not in the user
settings directory, although the FileTypes GUI suggests that it is.
We'd have to work with white-outs, since we cannot remove the files in
the data/mime_db directories. Or, alternatively, the API has to be
extended and the FileTypes GUI adjusted to disable the "Remove" button
in such a case.
2013-05-07 06:43:15 +04:00
|
|
|
/*
|
|
|
|
* Copyright 2013, Haiku, Inc. All Rights Reserved.
|
|
|
|
* Distributed under the terms of the MIT License.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Ingo Weinhold <ingo_weinhold@gmx.de>
|
|
|
|
*/
|
|
|
|
#ifndef DATABASE_DIRECTORY_H
|
|
|
|
#define DATABASE_DIRECTORY_H
|
|
|
|
|
|
|
|
|
|
|
|
#include <MergedDirectory.h>
|
|
|
|
|
|
|
|
|
2013-05-07 19:54:29 +04:00
|
|
|
namespace BPrivate {
|
|
|
|
namespace Storage {
|
|
|
|
namespace Mime {
|
|
|
|
|
|
|
|
|
2013-05-08 01:15:36 +04:00
|
|
|
class DatabaseLocation;
|
|
|
|
|
|
|
|
|
Support multiple MIME DB directories
Each installation location (system, common, common/non-packaged,
~/config, ~/config/non-package) can now have a read-only data/mime_db
directory. ~/config/settings/beos_mime is now named mime_db as well. The
contents of all directories makes up the MIME DB. Entries in more
specific locations shadow entries in more general locations. Only the
directory in ~/config/settings is where the registrar writes changes to.
The new layout allows packages to contribute entries to the MIME DB by
simply providing the respective files in data/mime_db. Consequently the
user settings directory is supposed to contain only the things the user
has actually changed.
Seems to work fine as far as tested. A few issues, though:
* The registrar doesn't monitor the directories yet, so it doesn't
notice entry changes due to package de-/activation.
* ATM it is not possible to remove a MIME type that is not in the user
settings directory, although the FileTypes GUI suggests that it is.
We'd have to work with white-outs, since we cannot remove the files in
the data/mime_db directories. Or, alternatively, the API has to be
extended and the FileTypes GUI adjusted to disable the "Remove" button
in such a case.
2013-05-07 06:43:15 +04:00
|
|
|
class DatabaseDirectory : public BMergedDirectory {
|
|
|
|
public:
|
|
|
|
DatabaseDirectory();
|
|
|
|
virtual ~DatabaseDirectory();
|
|
|
|
|
2013-05-08 01:15:36 +04:00
|
|
|
status_t Init(DatabaseLocation* databaseLocation,
|
|
|
|
const char* superType = NULL);
|
Support multiple MIME DB directories
Each installation location (system, common, common/non-packaged,
~/config, ~/config/non-package) can now have a read-only data/mime_db
directory. ~/config/settings/beos_mime is now named mime_db as well. The
contents of all directories makes up the MIME DB. Entries in more
specific locations shadow entries in more general locations. Only the
directory in ~/config/settings is where the registrar writes changes to.
The new layout allows packages to contribute entries to the MIME DB by
simply providing the respective files in data/mime_db. Consequently the
user settings directory is supposed to contain only the things the user
has actually changed.
Seems to work fine as far as tested. A few issues, though:
* The registrar doesn't monitor the directories yet, so it doesn't
notice entry changes due to package de-/activation.
* ATM it is not possible to remove a MIME type that is not in the user
settings directory, although the FileTypes GUI suggests that it is.
We'd have to work with white-outs, since we cannot remove the files in
the data/mime_db directories. Or, alternatively, the API has to be
extended and the FileTypes GUI adjusted to disable the "Remove" button
in such a case.
2013-05-07 06:43:15 +04:00
|
|
|
|
|
|
|
protected:
|
|
|
|
virtual bool ShallPreferFirstEntry(const entry_ref& entry1,
|
|
|
|
int32 index1, const entry_ref& entry2,
|
|
|
|
int32 index2);
|
|
|
|
|
|
|
|
private:
|
|
|
|
bool _IsValidMimeTypeEntry(const entry_ref& entry);
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2013-05-07 19:54:29 +04:00
|
|
|
} // namespace Mime
|
|
|
|
} // namespace Storage
|
|
|
|
} // namespace BPrivate
|
|
|
|
|
|
|
|
|
Support multiple MIME DB directories
Each installation location (system, common, common/non-packaged,
~/config, ~/config/non-package) can now have a read-only data/mime_db
directory. ~/config/settings/beos_mime is now named mime_db as well. The
contents of all directories makes up the MIME DB. Entries in more
specific locations shadow entries in more general locations. Only the
directory in ~/config/settings is where the registrar writes changes to.
The new layout allows packages to contribute entries to the MIME DB by
simply providing the respective files in data/mime_db. Consequently the
user settings directory is supposed to contain only the things the user
has actually changed.
Seems to work fine as far as tested. A few issues, though:
* The registrar doesn't monitor the directories yet, so it doesn't
notice entry changes due to package de-/activation.
* ATM it is not possible to remove a MIME type that is not in the user
settings directory, although the FileTypes GUI suggests that it is.
We'd have to work with white-outs, since we cannot remove the files in
the data/mime_db directories. Or, alternatively, the API has to be
extended and the FileTypes GUI adjusted to disable the "Remove" button
in such a case.
2013-05-07 06:43:15 +04:00
|
|
|
#endif // DATABASE_DIRECTORY_H
|