Hello! PCMan has written on Thursday, 7 November, at 19:34: >On Thu, Nov 7, 2013 at 7:02 PM, Andrej N. Gritsenko <and...@rep.kiev.ua>wrote: >> PCMan has written on Thursday, 7 November, at 11:22:
>> >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. No, you don't get the point. I work on machine A and I have some folder which I strongly want to see in Detailed mode with column MP3tag included, and few other settings. I've done set it working on machine A. When I come to machine B, I go to that folder which is either mounted or accessed via sftp:// and I find it very inconvenient that I have to do that full setup again and again. Imagine if administrator wants to setup convenient environment for the office - he/she have to make setup for each user then on some shared folder, that is a huge inconvenience. >> >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. Well, another example. You have some remote filesystem automounted locally on-demand. Your cache cleaner worked when it's not mounted and found it was gone, removing all metadata. Then you come into that folder (which automounts as you go into it) and (isn't that cool?) you see your setup was magically vanished. And that may be everyday setup of course! >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 It's what I said initially. :) >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. May be you're right. > 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. Well, dual-mechanism may be incostistent too, in case if local FS is mounted R/O, then R/W. That sometimes happens. That is very rare case though, I'm agree. Still xattr might be available to read but user may not have access to change it, and even worse - it might be changed on the next mount yet giving another unpredictable result. >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. It is not always true. Keyfile has only keys and values. Database has single list of keys, yes, but it has indexing and other internal data too so therefore often is much bigger. Especially if DB is crash-proof, that always has the price. >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. You may lose all the settings in any case - is that DB or is that a keyfile. That is always possible when you keep all the settings in one file. Unlike the caches, you cannot regenerate it as it is the only copy of the settings. Cheers! Andriy. ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Lxde-list mailing list Lxde-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxde-list
