Hacker News Reader

Store your app's configuration, including per-folder view options, in a centralized store -- either ~/.dreamfm/ or ~/Library/Application Support/ Dream File Manager/

In the same view options configuration window, have a checkbox option to make the configuration portable along with the files, in which case write it out to .DS_Store or a similar file, to be used as a local override à la .htaccess

Explaining this option succinctly may be a challenge but not impossible. Maybe "Save view options with folder" with a hover tooltip explaining that this would enable the view options to remain the same across user accounts and computers.

Thank your for your thoughts. This is more or less how I see it too in general.

> Maybe "Save view options with folder"

I like it, it's not only 'view options' though, as you understand. Many '.DS_Store' files are already there for many folders and I have to deal with them while compare sizes etc. Right now they are copied because I do not think FM should be invasive in your data as a general principle. But some option along the lines of "Copy meta data too" I think is reasonable way to deal with them.

If I'm moving files to a USB, it may also be to move things not just to a different machine, but a different OS. Perhaps even a different file manager, so your file would be the same pollutant. So overall anything like .DS_Store is unwanted.

As mentioned by other comments, store it in a centralised cache/config/whatever for your application.

I agree, I do not like pollution traveling around data. On the other hand I think FM shouldn't be invasive if this pollution is already there. Option can be added to deal with them, but only if you choose to, because not always you wish to. Many times you just wish to copy it 'the way it is' without a headache and even this simple basic task is not always possible to achieve with Finder.

Compute a simple checksum over first megabyte or so of the image file (for O(1) complexity) and store it per known file in memory. Store thumbnails using that checksum as key in global cache. Don't purge because methods discussed in this thread don't.

So, to show thumbnails for a directory with 100 photos, you’re going to open and close 100 files, and read 100 1MB chunks of data?

That probably is doable on modern local hardware, but on network disks, it might still be slow.

Make that an IMHO not unreasonably large 500 photos and your local disk might be slow, too.

Add a virus scanner, and 100 photos might already be annoyingly slow.

⇒ I would try to find a way to store away the checksum somewhere in the file (say in an extended attribute, as a (modification timestamp, checksum) pair)

Normally to show thumbnails you need to parse the whole image anyway. Unless that is the format doesn't have downscaled data already (progressive jpeg/PNG)

If you don’t cache thumbnails, that’s true, but that’s too slow, so you cache thumbnails.

If you do that, you only have to read the whole image the first time. Once you created the thumbnails, you only need to read them, and they’re a lot smaller, and can be put in a single file.

The proposed approach reads a significant part of each file to determine whether the cached thumbnail is still current. That doesn’t give a huge improvement over not caching thumbnails at all (factor of 5 in bytes read/network traffic, as a rough guess, likely less in disk seeks)

You're right. I got a bit ahead of myself it seems.

Thank you for thoughts though. Was interesting to read both of you.

It's a dilemma of memory vs computation. It depends on what we expect/prefer:

FM that takes a lot of memory or FM that use computation resources when required only. I tend to think that in general expectation from FM is to be very small in memory demands and take valuable computational resources only if it is absolutely necessary.

My approach would work amazingly in ipfs where hash of contents is an intrinsic property of the file system

> I am finishing "a proper missing, a dream File Manager" for Mac OS

Can I sign up to be notified when it's released? :)

Sure :) I understand you . For me Mac became unusable on a new setup until I install my FM. I wrote it for myself in the first place and I am using it heavily daily. Working on it for quite some time now. I do not plan it 'small' as another BS app over there. This one should really 'just work' in the best mac traditions of SJ we know: elegant for beginner and powerful for advanced in the same time, with high quality standard in mind as the first priority. So consider yourself being signed up for the first notifications, you won't miss the 'revolution' ;) Hacker News were very helpful and supportive resource for me and I think the first public announcements are deserve to be here.