This guy's ignorance of the OS he's using is pissing me off



  • What's going on here? It turns out that this file has a HFS+ resource fork: a separate store of data, completely distinct from the regular file content. Our font data is stored entirely in the resource fork; the regular part of the file (which HFS+ calls the "data fork") is completely empty. Resource forks can be added to any file.

    Yes...

    Not only can Resource forks be added to any file, the majority of Mac Classic files had no Data fork and only Resource forks. The vast majority.

    Applications — even basic filesystem tools — aren't aware of the additional content. How do you deal with a file with two sets of data?

    Right, because Apple gave up on producing good shit and started using really shitty Linux tools that only work on the lowest common denominator, and turn everything into a morass of useless shit in the name of "compatibility".

    But no, obviously it's the filesystem's fault, not the fact that tools "ported" from *nix don't work worth shit.

    I'm sure there's an Apple-y reason for the existence of this feature, but I can't imagine what it might be.

    Gee, I dunno, it's not like THE FIRST FULLY 20 YEARS OF THE OS'S EXISTENCE WAS DESIGNED AROUND THE CONCEPT OR ANYTHING YOU IGNORANT FUCKER!



  • It would be funny to see him flounder around an ntfs filesystem with alternate data streams.

    Also, he's a fucking idiot.


  • Impossible Mission Players - A

    @tufty said:

    ntfs filesystem with alternate data streams.

    Agreed, but how many files are expectedrequired to be in alternate data streams instead of the primary one.



  • @Tsaukpaetra said:

    Agreed, but how many files are expectedrequired to be in alternate data streams instead of the primary one.

    Practically none. As I recall, the feature was originally added to support Mac files on network servers.



  • Not a Mac user, so please don't hit me, but... How do you move a file like that to a FS which doesn't allow alternate streams? The resource fork data just disappears into the ether?



  • @powerlord said:

    Practically none. As I recall, the feature was originally added to support Mac files on network servers.

    That's not true.

    It was actually part of the arrangement with IBM to make NT compatible with OS/2, believe it or not. I don't know enough about OS/2 to tell you what IBM planned to use it for...

    But it's handy for all kinds of things. And almost every filesystem, even most *nix ones, have some way out storing data relevant to a file outside of the file's data area. It's not like HFS+ is unique in any way here.



  • On OSX, you make it a hidden file called ._{originalfilename}. On Windows, you pop up a "SUCKS TO BE YOU!" dialog. On Linux, you kernel panic because the FS driver which inexplicably isn't in FUSE doesn't understand how to handle interrogations about alternate data streams.



  • @Maciejasjmj said:

    Not a Mac user, so please don't hit me, but... How do you move a file like that to a FS which doesn't allow alternate streams?

    Mac email clients implemented it "transparently", more or less. For things like BBSes, old-school AOL, etc. you generally had to manually BinHex the file before sending it.

    Practically-speaking, Mac files were distributed in the StuffIt compression format, which happened to only use the data fork. So if you wanted to put your file on AOL, you'd compress it with StuffIt and be insulated from the annoyance of BinHex.

    @Maciejasjmj said:

    The resource fork data just disappears into the ether?

    Welcome to shit-ass-town, a.k.a. our awful reality in IT.

    Servers run *nix. *nix doesn't understand fucking ANYTHING made after 1972. All OSes/applications/etc that wants to use the Internet can not implement any features that didn't already exist in 1972.

    What basically happened is that Mac Classic died, and Apple switched everything to be a shitty Unix distro instead, and everybody who loved computers wept.



  • You get a pair of files (or more, HFS[+XJ] can have multiple forks, not just 2), only one of which is normally visible. The majority of OSX's command line tools are, in fact, perfectly aware of extra forks and handle them transparently, although going on and off non-fork-aware filesystems means relying on automated naming conventions.



  • Doesn't alternate streams break a lot of tools in any os? Do zip files support it?

    I would never use such feature, noone expects an alternate stream.


  • Impossible Mission Players - A

    @fbmac said:

    noone expects an alternate streamthe Discourse Inqusition!.

    FTFY <!--Did I meme that right?-->



  • @fbmac said:

    Doesn't alternate streamsthreading break a lot of tools in any os? Do zip files support it?

    I would never use such feature, noone expects an alternate stream thread.

    Yes, people are dumb. That doesn't automatically make a feature stupid.



  • A feature that breaks all existing file manipulating tools for no benefit is pretty dumb IMO



  • Yes, which is why tools should probably handle old features that we've had for a very long time, instead of just acting like they don't exist and suddenly breaking. Your point?



  • Resource forks are from 1984. Perhaps 1982, if the LISA filesystem had them. How old does a feature have to be before it's "worthy"?



  • Age won't make it worthy. If all tools in their system supported it, that would help. Still, very little benefit in that, and a lot of potential for confusion.

    Do you check streams for every file you open on NTFS? Does .NET even support it?



  • @fbmac said:

    Do you check layers for every file you open on NTFS?

    I don't even know what that means. What are "layers"? Are you just pulling new terminology out of your ass?

    @fbmac said:

    Does .NET even support it?

    Probably not, considering it's just a thing some moron on DailyWTF forums invented a couple minutes ago.



  • Are you that pedant IRL? Do you act like this for fun or out of grumpiness?



  • @fbmac said:

    A feature that breaks all existing file manipulating tools for no benefit is pretty dumb IMO

    As has been pointed out, it's an old, although somewhat advanced if you're acclimatised to FAT, feature. And it didn't break "all existing file manipulation tools", Apple moved to a platform where the majority of file manipulation tools didn't support that feature, and have since been retrofitting the feature back (despite largely deprecating non-data-forks for some considerable time).

    @blakeyrat said:

    Perhaps 1982, if the LISA filesystem had them.

    Lisa had file labels, which were not exactly the same thing (closer to creator codes, really). 128 bytes per label, IIRC.



  • It is easy to forget them on NTFS because nothing uses it on windows. Seems like a lot of fun when you run accross one of these. And C fopen doesnt support it, great way to put us in vendor lock-in with a totally useless feature.



  • @fbmac said:

    It is easy to forget them on NTFS because nothing uses it on windows.

    Lies.

    The "downloaded from the Internet" warning is stored there, since XP SP2.



  • I never noticed that. Nothing relevant uses it then.



  • Correct. As lord of logic and sole arbiter of reason, your experiences alone determine the worthiness of all that is.



  • This post is deleted!


  • Other relevant things stored there:

    • The resource fork of classic Mac files.
    • Spotlight data, if your OSX is configured correctly.
    • Shell properties, like Title and Album, when there's no file-format-specific handler.
    • POSIX information when Interix is in use, though they added Extended Atrributes as a replacement that they never used.
    • You, if you throw a colon after the file name in 'CreateFile()'.

  • :belt_onion:

    Thanks for the article! I think he is right HFS+ is crazy.

    According to ls, our 66 KB file actually has a size of zero bytes

    resource fork looks like a :wtf:-hack (any extended attribute is really an ugly hack).

    P.S. I do not care about the CLI tools, the interface is shit.


  • Discourse touched me in a no-no place

    @fbmac said:

    Do you check streams for every file you open on NTFS? Does .NET even support it?

    You don't need to, and the answer is yes.

    Everything supports streams, but normally you only work with one at a time. Fire up a command prompt, type "notepad blargle.txt:blakeyrat", answer "yes" to the messagebox, type in some text, save the file.



  • @fbmac said:

    It is easy to forget them on NTFS because nothing uses it on windows.

    Windows does. You know all that business where you try to run something you downloaded and you get a scary warning that it was downloaded and might therefore do Bad Things? That's IE tagging every downloaded file with an alternate data stream, and Windows Explorer testing for its presence.



  • @dse said:

    any extended attribute is really an ugly hack

    :interrobang:



  • @FrostCat said:

    Fire up a command prompt, type "notepad blargle.txt:blakeyrat"

    Replace that colon with a slash and it works in fat and ext4 too. What benefit did it brings for its incompatibility? ZERO


  • Discourse touched me in a no-no place

    @fbmac said:

    What benefit did it brings for its incompatibility?

    Because it's one file. You can't forget to copy the second stream, for example. I mean, unless you copy to a FAT filesystem or something.



  • @FrostCat said:

    notepad blargle.txt:blakeyrat
    Other than the automatic "downloaded and might therefore do Bad Things" thing, I have no experience with alternate streams. Having done this, how does one access the contents of that stream? Nothing I can find even suggests that such a stream exists; even the file size on disk is 0 bytes.



  • The same way. Any program that goes directly against Windows' CreateFile API can be used to create or edit alternate streams. DIR will also report the existence and extent of them.


  • :belt_onion:

    1. If I have a file.txt what is wrong to have a hidden .file.txt.icon for an icon file? Why does FS need to care about the file explorer application logic? What does file.txt/..icon/rsrc achieve that normal files cannot?
    2. It just hides some critical information about the file, making it more difficult for applications specially across filesystems or internet. You email a file, upload a file, copy to USB (usually some FAT), sometimes even between applications on the same machine :wtf:, and you loose that data. Whereas you can archive .file.txt.icon along with file.txt and treat it like how OSX treats applications bundles. Application bundles is what I prefer.
    3. With xattrs the application-layer logic is leaking into the most critical part of the OS that is supposed to safeguard my files. It requires more diligence for journaling because OS is working hard maintaining some shadow tree. Corrupt filesystem problem with HFS+ is a symptom.
    4. It is a pain

    I am not really against moderate use of xattr, say for ACLs or small attributes that is not really data. I write this in small font so blakey would not read it.



  • @dse said:

    If I have a file.txt what is wrong to have a hidden .file.txt.icon for an icon file? Why does FS need to care about the file explorer application logic? What does file.txt/..icon/rsrc achieve that normal files cannot?

    Resource forks predate hidden files.

    @dse said:

    It just hides some critical information about the file, making it more difficult for applications specially across filesystems or internet. You email a file, upload a file, copy to USB (usually some FAT), sometimes even between applications on the same machine :wtf:, and you loose that data. Whereas you can archive .file.txt.icon along with file.txt and treat it like how OSX treats applications bundles. Application bundles is what I prefer.

    As we've discussed, that's because the Internet was developed by assholes who hate any technology invented after 1972, and thus it can't handle shit.

    That's why we can't have nice things: *nix users.

    @dse said:

    With xattrs the application-layer logic is leaking into the most critical part of the OS that is supposed to safeguard my files. It requires more diligence for journaling because OS is working hard maintaining some shadow tree. Corrupt filesystem problem with HFS+ is a symptom.

    Huh?

    Information that is relevant to the file is attached to the file. There's no leaking here.

    @dse said:

    It is a pain

    Right; because *nix users are assholes. Already stated this several times.



  • @TwelveBaud said:

    The same way. Any program that goes directly against Windows' CreateFile API can be used to create or edit alternate streams. DIR will also report the existence and extent of them.

    Ah, since DIR didn't seem to be doing this for me, I did some (trivial) poking, and discovered the /R switch. So yes, it will, but only if you explicitly tell it to do so, which I wasn't aware of until just now.

    Is there a way to get explorer to show the info? I haven't found that, yet.


  • :belt_onion:

    @blakeyrat said:

    Resource forks predate hidden files.

    CLI applications predate GUI applications. And lets keep Dwarf Fortress in ASCII mode because it is older, no need for graphics.

    @blakeyrat said:

    that's because the Internet was developed by assholes who hate any technology invented after 1972, and thus it can't handle shit.

    That's why we can't have nice things: *nix users.


    You might be right, but again, so what? It does not excuse shitty HFS+ filesystem not being upgraded, and even defended by mac fanboys becoz Steve Jobzzz.

    @blakeyrat said:

    There's no leaking here.

    The leaking is in design of the layers of OS:
    Icons are application layer because Finder/Explorer wants to show them, Music player wants artist name, ...
    FileSystem is lower layer, if it tries to do some of the responsibilities of applications, that is called leaking in the design. What is next? FileSystem trying to send emails?

    @blakeyrat said:

    Right; because *nix users are assholes. Already stated this several times.

    Assholes create the world.



  • @dse said:

    CLI applications predate GUI applications.

    Ok. Relevance?

    I'm just saying, "why didn't they implement that with hidden files?" is kind of like the Raymond Chen example of the guy asking, "why didn't they rescue Apollo 13 with the space shuttle?"

    @dse said:

    You might be right, but again, so what? It does not excuse shitty HFS+ filesystem not being upgraded, and even defended by mac fanboys becoz Steve Jobzzz.

    I didn't say it was. Quote where I did. I dare you.

    @dse said:

    The leaking is in design of the layers of OS:

    Huh?

    @dse said:

    Icons are application layer because Finder/Explorer wants to show them,

    That wasn't true in Mac Classic, so you have at least one fundamental disconnect here.

    @dse said:

    FileSystem is lower layer, if it tries to do some of the responsibilities of applications, that is called leaking in the design.

    What task is the filesystem doing here that is the "responsibility of applications"? All it's doing is storing data relevant to the file in the file. That's exactly what it's supposed to be doing.

    And remember, the OS that kicked this all off, didn't have the problem of the disconnect between what the CLI could support (as far as displaying file size, etc.) versus what the GUI could support, because it had no CLI at all.

    @dse said:

    Assholes create the world.

    I know. That's why it's shit.


  • :belt_onion:

    @blakeyrat said:

    That wasn't true in Mac Classic, so you have at least one fundamental disconnect here.

    It is true in OSX. If it made sense then, it does not make sense now and HFS+ sucks now.

    @blakeyrat said:

    And remember, the OS that kicked this all off, didn't have the problem of the disconnect between what the CLI could support (as far as displaying file size, etc.) versus what the GUI could support, because it had no CLI at all.

    That is why I am not arguing against Mac Classic or its design decisions!
    I doubt that guy runs Mac classic too, it is OSX most likely.

    @blakeyrat said:

    I know. That's why it's shit.

    It is getting better. If we do not nuke each other, it will be great.



  • @dse said:

    It is true in OSX.

    Well it shouldn't be. Fuck OS X.

    @dse said:

    If it made sense then, it does not make sense now and HFS+ sucks now.

    Well since you've bolded random words in your response, I now know how serious you are about it and you've convinced me entirely. Italics.

    @dse said:

    I doubt that guy runs Mac classic too, it is OSX most likely.

    I doubt he's ever even seen Mac Classic, which is why it pisses me off when he comes in with that lecturing attitude, as if he's some expert on it.



  • @dse said:

    What does file.txt/..icon/rsrc achieve that normal files cannot?

    You solution would be fine as long as it's only .file.txt.icon. What happens when you've also got .file.txt.pgp.sig and .file.txt.created-by and .file.txt.open.with and .file.txt.collaborators and …

    Effectively, you're reinventing what additional forks / metadata / extended attributes do, in a totally ad-hoc and unsupported manner. Well done you.

    :doing_it_wrong: Sounds great!

    @dse said:

    It just hides some critical information about the file

    If the information is critical, it should stay with the file. Not be bunged into some hidden file that might or might not stay with it.

    @dse said:

    Corrupt filesystem problem with HFS+ is a symptom.

    Wanna know the last time I had corrupt HFS+ filesystem? Never, that's when. I've had a few drives go west (including one that wasn't backed up, and required hardware fiddlage followed by 2 weeks of ddrescue on the image I managed to pull from it), but never had the filesystem shit itself, even when, in a fit of driver development, I was hard crashing my machine upwards of 50 times a day. I still have files on this machine that came from the HFS drive on my IIfx in 1991 (IIfx -> Powerbook 5300 -> Wallstreet -> move to HFS+ -> Wallstreet -> Move to OSX -> Wallstreet -> Tibook -> drive recovery -> TiBook -> Mini G4 -> iMac -> thinkpad).

    HFS+ doesn't have file checksumming, which means that if your hardware fails then you lose files, but it's hardly alone with that. NTFS is in exactly the same situation. I've never had NTFS corrupt itself, either. Ext2 and Ext3? I've had massive data loss due to filesystem shittage with both of those.

    On the other hand, HFS+ doesn't require defragmentation, it moves hot files and does an awful lot of other things that other file systems don't. It's not perfect, and a lot of its features are bolted on in an unpleasant way, but it's pretty damn good.
    @dse said:

    It is a pain

    Sure, if your tools don't support it, it's a pain. It's bit like compiling C+ in that respect.


  • :belt_onion:

    I guess you also do not like reading tiny texts:
    @dse said:

    I am not really against moderate use of xattr, say for ACLs or small attributes that is not really data.

    xattr for some of the applications you mentioned make sense because they are not really data to miss if lost.

    @tufty said:

    If the information is critical, it should stay with the file.

    QFT. And .file.txt.icon is a file but xattrs are not, they are ad-hoc. But the OP article is about an icon file that has no freaking bitmap data! What is more critical about an icon than bitmap?



  • @dse said:

    I guess you also do not like reading tiny texts:

    If you wanted me to read it, and then made it unreadable, then you're a pretty dumb motherfucker, ain't ya?

    @dse said:

    But the OP article is about an icon file that has no freaking bitmap data! What is more critical about an icon than bitmap?

    It's about a font, you retard.


  • :belt_onion:

    @blakeyrat said:

    If you wanted me to read it, and then made it unreadable, than you're a pretty dumb motherfucker, ain't ya?

    On the contrary:
    @dse said:

    I am not really against moderate use of xattr, say for ACLs or small attributes that is not really data. I write this in small font so blakey would not read it.

    I was not replying to you.

    @blakeyrat said:

    It's about a font, you retard.

    Fonts have bitmap too, you are right



  • @blakeyrat said:

    Right; because *nix users are assholes. Already stated this several times.

    Why the *nix users and not the *nix developers? And why they should add support to a Apple feature? They should write their own tools, or add support to it for the opensource tools they are using.



  • fbmac, between your constant deleting of posts and general being a dumbass, I'm not going to converse with you. Just wanted to say that to save your time in the future. You are quite welcome to get the fuck out of all my threads.



  • I like conversing with you, I'll stay around



  • @fbmac said:

    I like conversing with you, I'll stay around

    :popcorn:


  • Discourse touched me in a no-no place

    @HardwareGeek said:

    Ah, since DIR didn't seem to be doing this for me, I did some (trivial) poking, and discovered the /R switch. So yes, it will, but only if you explicitly tell it to do so, which I wasn't aware of until just now.

    Actually, what Twelvebaud and I were saying is that "dir test.txt:blakeyrat" will show that stream.

    Yes, dir/r is nicer, and I'm glad to learn about that.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    If you wanted me to read it, and then made it unreadable, then you're a pretty dumb motherfucker, ain't ya?

    QFT. All you people writing in multiple-small tags suck.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.