Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

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).

×

Comment: Re:Good operating systems Dont. (Score 1) 555

by BronsCon (#49183671) Attached to: Why We Should Stop Hiding File-Name Extensions
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).

Comment: Re:Good operating systems Dont. (Score 1) 555

by BronsCon (#49183597) Attached to: Why We Should Stop Hiding File-Name Extensions
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.

Comment: Re:Better idea (Score 1) 555

by BronsCon (#49178385) Attached to: Why We Should Stop Hiding File-Name Extensions
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.

Comment: Re:Good operating systems Dont. (Score 1) 555

by BronsCon (#49175623) Attached to: Why We Should Stop Hiding File-Name Extensions
Already knew about those and can't stand mission control. Among the first things I figured out in OSX, actually. :)

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.

Comment: Re:Better idea (Score 1) 555

by BronsCon (#49175329) Attached to: Why We Should Stop Hiding File-Name Extensions
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).

Comment: Re:Missing the point (Score 1) 555

by BronsCon (#49174993) Attached to: Why We Should Stop Hiding File-Name Extensions

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 .gif from opening in [gif viewer of choice] to executing them. If someone then sends you an executable with a .gif extension, and you double-click it, it will execute the executable.

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.

Comment: Re:Missing the problem by a mile (Score 1) 555

by BronsCon (#49174879) Attached to: Why We Should Stop Hiding File-Name Extensions

That .jpg might not actually be an image, but Windows will try to load it like one.

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.

Comment: Re:Good operating systems Dont. (Score 1) 555

by BronsCon (#49174705) Attached to: Why We Should Stop Hiding File-Name Extensions
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.

Comment: Re:Good operating systems Dont. (Score 1) 555

by BronsCon (#49174563) Attached to: Why We Should Stop Hiding File-Name Extensions
On the SATA SSD, the results for the flat 100k files were:
CLI: 3.038s
Finder: 4.82s

Surprisingly, Finder did better on the slower disk.

The 4-levels-nested test results were:
CLI: 2.904s
Finder: 4.83s

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.

What this country needs is a dime that will buy a good five-cent bagel.

Working...