On Thu, Nov 7, 2013 at 7:02 PM, Andrej N. Gritsenko <andrej@rep.kiev.ua> wrote:

PCMan has written on Thursday,  7 November, at 11:22:
>On Thu, Nov 7, 2013 at 10:48 AM, Andrej N. Gritsenko <andrej@rep.kiev.ua>wrote:
>>     I'm currently working on implementation of next feature for PCManFM.
>> It is different sort and view mode for selected folders. I.e. user can
>> check an option 'Use these settings for this folder only' and sort (and
>> view mode) will be remembered for current folder independently from
>> common settings. The question is how to do that. I know two ways now:

>> 1. Use '.directory' file in folder in question.
>>  Pros:
>>   - can be used by other implementations and other file managers;
>>   - settings persist if folder is renamed;
>>   - settings persist if folder is accessed other way (via ssh, ftp, etc.).
>>  Cons:
>>   - can be used only if user can write into .directory file in folder.

>> 2. Use cache file somewhere.
>>  Pros:
>>   - can be used against system directories (/usr for example).
>>  Cons:
>>   - completely implementation-dependent and even environment-dependent;
>>   - settings are lost when folder is renamed;
>>   - it may be impossible to have different settings for removable media;
>>   - cache will grow indefinitely, no sane cleaning heuristics exist.

>>     I would appreciate all your opinions and I'm waiting for them until I
>> start implementing it. Thank you in advance.

>Well, I've been thinking about the issue for quite a long time but did not
>do it since I couldn't find a really satisfying solution.
>A cache is the most reliable, but it's hard to maintain and it's easy to
>Deleting dead entries in the cache periodically is needed. Otherwise the
>cache will be full of garbage after a period of time.
>Windows seems to use this approach and the info is in windows registry.
>Thunar uses similar way, and the info is stored in a tdb file.
>Tdb is the trivial key-value db developed by Samba and it's good enough for
>the task.
>Nautilus seems to use similar approach, but they use text-based meta-info
>files stored somewhere rather than a db, which is very inefficient.
>A key-value based binary db with periodic dead-entry clearance is
>Good candidates are samba tdb and sqlite.

    I really hate the cache solution - it is completely implementation
dependent and you even have to implement it exactly the same in each
application if you want them to be compatible. And yes, any cache is easy
to break if any crash happens in time of its rebuild.

>Another good stuff to use is xattr. Most modern filesystems support it.
>This is the best place to store this kind of info.
>Pros: widely-available, creates no junk, can be accessed by others easily.
>Will not be included when you try to tar a dir (this beats the .directory
>Cons: not available on read-only FS, remote FS, and windows FS, such as
>ntfs and vfat.

>The last one is .directory approach. I like this one, too. Windows uses
>similar method to store other info, such as directory icon. It uses a
>hidden file "desktop.ini" in every folder for that.
>Pros: constant access speed. No db lookup, easy to implement, no other
>dependencies. Portable, easily managed, and can be preserved even when you
>create backup for the folder.
>Cons: When you create a tar file for the folder, it will be included. It's
>hard to delete them all if you want to uninstall pcmanfm. Also, remember to
>add it to .gitignore. This is quite annoying. It's also visible to the user
>if you turn on "show hidden files", which is really bad.

>So, the best way I can figure out:
>1. For local filesystems, check xattr first.

    Well, that still have the same big limitation - when you go into the
folder via ssh or ftp, you get no setup for it.

You can still add that sftp://path/to/your/folder to the cache. So next time it will work. Since you don't change that folder setting everyday, the user only need to do this setting once, which is not perfect, but acceptable.
Besides, you may not want to use the same setting when you access the folder from another computer. For example, you have a very small monitor and you want to use a different view mode, then applying a hidden config file for another machine is not really that suitable in this case.
>2. If xattr is not availble or it's not a local FS, try the key-value
>db-based cache.
>3. remove dead entries from the db periodically.

    It is not possible really - you will remove all remembered data for
remote or removable media not currently connected. And since you have
proposed to use cache exactly for that purpose, that renders value of
that cache close to zero. In short - either not use cache, or accept its
unlimited growth, and other cons that I mentioned above.

It's possible sometimes. For remote filesystems, just let it grows since we don't know wether the server is dead definitely or it's just shutdown for maintaince and will be online again. Same for removable devices.
For "fixed" local filesystems which does not support xattrs, such as ntfs and vfat, detecting dead entries and remove them is possible.
So, let entries for remote filesystems and removable devices grows, and only do cleanup for local filesystems with no xattrs support.
Or, just don't do the clean up at all since normally the folder having customized settings won't be too many and setting custom folder settings is not a frequently done operation. The cache won't be too large anyways.
>4. Add UI options for the user to turn off per-folder config.

    That will be in config in any case, that was never a question.

>The .directory apprach is really bad for maintainance. For example, if the
>user want to turn off "per-folder" setting, it's not possible to search for
>all .desktop files and delete them. The drawbacks make this apprach less

    It still have all that Pros that I mentioned above though. :)

    Well, it seems both .directory and cache approaches have too many
Cons in eyes of you, people, so only acceptable one is to use xattr. It
has own drawbacks too but combine two (or more) approaches is worse as
that will bring problems when detection which approach to use fails by
false positive. So I would avoid double-approach as much as possible.

I really think that the dual-mechanism should be used.
If only xattr is used, then it's only possible to support per-folder config for sub folders under /home in the most cases since we have no write access to others. For removable devices using vfat or ntfs for compatibility reasons, we have no xattrs, too. So sometimes the functionality works, and sometimes it does not. The user will be confused by these inconsistent behavior.
I still believed that a key-value db-based binary cache is the most reliable and managable way.The reason why I propose checking xattr first is simple. We can avoid using db when xattr is available. So that operation can be faster and we also save disk space at the same time.
Crashes are not a real issue. We only need to choose a more reliable and robust db. Samba tdb and sqlite are quite robust ones. Samba tdb is used in samba and thunar. Sqlite is widely used everywhere, even in firefox. It's well-tested and robust enough for this trivial task.
If unfortunately the db is broken, the worst case is you'll loose your folder view preference setting. That's all.
    Thank you very much for all your opinions!