121–130 of 280 posts
As a non-Mac user, I always find it somewhat annoying when I download some .tgz published on Github or something and find .DS_Store littered inside. I guess macos probably just uses GNU tar? It's kind of surprising it wasn't modified or configured by default to ignore .DS_Store.
Earlier quoted context omitted.
Resource fork used to contain all the stuff you could edit with ResEdit (good old times!) right? Icons, various gui resources, could be text and translation assets too. For example Escape Velocity plugins used custom resource types and a ResEdit plugin made them easy to edit there.
A lot of Classic Mac apps just used the resource fork to store all their data. It was basically used as a Berkeley DB, except the keys were limited to a 32-bit OSType plus a 16-bit integer, and performance was horrible. But it got the job done when the files were small, had low on-disk overhead, and was ridiculously easy to deploy. Once you pushed an app beyond the level of usage the developer had performed in their…
Here's some https://arstechnica.com/gadgets/2001/08/metadata/
Earlier quoted context omitted.
I recall seeing CD-ROMs that had both Mac and Windows software on it, and depending on which OS it was mounted on, it would show the Windows EXE or the Mac app... I wonder how that's done. I'm guessing there was a clever trick so files on both filesystems share the same data (e.g. if the program/game had a movie, it would only store the bytes of the movie once but its addressable as a file on each filesystem), but th…
IIRC from that time, those CD-ROMs contained two tracks, one formatted with ISO 9660 and another with HFS+. Windows didn't come with HFS+ drivers so it ignored it, and probably MacOS prioritized mounting the HFS+ track.
Never understood why it had to be in the same folder. Can’t the os have its own little db somewhere that has a reference to each path?
Putting in in the folder is also nice in that it naturally gets deleted when the folder is deleted
Earlier quoted context omitted.
I wholly agree with you on this one. Windows has its fair share of issues, but Windows Explorer feels like peak file browsing to me. For MacOS I can recommend Forklift [0]. I've been using it for years and it is a bit closer to the Windows Explorer way of doing things. Does what it is meant to do. Affordable. No nags. Gets out of the way. Not perfect, but soooo much better than the horrific experience that is Finder.…
How’s Forklift 4? I have a paid Forklift 3, and it’s nagging me to upgrade and pay for next version. I mostly went back to Finder for now, as I remember having some kind of issues with Forklift3 not being performant, though I don’t remember the details.
That said I only work on local files and don't use any of the remote workflows. The most advanced feature I use is synchronising files between local storage and SD card. And that works fine.
One thing that did break in v4 is that search doesn't work anymore when using the text only toolbar. I reported that ~10 months ago but it's still broken. Maybe I'm the only person who was actually using it.
Why doesn't Windows need such a directory to store folder customizations in Explorer?
Never understood why it had to be in the same folder. Can’t the os have its own little db somewhere that has a reference to each path?
The idea was that metadata, for example a file’s label, would travel across to whichever device you use the network drive from.
As a non-Mac user, I always find it somewhat annoying when I download some .tgz published on Github or something and find .DS_Store littered inside. I guess macos probably just uses GNU tar? It's kind of surprising it wasn't modified or configured by default to ignore .DS_Store.
It was, but not by default.
If you export COPYFILE_DISABLE=true then tar will skip .DS_Store files.
Earlier quoted context omitted.
> It’s uncharacteristically un-Apple in terms of UX polish. Apple's polish has always been more about the surface then the internals.
I remember playing around with setting up a Hackintosh, and found all those errors in the system logs --- then realised that an actual working Mac generates much the same (ignorable) errors.
For operating systems it must be straight up impossible.
> Back in 1999 I was the technical lead for the Mac OS X Finder at Apple. At that time the Finder code base was some 8 years old and had reached the end of its useful life. Making any changes to it require huge engineering effort, and any changes usually broke two or three seemingly unrelated features. For Mac OS X we decided to rewrite the Finder from scratch. Not that I don't appreciate your work from back then, bu…
>The Finder has so many bizarre quirks and it's so slow to proliferate updates that it's just embarrassing Say what you will about Windows, but the Explore file manager has always been pretty rock solid.