And even if they did, it the SWAT team wouldn't respond, it would be a wellfare check, 2 street cops knocking on the door. That's all. And they'd have a good chuckle.

Source: Best friend's stepfather, a retired cop.

Yup, taking a shift right now. Wait, do I have those two backwards? Well, shift!

To clarify, the tools are somewhat of an image forensics suite, useful for organizing images of varied types, from varied sources, with varied levels and types of metadata and varied naming schemes, some of which may have incorrect extensions, additional embedded or appended data (e.g. zip files), and even stegonographically hidden data.

And no, not for porn (though it would be useful there, as well).

Yes, I was an IrfanView user in my Windows days, even had it running in Wine on OSX for some time. I've since written my own tools for managing large multi-faceted image libraries. I may, someday, share those tools with the world, but they're a bit quirky (built around how I needed to manage a specific set of images when I wrote them) and need some refinement before I do so.

Oh, I get the argument, you missed the point by about a mile. I was throwing out an argument in support for, at the very least, keeping file extensions in addition to other methods. If I remove the extension from a JPEG altogether, OSX will still manage to open it in an image viewer; clearly, OSX uses other methods to identify the file type. That's all fine and dandy, and I'm glad it works.

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, .sjpg and .spng open in a photo editor, while .jpg and .png open in an image viewer. The same files, all that's changing is the extension. When I import images from my camera, or add stock photos (which will need to be edited later) to my collection, I run a script that renames them accordingly, so all of my archive images open in an editor. Then, once edited, I save the result with the "proper" extension and the image will, from then, open in my image viewer.

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.

Already knew about those and can't stand mission control. Among the first things I figured out in OSX, actually. :)

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.

Fixed that for you.

Derp. Yeah, I tried it with an empty trash. CMD-Delete still sends files to trash, though; doesn't direct-delete as you said. That has to be a 3rd-party utility on your systems.

That's all good and well, if you also couple it with color-coding of filenames, for cases where the icon is not displayed, or is too small to be useful (think list views), and you leave my file extensions the hell alone, because I use them to tell my OS to open some JPEGs in my editor by default and other in me viewer (I name stock photos .sjpg and leave everything else as .jpg, then have .sjpg always open in my editor, so I don't even have to think about it, just open the file, edit, and it's ready for the project I need it for).

That almost works. Now, set Explorer to list view. Icon still big enough for that to be useful? Nope, need color-coding of the file name, as well. You're on the right path, though.

File extensions are useful for automation, of sorts. For example, I keep stock photos with .sjpg and .spng extensions, set to open in my image editor, while .jpg and .png open in my image viewer. They're JPEG and PNG images in either case; it's the extension that makes that automation possible.

Your point? The defaults would still be mutable even if we used magic numbers, or some other system, instead of extensions.

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 .jpg in a viewer and .jpeg in an editor. Now, name all of your working copies .jpeg and all of your finals .jpg and enjoy having all of your working copies automatically open in your editor, while all of your completed work defaults to the viewer.

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.

Huh, they run just fine on mine. Must be all the Wine.

Well, that was uneventful. The results are so close to the other test there's no point posting them. I'm also too damn lazy to install Mavericks or Mountain Lion on a spare SSD to test there, but I know for certain that the issue I mentioned previously did actually occur the last time I tried it (which was *not* on my current platform, Yosemite). Either way, looks like Apple has fixed that performance killer now, so it's a moot point.

Thanks for prompting this bit of testing.