Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
And no, not for porn (though it would be useful there, as well).
I'm also glad OSX looks at the extension first, for the reasons mentioned in the post above. Allow me to rephrase, since you missed it the first time:
I use the file extension to easily tell the OS which application to use when opening certain files of the same type. For example,
It's a simple way to not only identify which images I have and have not yet edited, but to also not need to put any thought into remembering to right click and "Open With" when I need to edit an image from my archives.
I do agree that OSes need to utilize better methods for helping users identify files. I've posted my ideas for that several times in this discussion already, so I won't repeat them here. What I'm proposing is keeping file extensions as a way for users to easily tell their OS which program, of several they may have available to handle a certain type of file, should be used for a given file.
I really hate typing novel-length posts (like this one) to express simple concepts, so please excuse me for relying on the ability of my peers to comprehend concisely-written text.
Cmd-Delete deletes the file
That's what confused me, because I thought when you said "deletes the file" you meant, well... deletes... the file. CMD-Delete moving to trash, also one of the first things I learned in OSX, is the behavior I was already familiar with.
Adobe Acrobat icon = PDF, or malware executable masquerading as a PDF by co-opting the Acrobat icon.
Fixed that for you.
But the defaults are mutable, and not to be trusted to stay consistent.
Your point? The defaults would still be mutable even if we used magic numbers, or some other system, instead of extensions.
There is nothing that prevents an application from changing the default for
You have a point. However, there is nothing that prevents an executable from using an icon that looks like an image thumbnail (after all, that's all an icon really is). Trusting that an icon properly identifies a file is folly.
Unix(-like) systems have this pretty well handled on the command line, since you can see right there, in the directory listing, whether the executable bit is set. If a GUI is more your speed, what is actually needed is for the GUI to apply some type of overlay to the icon displayed for each file, to indicate what it will attempt to do when that file is opened. That only works if you're displaying icons and, then, if the icons are big enough to be useful (in list views, they usually aren't), though, so some color-coding of file names should be done, as well.
Or, common sense, look at the file header before opening it if you don't trust the source; and you should *never* trust the source.
As will OSX. In fact, on both platforms it is possible to exploit that behavior to your own benefit as a user. Try configuring your OS to open
Only possible when the OS makes intelligent use of file extensions; the people we're arguing with don't seem to comprehend the usefulness of this, though.
Thanks for prompting this bit of testing.
Surprisingly, Finder did better on the slower disk.
The 4-levels-nested test results were:
Another interesting result, the slower SATA-based SSD was actually faster than the PCIe-based SSD, in both tests. It's also possible that Apple optimized the algorithm Finder uses to build its file list in Yosemite; I'm pretty sure the last time I tried to delete a large batch of files via Finder was under Mavericks, possibly Mountain Lion.
Now, here's the kicker: I didn't actually run this test on the old MBP. The SSD that used to be in that system is currently connected to this system via USB3. That makes these results even more interesting, wouldn't you say?
Methinks disk cache has something to do with that, so I'm going to do one more set of tests, ejecting and remounting the disk in between the writes and the deletes, to ensure that the none of the deletes are acting against writes that haven't yet been committed to disk.