• Anonymous Coward (unregistered) in reply to Thomas

    OS X uses colons as path separators.

    That being said, being organized is for people who are too lazy to look for their stuff.

  • HP PhaserJet (unregistered) in reply to AndyC
    AndyC:
    Martin:
    Files should not be scanned. The mime type should be stored along side the filename, but not a part of it. It's an abuse if the file name field to use it to store file types too. A hack which presumably stems from having a fat without a dedicated place for the type

    Of course, if you really believe that a "real" OS wouldn't do something as stupid as storing metadata as part of the filename, then you presumably also think it would be ridiculously stupid to make a file hidden simply on the basis that the filename begins with a "." character. No "real" OS would do that, would it?

    The TRWTF is that nothing is perfect. Why does everything have to have its own unique flaws? Why can't we just have one thing that is perfect?

  • oheso (unregistered) in reply to cellocgw
    cellocgw:
    OTOH, if you've set the Finder not to show extensions, stupid things happen when you try to specify an extension in the Save dialog box. It's almost as Bleeped-up as Windows.

    No, it's more bleeped-up than Windows. Because the default is still not to add file extensions (or to display them). And then not to add them even when I've set the preference to require and to always display.

    TRWTF is any OS that uses file extensions for any reason whatsoever and then doesn't display them.

  • some dude (unregistered) in reply to CDave
    CDave:
    Ralph:
    Jay:
    Ralph:
    TRWTF is file "extensions".

    If you are just another sheep bent on following the herd and never questioning anything, you will not be able to understand why this is true.

    On the other hand if you have the ability to look at systems and see what is wrong with them and how it could be designed better, you already know this.

    So why am I bothering with this post?

    I guess so the few of us can know we aren't alone. Hopelessly overwhelmed by sheep, but not alone.

    So why, exactly, is it better to have the type identification NOT be part of the file name? blah blah blah

    (By the way, how does disagreeing with you make someone a mindless sheep? Have you ever considered the possibility that someone might have carefully considered a question and come to a different conclusion than you did?)

    Thank you for identifying yourself as an idiot, I know to ignore you now.

    Ok I'll bite, how would you redesign the system?

    Are you kidding? Offer a helpful suggestion? All he wants to do it shit on Mac users out of jealousy.

  • (cs) in reply to Rob
    Rob:
    Sadly, OS X has been using file extensions as the default typing method for the last few releases. It sucks balls. Regardless, the correct extension for CSV files is, in fact, .txt.
    Actually, it's not. See Ars Technica for an explanation of the true file typing system: UTIs. What I think happened is the stupid app (an Apple app no less) is trying to use the wrong UTI (couldn't they have a better initialism??) when it should be public.comma-separated-values-text which would be .csv. It seems that Apple recently started enforcing mapping between UTIs and extensions. And as the OS is Object Oriented, the dialogs are partially managed by Frameworks. The Finder (and other apps) allow you to override this by the Get Info window where you can set whatever you want but again, the app should be doing it right in the first place (choosing comma delimited should have changed the extension automatically).
    Anonymous:
    Exactly. The WTF is not there IS such a dialog, but that it LACKS the ability to override. Not providing a "do it anyway" button is fair and square the fault of Apple.
    That used to exist (at least in TextEdit) and has dropped for stronger enforcement. Apps need to catch up.
    Jay:
    So why, exactly, is it better to have the type identification NOT be part of the file name? It seems to me that a pretty obvious advantage of using the extension to identify the file type is that I can look at a file name and immediately know the file type. It is obvious from a directory listing what the types of the files are. If the type is stored separately, then I have to look it up, possibly with a special program. You could, I suppose, always write the name with the type appended in some way, like, "myspreadsheet.txt,csv". But then how is that different in practice from writing "myspreadsheet.csv"?
    Some utility/app/shell/whatever must display the filename and therefore can display the metadata along side it. Explorer in Windows and Finder in Mac OS X do that and do it quite well with human readable text. Extensions are only good for backwards compatibility and cross-platform support.
    Rhywden:
    That's nice. However, when I see a directory listing, I do want to have an inkling of what's contained in it. Last time I checked, even Linux still has stuff like: file.c file.h file.py file.rb file.log file.tar.gz file.conf And so on and so forth. Weird, huh? Obviously, file extensions do make sense.
    And there's no reason why a second column cannot show you the human text of the file type. Additionally, there's nothing keeping you from naming a file with whatever blob of text you want in order to differentiate. It's unfortunate that noobs have to learn all this alphabet soup (log, tar.gz) when Log File and Compressed Archive (Gzip & tar) would be more readable. (What is an .rb file anyway?) This isn't the 80s, people!
    AndyCanfield:
    I once taught two students how to code HTML. One used Windows, the other a Mac. We had so much trouble trying to get the Mac to save an HTML file as something.html that we finally gave up and he switched to Windows.
    Sounds like teacher failure to me.
    Coyne:
    then the resulting psuedo-CSV file is broken.

    Maybe the Mac knows his file is broken and that's why he can't save it as .csv?

    I can guarantee that's not the case. It's a file typing error and the app is at fault.

    AndyC:
    And how, pray tell, do you send said metadata when transferring files betweens systems? Because there are a whole raft of communication methods that predate the invention of mime types, so you can't use that. Indeed the only thing you can rely on being able to use is a filename.

    There's a reason that the Mac changed from the old Creator/Type info into using file type extensions. And it wasn't that Apple thought they'd make it a bit more Windows like.

    Bingo. I'm sure an RFC could be agreed upon to go forward with some sort of packaging of the metadata but the old stuff like SFTP et. al. won't be updated so don't hold your breath. Extensions are with us for the foreseeable future.

    Zemm:
    SeySayux:
    BTW, HFS+ allows any character (including '/' and NUL) in a filename,

    TRWTF. Mac people at work often create filenames with "/" or "*" or other characters that are illegal in Windows. Those files actually do work over SMB (Windows users sees garbage filenames) but if you try and copy them onto a USB stick they just fail without any error message or anything.

    TR,RWTF is that Windows does not change the filenames as it receives the files, show an error on a filename it cannot copy to flash stick(really!?!?!), or reject the uploading file out of desperation. I don't want your archaic namespace imposed on my Macs especially as the OS does not have exclusive domain over those characters. It's unfortunate that : is still the primary Mac directory separator when a unicode one exists.
    bertram:
    Lockwood:
    TRWTF is Macs.

    I disagree: the real WTF is Mac users.

    Your bridge needs your attention.

  • (cs) in reply to SeySayux
    SeySayux:
    On the topic of the Mac screenshot:
    1. Applications can set constraints on the allowed extensions for files when saving. This is useful, e.g. so you don't accidentially erase the extension while saving.
    2. This particular application forgot to allow "CSV" as an extension, so it's the app's fault, not Mac's fault.
    3. As you can see, the dialog clearly offers the option to override this descision, it's even selected as default. I can't remember when Windows allowed me to override a descision.
    4. Mac still uses metadata for determining file type association. In case no metadata is found (for example, if you download something from the internet with a program that does not set mime type), the extension is used.

    Next time you bash Mac OS X, please use it first. Thanks.

    BTW, HFS+ allows any character (including '/' and NUL) in a filename, and can be either case sensitive or not.

    1. Standard practice is to add the default extension if no extension is specified
    2. Normally, applications are meant to defer to the user's better judgment. Apparently, in this case, the developer knows best.
    3. The dialog clearly shows that you have three options: Append the only allowed file extension, replace the chosen file extension with the only allowed file extension, or cancel saving.
    4. Support for metadata should eliminate the need to force the extension.
  • (cs) in reply to Rob

    Actually both .csv and .txt have always been considered to be valid extensions for CSV files for as long as I can remember. They may be a plain-text/human-readable format, but I definitely recall .csv as being the canonical extension for CSV, just as .sql is used for SQL files and not .txt, even though they too are plain-text.

  • (cs) in reply to Anonymous Coward
    Anonymous Coward:
    OS X uses colons as path separators.

    That being said, being organized is for people who are too lazy to look for their stuff.

    Actually, being based upon BSD UNIX, the real directory separater is /, as can be seen via the Terminal application. The GUI side might be converting normally illegal chars to Unicode analogs.

  • Lennart Goosens (unregistered)

    The "File > Quit > Yes, Quit" routine is, in fact, by far the best quit confirmation "dialog" I've ever seen. In fact, it isn't a dialog at all, which is the whole point.

    Presenting a user with a dialog to confirm quitting the application can be a real drag, not only because we don't expect it, but especially since the user has to move the mouse pointer a whole mile to click on the Yes button. Incorporating the "Yes, Quit" button in a small sub menu:

    • makes accidental clicks very unlikely
    • makes confirmation a breeze

    This may be out of the ordinary, but I'd really like to see this become standard, instead of the instant-but-accidental-quit or the dreaded are-you-sure-you-want-to-quit.

    Another option would be to have a Quit/Cancel button dialog appear in the menu, as soon as someone clicks Quit.

  • Lennart Goosens (unregistered) in reply to hoodaticus
    hoodaticus:
    Rank Amateur:
    Anonymous:
    That method for quitting a program actually looks kind of compelling.

    I agree. I bet it's faster and easier for the user than a Yes/No message box, but still protects the user from accidentally quitting due to a slip of the mouse.... assuming that such protection is needed (e.g., the program has a lengthy startup process).

    Label works for me. What would be better? I don't need "No, Don't Quit."

    You people have it all wrong. There should never be a "Are you sure you want to quit?" feature. I don't care if it's a fuel pump controller for the boosters on the space shuttle - users should rightly be punished for clicking things they shouldn't.

    Then again, that's another way of thinking. :P

    I really don't agree though. I do, however, firmly believe that developers should be punished for coding things they should not have, especially web developers. So to hell with browser support for <marquee> and malformed XHTML!

    But I guess that's a bit off-topic. It might be important to recognise the fact that not every program actually needs a confirmation dialog for quitting (picture a simple calculator asking whether or not you're REALLY, REALLY sure you wanted to quit - horrifying).

    However, incorporating such a "feature" could, sometimes, actually mean a huge reduction in support calls of dumb - er... uneducated - people wanting to recover their lost data.

Leave a comment on “Redefining Near”

Log In or post as a guest

Replying to comment #:

« Return to Article