4 ms·

Personally I hate .DS_Store and they must be deleted. BUT on the other hand I am finishing "a proper missing, a dream File Manager" for Mac OS and thinking abou

Personally I hate .DS_Store and they must be deleted. BUT on the other hand I am finishing "a proper missing, a dream File Manager" for Mac OS and thinking about features that would require to store some meta data. Where should I store them? If it's in the folder in form of some ".meta-data" then it would be copied when you copy data and be available there in another machine, or I can create it inside the OS somewhere, but then how to transfer it to usb drive for instance? I do not like idea of data to be polluted with some extra .something, I really hate the idea, but how to deal with it to keep it manageable? I can make some indexes/pre-calculated sizes in the root of the drive, if user chooses to have those, BUT then if we speak about shared network folder, it then may very well appear in some folder after all because it was mounted as a drive, so the only solution would be to put it in ... well the same ".meta-data" just like .DS_Store that I hate. Then only thing to do about it is to give a choice to user when he copy something, to avoid copying those too. Right now I am using constantly "my file manger of a dream" and actually almost forgot about .DS_Store disaster, because honestly I have no need for poor Finder anymore, and thus .DS_Store is not created at all, but should I add something like this for extra features which would -really- require them? What do you think? Putting yourself in the shoes of someone designing File Manger you kind of see where .DS_Store comes from. Still, hate it :) Really thinking what to do for some time now ...

torstenvl 6y ago
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.
- lovelyviking 6y ago
  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.
TheCapeGreek 6y ago
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.
- lovelyviking 6y ago
  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.
ScottFree 6y ago
> I am finishing "a proper missing, a dream File Manager" for Mac OS Can I sign up to be notified when it's released? :)
- lovelyviking 6y ago
  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.
loa_in_ 6y ago
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.
- Someone 6y ago
  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)
  - loa_in_ 6y ago
    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)
    - Someone 6y ago
      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)
      - loa_in_ 6y ago
        You're right. I got a bit ahead of myself it seems.

torstenvl 6y ago

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.

lovelyviking 6y ago
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.

TheCapeGreek 6y ago

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.

lovelyviking 6y ago
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.

ScottFree 6y ago

> I am finishing "a proper missing, a dream File Manager" for Mac OS Can I sign up to be notified when it's released? :)

lovelyviking 6y ago
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.

loa_in_ 6y ago

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.

Someone 6y ago
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)
- loa_in_ 6y ago
  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)
  - Someone 6y ago
    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)
    - loa_in_ 6y ago
      You're right. I got a bit ahead of myself it seems.