What is __MACOSX folder?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
What are these __MACOSX folders I keep seeing in zip files made by people on OSX? Some take as much as 30% of the file.
What program are producing these __MACOSX folder and how can mac users avoid this mistake?
macos zip
asked Feb 3 '10 at 22:37
YadaYada
8813710
migrated from stackoverflow.com Feb 4 '10 at 1:58
This question came from our site for professional and enthusiast programmers.
|
show 1 more comment
What are these __MACOSX folders I keep seeing in zip files made by people on OSX? Some take as much as 30% of the file.
What program are producing these __MACOSX folder and how can mac users avoid this mistake?
macos zip
asked Feb 3 '10 at 22:37
YadaYada
8813710
migrated from stackoverflow.com Feb 4 '10 at 1:58
This question came from our site for professional and enthusiast programmers.
8
They are super-irritating, yes, and usually pointless as the resource forks are so often empty. But at least they're harmless, unlike the non-standard approach Apple have taken to >4GB archive sizes with the built-in OS X stuff, which will confuse any other tool and break again for sufficiently large files. And hey, it could be worse, it could be storing two copies of each file with the same name, one for the data and one for the resource fork, often making it impossible to access either, like pre-OSX Mac used to. Oh Apple, why do you hate standard file formats?
– bobince
Feb 3 '10 at 23:01
3
@bobince: actually, resource forks were a very good idea ... at the time. These days, the same effect is achieved by storing resources as individual files, most of which look pretty much like standard file formats.
– Duncan
Feb 3 '10 at 23:20
16
Nothing wrong with metadata as such, it's just that Apple have such a knack of making up their own formats and messing up existing formats with gratuitously incompatible extensions! Having the content-type data as metadata is in itself a great thing and it saddens me that OS X is moving towards the Windows hack of file extensions as an alternative. Although this isn't as bad as on Linux, where the filesystem supports storing Content-Type metadata, but no desktops use it, preferring a thoroughly broken mixture of file-extension/name-patterns and content-sniffing (urgh!). Sigh, OSes eh?
– bobince
Feb 3 '10 at 23:33
@bobince: But yes, at least the format they made up for this does not do any real harm, other than slightly cluttering directory listings and wasting essentially 1 inode and 1 block per empty resource fork extracted, unless you use something like NTFS (which will store the file contents in the MFT for such small files), in which case it just wastes the "inode" (MFT entry).
– SamB
Feb 15 '11 at 20:52
9
Can be fixed after the fact byzip -d filename.zip __MACOSX/*
– Chris Johnson
Dec 2 '12 at 1:31
|
show 1 more comment
What are these __MACOSX folders I keep seeing in zip files made by people on OSX? Some take as much as 30% of the file.
What program are producing these __MACOSX folder and how can mac users avoid this mistake?
macos zip
asked Feb 3 '10 at 22:37
YadaYada
8813710
What are these __MACOSX folders I keep seeing in zip files made by people on OSX? Some take as much as 30% of the file.
What program are producing these __MACOSX folder and how can mac users avoid this mistake?
macos zip
macos zip
asked Feb 3 '10 at 22:37
YadaYada
8813710
asked Feb 3 '10 at 22:37
YadaYada
8813710
asked Feb 3 '10 at 22:37
YadaYada
8813710
asked Feb 3 '10 at 22:37
YadaYada
8813710
asked Feb 3 '10 at 22:37
YadaYada
8813710
8813710
migrated from stackoverflow.com Feb 4 '10 at 1:58
This question came from our site for professional and enthusiast programmers.
migrated from stackoverflow.com Feb 4 '10 at 1:58
This question came from our site for professional and enthusiast programmers.
8
They are super-irritating, yes, and usually pointless as the resource forks are so often empty. But at least they're harmless, unlike the non-standard approach Apple have taken to >4GB archive sizes with the built-in OS X stuff, which will confuse any other tool and break again for sufficiently large files. And hey, it could be worse, it could be storing two copies of each file with the same name, one for the data and one for the resource fork, often making it impossible to access either, like pre-OSX Mac used to. Oh Apple, why do you hate standard file formats?
– bobince
Feb 3 '10 at 23:01
3
@bobince: actually, resource forks were a very good idea ... at the time. These days, the same effect is achieved by storing resources as individual files, most of which look pretty much like standard file formats.
– Duncan
Feb 3 '10 at 23:20
16
Nothing wrong with metadata as such, it's just that Apple have such a knack of making up their own formats and messing up existing formats with gratuitously incompatible extensions! Having the content-type data as metadata is in itself a great thing and it saddens me that OS X is moving towards the Windows hack of file extensions as an alternative. Although this isn't as bad as on Linux, where the filesystem supports storing Content-Type metadata, but no desktops use it, preferring a thoroughly broken mixture of file-extension/name-patterns and content-sniffing (urgh!). Sigh, OSes eh?
– bobince
Feb 3 '10 at 23:33
@bobince: But yes, at least the format they made up for this does not do any real harm, other than slightly cluttering directory listings and wasting essentially 1 inode and 1 block per empty resource fork extracted, unless you use something like NTFS (which will store the file contents in the MFT for such small files), in which case it just wastes the "inode" (MFT entry).
– SamB
Feb 15 '11 at 20:52
9
Can be fixed after the fact byzip -d filename.zip __MACOSX/*
– Chris Johnson
Dec 2 '12 at 1:31
|
show 1 more comment
8
They are super-irritating, yes, and usually pointless as the resource forks are so often empty. But at least they're harmless, unlike the non-standard approach Apple have taken to >4GB archive sizes with the built-in OS X stuff, which will confuse any other tool and break again for sufficiently large files. And hey, it could be worse, it could be storing two copies of each file with the same name, one for the data and one for the resource fork, often making it impossible to access either, like pre-OSX Mac used to. Oh Apple, why do you hate standard file formats?
– bobince
Feb 3 '10 at 23:01
3
@bobince: actually, resource forks were a very good idea ... at the time. These days, the same effect is achieved by storing resources as individual files, most of which look pretty much like standard file formats.
– Duncan
Feb 3 '10 at 23:20
16
Nothing wrong with metadata as such, it's just that Apple have such a knack of making up their own formats and messing up existing formats with gratuitously incompatible extensions! Having the content-type data as metadata is in itself a great thing and it saddens me that OS X is moving towards the Windows hack of file extensions as an alternative. Although this isn't as bad as on Linux, where the filesystem supports storing Content-Type metadata, but no desktops use it, preferring a thoroughly broken mixture of file-extension/name-patterns and content-sniffing (urgh!). Sigh, OSes eh?
– bobince
Feb 3 '10 at 23:33
@bobince: But yes, at least the format they made up for this does not do any real harm, other than slightly cluttering directory listings and wasting essentially 1 inode and 1 block per empty resource fork extracted, unless you use something like NTFS (which will store the file contents in the MFT for such small files), in which case it just wastes the "inode" (MFT entry).
– SamB
Feb 15 '11 at 20:52
9
Can be fixed after the fact byzip -d filename.zip __MACOSX/*
– Chris Johnson
Dec 2 '12 at 1:31
8
8
They are super-irritating, yes, and usually pointless as the resource forks are so often empty. But at least they're harmless, unlike the non-standard approach Apple have taken to >4GB archive sizes with the built-in OS X stuff, which will confuse any other tool and break again for sufficiently large files. And hey, it could be worse, it could be storing two copies of each file with the same name, one for the data and one for the resource fork, often making it impossible to access either, like pre-OSX Mac used to. Oh Apple, why do you hate standard file formats?
– bobince
Feb 3 '10 at 23:01
They are super-irritating, yes, and usually pointless as the resource forks are so often empty. But at least they're harmless, unlike the non-standard approach Apple have taken to >4GB archive sizes with the built-in OS X stuff, which will confuse any other tool and break again for sufficiently large files. And hey, it could be worse, it could be storing two copies of each file with the same name, one for the data and one for the resource fork, often making it impossible to access either, like pre-OSX Mac used to. Oh Apple, why do you hate standard file formats?
– bobince
Feb 3 '10 at 23:01
3
3
@bobince: actually, resource forks were a very good idea ... at the time. These days, the same effect is achieved by storing resources as individual files, most of which look pretty much like standard file formats.
– Duncan
Feb 3 '10 at 23:20
@bobince: actually, resource forks were a very good idea ... at the time. These days, the same effect is achieved by storing resources as individual files, most of which look pretty much like standard file formats.
– Duncan
Feb 3 '10 at 23:20
16
16
Nothing wrong with metadata as such, it's just that Apple have such a knack of making up their own formats and messing up existing formats with gratuitously incompatible extensions! Having the content-type data as metadata is in itself a great thing and it saddens me that OS X is moving towards the Windows hack of file extensions as an alternative. Although this isn't as bad as on Linux, where the filesystem supports storing Content-Type metadata, but no desktops use it, preferring a thoroughly broken mixture of file-extension/name-patterns and content-sniffing (urgh!). Sigh, OSes eh?
– bobince
Feb 3 '10 at 23:33
Nothing wrong with metadata as such, it's just that Apple have such a knack of making up their own formats and messing up existing formats with gratuitously incompatible extensions! Having the content-type data as metadata is in itself a great thing and it saddens me that OS X is moving towards the Windows hack of file extensions as an alternative. Although this isn't as bad as on Linux, where the filesystem supports storing Content-Type metadata, but no desktops use it, preferring a thoroughly broken mixture of file-extension/name-patterns and content-sniffing (urgh!). Sigh, OSes eh?
– bobince
Feb 3 '10 at 23:33
@bobince: But yes, at least the format they made up for this does not do any real harm, other than slightly cluttering directory listings and wasting essentially 1 inode and 1 block per empty resource fork extracted, unless you use something like NTFS (which will store the file contents in the MFT for such small files), in which case it just wastes the "inode" (MFT entry).
– SamB
Feb 15 '11 at 20:52
@bobince: But yes, at least the format they made up for this does not do any real harm, other than slightly cluttering directory listings and wasting essentially 1 inode and 1 block per empty resource fork extracted, unless you use something like NTFS (which will store the file contents in the MFT for such small files), in which case it just wastes the "inode" (MFT entry).
– SamB
Feb 15 '11 at 20:52
9
9
Can be fixed after the fact by
zip -d filename.zip __MACOSX/*– Chris Johnson
Dec 2 '12 at 1:31
Can be fixed after the fact by
zip -d filename.zip __MACOSX/*– Chris Johnson
Dec 2 '12 at 1:31
|
show 1 more comment
3 Answers
3
active
oldest
votes
http://www.realsoftware.com/listarchives/gettingstarted/2005-09/msg00328.html
Apple provides built-in capability to ZIP files in OS X 10.3 and higher, and these files are the result of Apple storing Resource Forks safe manner. You would never see these files running OS X 10.3 or higher, but since Windows and other operating systems do not understand this special form of Resource Forks they will appear as you see them.
answered Feb 3 '10 at 22:39
nickfnickf
1,60042128
4
It's not just resource forks, anything beyond basic file contents gets put in the AppleDouble file. Apple's moving away from resource forks, but toward things like extended attributes that'll also get stored in the AppleDouble container.
– Gordon Davisson
Feb 5 '10 at 2:02
14
You make it sound like a feature. .zip files are intentionally lacking in the metadata department. If you want metadata, use a different format, not a Mac. Example of proper zip + metadata implementation: .jar
– Zenexer
Aug 22 '13 at 4:11
16
dead link, please fix.
– think123
Feb 2 '14 at 3:24
69
"since Windows and other operating systems do not understand"--Ugh. I just hate this kind of terminology
– Joe Plante
Apr 23 '14 at 2:38
5
Just discovered: if you're on a Mac, using the command line,unzip filename.zipwill unpack the __MACOSX/ directory, which you don't want, butopen filename.zipwill do the right thing.
– Edward Falk
Jun 22 '16 at 18:40
|
show 2 more comments
Here's a link that explains it pretty well. I suppose it is a bit late to help Yada, but for posterity.
Explanation of resource fork at Wikipedia
The rest is my opinion:
@nickf: Never seeing these files is not a FEATURE of those OS X versions it is a FLAW.
People produce data, wrap it up, store it on different mediums and so on. They need to know what is needed or what is not needed.
Hiding it keeps them in the dark.
The age old bad idea of hiding things from users:
A programmer, concerned with expediency of accomplishing his own work,
abuses something in the domain of the end user, to make it easy for himself.
In this case he stored meta data in the user's data space, he then hid it from the user.
He missed the big picture: The user won't become aware of the hidden details.
When he packages his data and ships it somewhere unanticipated by the programmer,
missing parts won't get shipped or unknown parts will arrive which neither
the user nor the recipient can explain.
Hiding things from the user is bad.
It assumes the user is stupid, when more accurately it is the programmer being stupid,
or lazy.
To be clear, this bad habit is not confined to MAC. It is everywhere.
It's a consequence of programmers falling in love with their own schemes and vendors prioritizing their own goals ahead of the needs of the end user.
In brief.
__MACOSX:
weird smelling programmer droppings emerging from under the rug where they were swept.
Programmers and vendors: Please keep things in the open.
When you hide them, you make yourself stupid and the user uninformed.
edited Oct 10 '17 at 11:45
Cœur
26529
answered Dec 3 '11 at 1:31
pbernatchezpbernatchez
1,400196
10
This answer would be better if it was just an answer. The extended ranting about stupid programmers and lazy users detracts from it.
– Kristopher Johnson
Jun 19 '15 at 13:15
1
@pbernatchez Actually, if you stopped to learn about how things looked like and how they evolved, probably you wouldn't leave here your own ranty, arrogant "droppings". Resource forks were a (really nice!) implementation detail pre-Mac OS X and users only found them when interfacing with other systems; since the 90s, Apple has increasingly moved to a world without resource forks, but still bending backwards to keep compatibility. "Store metadata in the user's data space"? WTF? How twistedly do you have to define "metadata" and "user's data space" to say that? You must hate filesystems!
– hmijail
Jan 20 '17 at 12:28
3
"Hiding things from the user is bad". Man, you must also hate all kind of user interfaces, and libraries, and abstraction, and... well, any kind of programming and computers more advanced than an abacus.
– hmijail
Jan 20 '17 at 12:39
3
This does not answer the question. After reading this answer I still have no idea what metadata is contained in the _MACOSX folder, or what resource forks are. I guess people are upvoting this just because they agree with the rant?
– Atte Juvonen
Feb 15 '17 at 13:25
1
While I agree that the emotionally-charged tone is not helpful, I also absolutely agree that creating hidden things that are occasionally needed is a really bad idea, precisely as stated in this answer: users will either (a) not ship hidden files that are needed, or (b) ship hidden files that the recipient can see and neither understand. These files should either be visible, or the data should be embedded in the files in some manner that is flagged as "skippable" by other OS's. Hidden files and directories should be used primarily to protect users, not keep them in the dark.
– Mike Williamson
Oct 25 '18 at 1:47
|
show 2 more comments
To answer your final question:
how can mac users avoid this mistake?
Mac OS X users can install a 3rd-party archiving utility like Keka, then tell it to not use Resource Forks, then set it as the default compressor.
How to do this with Keka
Tell Keka to not use Resource Forks
Open Keka without a file (From Launchpad, Spotlight, etc.)- Press ⌘ Cmd+, to open Preferences
- Select the Compression tab
- Check "Exclude Mac resource forks (eg: .DS_Store)"
Make Keka the default compressor
- In the same Keka Preferences window
- Select the General tab
- Click "Set Keka as default compressor/uncompressor" [sic]
answered Nov 5 '15 at 15:03
Ben LeggieroBen Leggiero
344212
1
This could be improved my adding some information on the last 2 steps, "tell it to not use Resource Forks, then set it as the default compressor."
– Steven C. Howell
Feb 16 '16 at 21:17
@stvn66 Done! Just FYI, though, that's usually outside the scope of these questions, which is why I didn't at first.
– Ben Leggiero
Feb 16 '16 at 21:52
2
Downvoting, sorry. I'm not a fan of installing 3rd-party software to fix a problem that can be fixed with the default software. As Chris Johnson pointed out above,zip -dwill remove the resource forks from a zipfile. In fact, I think if you use zip in the first place, the resource forks don't get added in the first place.
– Edward Falk
Jun 22 '16 at 18:44
1
@EdwardFalk That's fair! This answer was meant to solve the "How do I get it to always behave this way?" problem, not the "How do I get it to behave this way once?" one.
– Ben Leggiero
Nov 9 '16 at 14:24
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f104500%2fwhat-is-macosx-folder%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
http://www.realsoftware.com/listarchives/gettingstarted/2005-09/msg00328.html
Apple provides built-in capability to ZIP files in OS X 10.3 and higher, and these files are the result of Apple storing Resource Forks safe manner. You would never see these files running OS X 10.3 or higher, but since Windows and other operating systems do not understand this special form of Resource Forks they will appear as you see them.
answered Feb 3 '10 at 22:39
nickfnickf
1,60042128
4
It's not just resource forks, anything beyond basic file contents gets put in the AppleDouble file. Apple's moving away from resource forks, but toward things like extended attributes that'll also get stored in the AppleDouble container.
– Gordon Davisson
Feb 5 '10 at 2:02
14
You make it sound like a feature. .zip files are intentionally lacking in the metadata department. If you want metadata, use a different format, not a Mac. Example of proper zip + metadata implementation: .jar
– Zenexer
Aug 22 '13 at 4:11
16
dead link, please fix.
– think123
Feb 2 '14 at 3:24
69
"since Windows and other operating systems do not understand"--Ugh. I just hate this kind of terminology
– Joe Plante
Apr 23 '14 at 2:38
5
Just discovered: if you're on a Mac, using the command line,unzip filename.zipwill unpack the __MACOSX/ directory, which you don't want, butopen filename.zipwill do the right thing.
– Edward Falk
Jun 22 '16 at 18:40
|
show 2 more comments
http://www.realsoftware.com/listarchives/gettingstarted/2005-09/msg00328.html
Apple provides built-in capability to ZIP files in OS X 10.3 and higher, and these files are the result of Apple storing Resource Forks safe manner. You would never see these files running OS X 10.3 or higher, but since Windows and other operating systems do not understand this special form of Resource Forks they will appear as you see them.
answered Feb 3 '10 at 22:39
nickfnickf
1,60042128
4
It's not just resource forks, anything beyond basic file contents gets put in the AppleDouble file. Apple's moving away from resource forks, but toward things like extended attributes that'll also get stored in the AppleDouble container.
– Gordon Davisson
Feb 5 '10 at 2:02
14
You make it sound like a feature. .zip files are intentionally lacking in the metadata department. If you want metadata, use a different format, not a Mac. Example of proper zip + metadata implementation: .jar
– Zenexer
Aug 22 '13 at 4:11
16
dead link, please fix.
– think123
Feb 2 '14 at 3:24
69
"since Windows and other operating systems do not understand"--Ugh. I just hate this kind of terminology
– Joe Plante
Apr 23 '14 at 2:38
5
Just discovered: if you're on a Mac, using the command line,unzip filename.zipwill unpack the __MACOSX/ directory, which you don't want, butopen filename.zipwill do the right thing.
– Edward Falk
Jun 22 '16 at 18:40
|
show 2 more comments
http://www.realsoftware.com/listarchives/gettingstarted/2005-09/msg00328.html
Apple provides built-in capability to ZIP files in OS X 10.3 and higher, and these files are the result of Apple storing Resource Forks safe manner. You would never see these files running OS X 10.3 or higher, but since Windows and other operating systems do not understand this special form of Resource Forks they will appear as you see them.
answered Feb 3 '10 at 22:39
nickfnickf
1,60042128
http://www.realsoftware.com/listarchives/gettingstarted/2005-09/msg00328.html
Apple provides built-in capability to ZIP files in OS X 10.3 and higher, and these files are the result of Apple storing Resource Forks safe manner. You would never see these files running OS X 10.3 or higher, but since Windows and other operating systems do not understand this special form of Resource Forks they will appear as you see them.
answered Feb 3 '10 at 22:39
nickfnickf
1,60042128
answered Feb 3 '10 at 22:39
nickfnickf
1,60042128
answered Feb 3 '10 at 22:39
nickfnickf
1,60042128
answered Feb 3 '10 at 22:39
nickfnickf
1,60042128
1,60042128
4
It's not just resource forks, anything beyond basic file contents gets put in the AppleDouble file. Apple's moving away from resource forks, but toward things like extended attributes that'll also get stored in the AppleDouble container.
– Gordon Davisson
Feb 5 '10 at 2:02
14
You make it sound like a feature. .zip files are intentionally lacking in the metadata department. If you want metadata, use a different format, not a Mac. Example of proper zip + metadata implementation: .jar
– Zenexer
Aug 22 '13 at 4:11
16
dead link, please fix.
– think123
Feb 2 '14 at 3:24
69
"since Windows and other operating systems do not understand"--Ugh. I just hate this kind of terminology
– Joe Plante
Apr 23 '14 at 2:38
5
Just discovered: if you're on a Mac, using the command line,unzip filename.zipwill unpack the __MACOSX/ directory, which you don't want, butopen filename.zipwill do the right thing.
– Edward Falk
Jun 22 '16 at 18:40
|
show 2 more comments
4
It's not just resource forks, anything beyond basic file contents gets put in the AppleDouble file. Apple's moving away from resource forks, but toward things like extended attributes that'll also get stored in the AppleDouble container.
– Gordon Davisson
Feb 5 '10 at 2:02
14
You make it sound like a feature. .zip files are intentionally lacking in the metadata department. If you want metadata, use a different format, not a Mac. Example of proper zip + metadata implementation: .jar
– Zenexer
Aug 22 '13 at 4:11
16
dead link, please fix.
– think123
Feb 2 '14 at 3:24
69
"since Windows and other operating systems do not understand"--Ugh. I just hate this kind of terminology
– Joe Plante
Apr 23 '14 at 2:38
5
Just discovered: if you're on a Mac, using the command line,unzip filename.zipwill unpack the __MACOSX/ directory, which you don't want, butopen filename.zipwill do the right thing.
– Edward Falk
Jun 22 '16 at 18:40
4
4
It's not just resource forks, anything beyond basic file contents gets put in the AppleDouble file. Apple's moving away from resource forks, but toward things like extended attributes that'll also get stored in the AppleDouble container.
– Gordon Davisson
Feb 5 '10 at 2:02
It's not just resource forks, anything beyond basic file contents gets put in the AppleDouble file. Apple's moving away from resource forks, but toward things like extended attributes that'll also get stored in the AppleDouble container.
– Gordon Davisson
Feb 5 '10 at 2:02
14
14
You make it sound like a feature. .zip files are intentionally lacking in the metadata department. If you want metadata, use a different format, not a Mac. Example of proper zip + metadata implementation: .jar
– Zenexer
Aug 22 '13 at 4:11
You make it sound like a feature. .zip files are intentionally lacking in the metadata department. If you want metadata, use a different format, not a Mac. Example of proper zip + metadata implementation: .jar
– Zenexer
Aug 22 '13 at 4:11
16
16
dead link, please fix.
– think123
Feb 2 '14 at 3:24
dead link, please fix.
– think123
Feb 2 '14 at 3:24
69
69
"since Windows and other operating systems do not understand"--Ugh. I just hate this kind of terminology
– Joe Plante
Apr 23 '14 at 2:38
"since Windows and other operating systems do not understand"--Ugh. I just hate this kind of terminology
– Joe Plante
Apr 23 '14 at 2:38
5
5
Just discovered: if you're on a Mac, using the command line,
unzip filename.zip will unpack the __MACOSX/ directory, which you don't want, but open filename.zip will do the right thing.– Edward Falk
Jun 22 '16 at 18:40
Just discovered: if you're on a Mac, using the command line,
unzip filename.zip will unpack the __MACOSX/ directory, which you don't want, but open filename.zip will do the right thing.– Edward Falk
Jun 22 '16 at 18:40
|
show 2 more comments
Here's a link that explains it pretty well. I suppose it is a bit late to help Yada, but for posterity.
Explanation of resource fork at Wikipedia
The rest is my opinion:
@nickf: Never seeing these files is not a FEATURE of those OS X versions it is a FLAW.
People produce data, wrap it up, store it on different mediums and so on. They need to know what is needed or what is not needed.
Hiding it keeps them in the dark.
The age old bad idea of hiding things from users:
A programmer, concerned with expediency of accomplishing his own work,
abuses something in the domain of the end user, to make it easy for himself.
In this case he stored meta data in the user's data space, he then hid it from the user.
He missed the big picture: The user won't become aware of the hidden details.
When he packages his data and ships it somewhere unanticipated by the programmer,
missing parts won't get shipped or unknown parts will arrive which neither
the user nor the recipient can explain.
Hiding things from the user is bad.
It assumes the user is stupid, when more accurately it is the programmer being stupid,
or lazy.
To be clear, this bad habit is not confined to MAC. It is everywhere.
It's a consequence of programmers falling in love with their own schemes and vendors prioritizing their own goals ahead of the needs of the end user.
In brief.
__MACOSX:
weird smelling programmer droppings emerging from under the rug where they were swept.
Programmers and vendors: Please keep things in the open.
When you hide them, you make yourself stupid and the user uninformed.
edited Oct 10 '17 at 11:45
Cœur
26529
answered Dec 3 '11 at 1:31
pbernatchezpbernatchez
1,400196
10
This answer would be better if it was just an answer. The extended ranting about stupid programmers and lazy users detracts from it.
– Kristopher Johnson
Jun 19 '15 at 13:15
1
@pbernatchez Actually, if you stopped to learn about how things looked like and how they evolved, probably you wouldn't leave here your own ranty, arrogant "droppings". Resource forks were a (really nice!) implementation detail pre-Mac OS X and users only found them when interfacing with other systems; since the 90s, Apple has increasingly moved to a world without resource forks, but still bending backwards to keep compatibility. "Store metadata in the user's data space"? WTF? How twistedly do you have to define "metadata" and "user's data space" to say that? You must hate filesystems!
– hmijail
Jan 20 '17 at 12:28
3
"Hiding things from the user is bad". Man, you must also hate all kind of user interfaces, and libraries, and abstraction, and... well, any kind of programming and computers more advanced than an abacus.
– hmijail
Jan 20 '17 at 12:39
3
This does not answer the question. After reading this answer I still have no idea what metadata is contained in the _MACOSX folder, or what resource forks are. I guess people are upvoting this just because they agree with the rant?
– Atte Juvonen
Feb 15 '17 at 13:25
1
While I agree that the emotionally-charged tone is not helpful, I also absolutely agree that creating hidden things that are occasionally needed is a really bad idea, precisely as stated in this answer: users will either (a) not ship hidden files that are needed, or (b) ship hidden files that the recipient can see and neither understand. These files should either be visible, or the data should be embedded in the files in some manner that is flagged as "skippable" by other OS's. Hidden files and directories should be used primarily to protect users, not keep them in the dark.
– Mike Williamson
Oct 25 '18 at 1:47
|
show 2 more comments
Here's a link that explains it pretty well. I suppose it is a bit late to help Yada, but for posterity.
Explanation of resource fork at Wikipedia
The rest is my opinion:
@nickf: Never seeing these files is not a FEATURE of those OS X versions it is a FLAW.
People produce data, wrap it up, store it on different mediums and so on. They need to know what is needed or what is not needed.
Hiding it keeps them in the dark.
The age old bad idea of hiding things from users:
A programmer, concerned with expediency of accomplishing his own work,
abuses something in the domain of the end user, to make it easy for himself.
In this case he stored meta data in the user's data space, he then hid it from the user.
He missed the big picture: The user won't become aware of the hidden details.
When he packages his data and ships it somewhere unanticipated by the programmer,
missing parts won't get shipped or unknown parts will arrive which neither
the user nor the recipient can explain.
Hiding things from the user is bad.
It assumes the user is stupid, when more accurately it is the programmer being stupid,
or lazy.
To be clear, this bad habit is not confined to MAC. It is everywhere.
It's a consequence of programmers falling in love with their own schemes and vendors prioritizing their own goals ahead of the needs of the end user.
In brief.
__MACOSX:
weird smelling programmer droppings emerging from under the rug where they were swept.
Programmers and vendors: Please keep things in the open.
When you hide them, you make yourself stupid and the user uninformed.
edited Oct 10 '17 at 11:45
Cœur
26529
answered Dec 3 '11 at 1:31
pbernatchezpbernatchez
1,400196
10
This answer would be better if it was just an answer. The extended ranting about stupid programmers and lazy users detracts from it.
– Kristopher Johnson
Jun 19 '15 at 13:15
1
@pbernatchez Actually, if you stopped to learn about how things looked like and how they evolved, probably you wouldn't leave here your own ranty, arrogant "droppings". Resource forks were a (really nice!) implementation detail pre-Mac OS X and users only found them when interfacing with other systems; since the 90s, Apple has increasingly moved to a world without resource forks, but still bending backwards to keep compatibility. "Store metadata in the user's data space"? WTF? How twistedly do you have to define "metadata" and "user's data space" to say that? You must hate filesystems!
– hmijail
Jan 20 '17 at 12:28
3
"Hiding things from the user is bad". Man, you must also hate all kind of user interfaces, and libraries, and abstraction, and... well, any kind of programming and computers more advanced than an abacus.
– hmijail
Jan 20 '17 at 12:39
3
This does not answer the question. After reading this answer I still have no idea what metadata is contained in the _MACOSX folder, or what resource forks are. I guess people are upvoting this just because they agree with the rant?
– Atte Juvonen
Feb 15 '17 at 13:25
1
While I agree that the emotionally-charged tone is not helpful, I also absolutely agree that creating hidden things that are occasionally needed is a really bad idea, precisely as stated in this answer: users will either (a) not ship hidden files that are needed, or (b) ship hidden files that the recipient can see and neither understand. These files should either be visible, or the data should be embedded in the files in some manner that is flagged as "skippable" by other OS's. Hidden files and directories should be used primarily to protect users, not keep them in the dark.
– Mike Williamson
Oct 25 '18 at 1:47
|
show 2 more comments
Here's a link that explains it pretty well. I suppose it is a bit late to help Yada, but for posterity.
Explanation of resource fork at Wikipedia
The rest is my opinion:
@nickf: Never seeing these files is not a FEATURE of those OS X versions it is a FLAW.
People produce data, wrap it up, store it on different mediums and so on. They need to know what is needed or what is not needed.
Hiding it keeps them in the dark.
The age old bad idea of hiding things from users:
A programmer, concerned with expediency of accomplishing his own work,
abuses something in the domain of the end user, to make it easy for himself.
In this case he stored meta data in the user's data space, he then hid it from the user.
He missed the big picture: The user won't become aware of the hidden details.
When he packages his data and ships it somewhere unanticipated by the programmer,
missing parts won't get shipped or unknown parts will arrive which neither
the user nor the recipient can explain.
Hiding things from the user is bad.
It assumes the user is stupid, when more accurately it is the programmer being stupid,
or lazy.
To be clear, this bad habit is not confined to MAC. It is everywhere.
It's a consequence of programmers falling in love with their own schemes and vendors prioritizing their own goals ahead of the needs of the end user.
In brief.
__MACOSX:
weird smelling programmer droppings emerging from under the rug where they were swept.
Programmers and vendors: Please keep things in the open.
When you hide them, you make yourself stupid and the user uninformed.
edited Oct 10 '17 at 11:45
Cœur
26529
answered Dec 3 '11 at 1:31
pbernatchezpbernatchez
1,400196
Here's a link that explains it pretty well. I suppose it is a bit late to help Yada, but for posterity.
Explanation of resource fork at Wikipedia
The rest is my opinion:
@nickf: Never seeing these files is not a FEATURE of those OS X versions it is a FLAW.
People produce data, wrap it up, store it on different mediums and so on. They need to know what is needed or what is not needed.
Hiding it keeps them in the dark.
The age old bad idea of hiding things from users:
A programmer, concerned with expediency of accomplishing his own work,
abuses something in the domain of the end user, to make it easy for himself.
In this case he stored meta data in the user's data space, he then hid it from the user.
He missed the big picture: The user won't become aware of the hidden details.
When he packages his data and ships it somewhere unanticipated by the programmer,
missing parts won't get shipped or unknown parts will arrive which neither
the user nor the recipient can explain.
Hiding things from the user is bad.
It assumes the user is stupid, when more accurately it is the programmer being stupid,
or lazy.
To be clear, this bad habit is not confined to MAC. It is everywhere.
It's a consequence of programmers falling in love with their own schemes and vendors prioritizing their own goals ahead of the needs of the end user.
In brief.
__MACOSX:
weird smelling programmer droppings emerging from under the rug where they were swept.
Programmers and vendors: Please keep things in the open.
When you hide them, you make yourself stupid and the user uninformed.
edited Oct 10 '17 at 11:45
Cœur
26529
answered Dec 3 '11 at 1:31
pbernatchezpbernatchez
1,400196
edited Oct 10 '17 at 11:45
Cœur
26529
edited Oct 10 '17 at 11:45
Cœur
26529
edited Oct 10 '17 at 11:45
Cœur
26529
26529
answered Dec 3 '11 at 1:31
pbernatchezpbernatchez
1,400196
answered Dec 3 '11 at 1:31
pbernatchezpbernatchez
1,400196
answered Dec 3 '11 at 1:31
pbernatchezpbernatchez
1,400196
1,400196
10
This answer would be better if it was just an answer. The extended ranting about stupid programmers and lazy users detracts from it.
– Kristopher Johnson
Jun 19 '15 at 13:15
1
@pbernatchez Actually, if you stopped to learn about how things looked like and how they evolved, probably you wouldn't leave here your own ranty, arrogant "droppings". Resource forks were a (really nice!) implementation detail pre-Mac OS X and users only found them when interfacing with other systems; since the 90s, Apple has increasingly moved to a world without resource forks, but still bending backwards to keep compatibility. "Store metadata in the user's data space"? WTF? How twistedly do you have to define "metadata" and "user's data space" to say that? You must hate filesystems!
– hmijail
Jan 20 '17 at 12:28
3
"Hiding things from the user is bad". Man, you must also hate all kind of user interfaces, and libraries, and abstraction, and... well, any kind of programming and computers more advanced than an abacus.
– hmijail
Jan 20 '17 at 12:39
3
This does not answer the question. After reading this answer I still have no idea what metadata is contained in the _MACOSX folder, or what resource forks are. I guess people are upvoting this just because they agree with the rant?
– Atte Juvonen
Feb 15 '17 at 13:25
1
While I agree that the emotionally-charged tone is not helpful, I also absolutely agree that creating hidden things that are occasionally needed is a really bad idea, precisely as stated in this answer: users will either (a) not ship hidden files that are needed, or (b) ship hidden files that the recipient can see and neither understand. These files should either be visible, or the data should be embedded in the files in some manner that is flagged as "skippable" by other OS's. Hidden files and directories should be used primarily to protect users, not keep them in the dark.
– Mike Williamson
Oct 25 '18 at 1:47
|
show 2 more comments
10
This answer would be better if it was just an answer. The extended ranting about stupid programmers and lazy users detracts from it.
– Kristopher Johnson
Jun 19 '15 at 13:15
1
@pbernatchez Actually, if you stopped to learn about how things looked like and how they evolved, probably you wouldn't leave here your own ranty, arrogant "droppings". Resource forks were a (really nice!) implementation detail pre-Mac OS X and users only found them when interfacing with other systems; since the 90s, Apple has increasingly moved to a world without resource forks, but still bending backwards to keep compatibility. "Store metadata in the user's data space"? WTF? How twistedly do you have to define "metadata" and "user's data space" to say that? You must hate filesystems!
– hmijail
Jan 20 '17 at 12:28
3
"Hiding things from the user is bad". Man, you must also hate all kind of user interfaces, and libraries, and abstraction, and... well, any kind of programming and computers more advanced than an abacus.
– hmijail
Jan 20 '17 at 12:39
3
This does not answer the question. After reading this answer I still have no idea what metadata is contained in the _MACOSX folder, or what resource forks are. I guess people are upvoting this just because they agree with the rant?
– Atte Juvonen
Feb 15 '17 at 13:25
1
While I agree that the emotionally-charged tone is not helpful, I also absolutely agree that creating hidden things that are occasionally needed is a really bad idea, precisely as stated in this answer: users will either (a) not ship hidden files that are needed, or (b) ship hidden files that the recipient can see and neither understand. These files should either be visible, or the data should be embedded in the files in some manner that is flagged as "skippable" by other OS's. Hidden files and directories should be used primarily to protect users, not keep them in the dark.
– Mike Williamson
Oct 25 '18 at 1:47
10
10
This answer would be better if it was just an answer. The extended ranting about stupid programmers and lazy users detracts from it.
– Kristopher Johnson
Jun 19 '15 at 13:15
This answer would be better if it was just an answer. The extended ranting about stupid programmers and lazy users detracts from it.
– Kristopher Johnson
Jun 19 '15 at 13:15
1
1
@pbernatchez Actually, if you stopped to learn about how things looked like and how they evolved, probably you wouldn't leave here your own ranty, arrogant "droppings". Resource forks were a (really nice!) implementation detail pre-Mac OS X and users only found them when interfacing with other systems; since the 90s, Apple has increasingly moved to a world without resource forks, but still bending backwards to keep compatibility. "Store metadata in the user's data space"? WTF? How twistedly do you have to define "metadata" and "user's data space" to say that? You must hate filesystems!
– hmijail
Jan 20 '17 at 12:28
@pbernatchez Actually, if you stopped to learn about how things looked like and how they evolved, probably you wouldn't leave here your own ranty, arrogant "droppings". Resource forks were a (really nice!) implementation detail pre-Mac OS X and users only found them when interfacing with other systems; since the 90s, Apple has increasingly moved to a world without resource forks, but still bending backwards to keep compatibility. "Store metadata in the user's data space"? WTF? How twistedly do you have to define "metadata" and "user's data space" to say that? You must hate filesystems!
– hmijail
Jan 20 '17 at 12:28
3
3
"Hiding things from the user is bad". Man, you must also hate all kind of user interfaces, and libraries, and abstraction, and... well, any kind of programming and computers more advanced than an abacus.
– hmijail
Jan 20 '17 at 12:39
"Hiding things from the user is bad". Man, you must also hate all kind of user interfaces, and libraries, and abstraction, and... well, any kind of programming and computers more advanced than an abacus.
– hmijail
Jan 20 '17 at 12:39
3
3
This does not answer the question. After reading this answer I still have no idea what metadata is contained in the _MACOSX folder, or what resource forks are. I guess people are upvoting this just because they agree with the rant?
– Atte Juvonen
Feb 15 '17 at 13:25
This does not answer the question. After reading this answer I still have no idea what metadata is contained in the _MACOSX folder, or what resource forks are. I guess people are upvoting this just because they agree with the rant?
– Atte Juvonen
Feb 15 '17 at 13:25
1
1
While I agree that the emotionally-charged tone is not helpful, I also absolutely agree that creating hidden things that are occasionally needed is a really bad idea, precisely as stated in this answer: users will either (a) not ship hidden files that are needed, or (b) ship hidden files that the recipient can see and neither understand. These files should either be visible, or the data should be embedded in the files in some manner that is flagged as "skippable" by other OS's. Hidden files and directories should be used primarily to protect users, not keep them in the dark.
– Mike Williamson
Oct 25 '18 at 1:47
While I agree that the emotionally-charged tone is not helpful, I also absolutely agree that creating hidden things that are occasionally needed is a really bad idea, precisely as stated in this answer: users will either (a) not ship hidden files that are needed, or (b) ship hidden files that the recipient can see and neither understand. These files should either be visible, or the data should be embedded in the files in some manner that is flagged as "skippable" by other OS's. Hidden files and directories should be used primarily to protect users, not keep them in the dark.
– Mike Williamson
Oct 25 '18 at 1:47
|
show 2 more comments
To answer your final question:
how can mac users avoid this mistake?
Mac OS X users can install a 3rd-party archiving utility like Keka, then tell it to not use Resource Forks, then set it as the default compressor.
How to do this with Keka
Tell Keka to not use Resource Forks
Open Keka without a file (From Launchpad, Spotlight, etc.)- Press ⌘ Cmd+, to open Preferences
- Select the Compression tab
- Check "Exclude Mac resource forks (eg: .DS_Store)"
Make Keka the default compressor
- In the same Keka Preferences window
- Select the General tab
- Click "Set Keka as default compressor/uncompressor" [sic]
answered Nov 5 '15 at 15:03
Ben LeggieroBen Leggiero
344212
1
This could be improved my adding some information on the last 2 steps, "tell it to not use Resource Forks, then set it as the default compressor."
– Steven C. Howell
Feb 16 '16 at 21:17
@stvn66 Done! Just FYI, though, that's usually outside the scope of these questions, which is why I didn't at first.
– Ben Leggiero
Feb 16 '16 at 21:52
2
Downvoting, sorry. I'm not a fan of installing 3rd-party software to fix a problem that can be fixed with the default software. As Chris Johnson pointed out above,zip -dwill remove the resource forks from a zipfile. In fact, I think if you use zip in the first place, the resource forks don't get added in the first place.
– Edward Falk
Jun 22 '16 at 18:44
1
@EdwardFalk That's fair! This answer was meant to solve the "How do I get it to always behave this way?" problem, not the "How do I get it to behave this way once?" one.
– Ben Leggiero
Nov 9 '16 at 14:24
add a comment |
To answer your final question:
how can mac users avoid this mistake?
Mac OS X users can install a 3rd-party archiving utility like Keka, then tell it to not use Resource Forks, then set it as the default compressor.
How to do this with Keka
Tell Keka to not use Resource Forks
Open Keka without a file (From Launchpad, Spotlight, etc.)- Press ⌘ Cmd+, to open Preferences
- Select the Compression tab
- Check "Exclude Mac resource forks (eg: .DS_Store)"
Make Keka the default compressor
- In the same Keka Preferences window
- Select the General tab
- Click "Set Keka as default compressor/uncompressor" [sic]
answered Nov 5 '15 at 15:03
Ben LeggieroBen Leggiero
344212
1
This could be improved my adding some information on the last 2 steps, "tell it to not use Resource Forks, then set it as the default compressor."
– Steven C. Howell
Feb 16 '16 at 21:17
@stvn66 Done! Just FYI, though, that's usually outside the scope of these questions, which is why I didn't at first.
– Ben Leggiero
Feb 16 '16 at 21:52
2
Downvoting, sorry. I'm not a fan of installing 3rd-party software to fix a problem that can be fixed with the default software. As Chris Johnson pointed out above,zip -dwill remove the resource forks from a zipfile. In fact, I think if you use zip in the first place, the resource forks don't get added in the first place.
– Edward Falk
Jun 22 '16 at 18:44
1
@EdwardFalk That's fair! This answer was meant to solve the "How do I get it to always behave this way?" problem, not the "How do I get it to behave this way once?" one.
– Ben Leggiero
Nov 9 '16 at 14:24
add a comment |
To answer your final question:
how can mac users avoid this mistake?
Mac OS X users can install a 3rd-party archiving utility like Keka, then tell it to not use Resource Forks, then set it as the default compressor.
How to do this with Keka
Tell Keka to not use Resource Forks
Open Keka without a file (From Launchpad, Spotlight, etc.)- Press ⌘ Cmd+, to open Preferences
- Select the Compression tab
- Check "Exclude Mac resource forks (eg: .DS_Store)"
Make Keka the default compressor
- In the same Keka Preferences window
- Select the General tab
- Click "Set Keka as default compressor/uncompressor" [sic]
answered Nov 5 '15 at 15:03
Ben LeggieroBen Leggiero
344212
To answer your final question:
how can mac users avoid this mistake?
Mac OS X users can install a 3rd-party archiving utility like Keka, then tell it to not use Resource Forks, then set it as the default compressor.
How to do this with Keka
Tell Keka to not use Resource Forks
Open Keka without a file (From Launchpad, Spotlight, etc.)- Press ⌘ Cmd+, to open Preferences
- Select the Compression tab
- Check "Exclude Mac resource forks (eg: .DS_Store)"
Make Keka the default compressor
- In the same Keka Preferences window
- Select the General tab
- Click "Set Keka as default compressor/uncompressor" [sic]
answered Nov 5 '15 at 15:03
Ben LeggieroBen Leggiero
344212
edited Mar 6 at 15:23
answered Nov 5 '15 at 15:03
Ben LeggieroBen Leggiero
344212
answered Nov 5 '15 at 15:03
Ben LeggieroBen Leggiero
344212
answered Nov 5 '15 at 15:03
Ben LeggieroBen Leggiero
344212
344212
1
This could be improved my adding some information on the last 2 steps, "tell it to not use Resource Forks, then set it as the default compressor."
– Steven C. Howell
Feb 16 '16 at 21:17
@stvn66 Done! Just FYI, though, that's usually outside the scope of these questions, which is why I didn't at first.
– Ben Leggiero
Feb 16 '16 at 21:52
2
Downvoting, sorry. I'm not a fan of installing 3rd-party software to fix a problem that can be fixed with the default software. As Chris Johnson pointed out above,zip -dwill remove the resource forks from a zipfile. In fact, I think if you use zip in the first place, the resource forks don't get added in the first place.
– Edward Falk
Jun 22 '16 at 18:44
1
@EdwardFalk That's fair! This answer was meant to solve the "How do I get it to always behave this way?" problem, not the "How do I get it to behave this way once?" one.
– Ben Leggiero
Nov 9 '16 at 14:24
add a comment |
1
This could be improved my adding some information on the last 2 steps, "tell it to not use Resource Forks, then set it as the default compressor."
– Steven C. Howell
Feb 16 '16 at 21:17
@stvn66 Done! Just FYI, though, that's usually outside the scope of these questions, which is why I didn't at first.
– Ben Leggiero
Feb 16 '16 at 21:52
2
Downvoting, sorry. I'm not a fan of installing 3rd-party software to fix a problem that can be fixed with the default software. As Chris Johnson pointed out above,zip -dwill remove the resource forks from a zipfile. In fact, I think if you use zip in the first place, the resource forks don't get added in the first place.
– Edward Falk
Jun 22 '16 at 18:44
1
@EdwardFalk That's fair! This answer was meant to solve the "How do I get it to always behave this way?" problem, not the "How do I get it to behave this way once?" one.
– Ben Leggiero
Nov 9 '16 at 14:24
1
1
This could be improved my adding some information on the last 2 steps, "tell it to not use Resource Forks, then set it as the default compressor."
– Steven C. Howell
Feb 16 '16 at 21:17
This could be improved my adding some information on the last 2 steps, "tell it to not use Resource Forks, then set it as the default compressor."
– Steven C. Howell
Feb 16 '16 at 21:17
@stvn66 Done! Just FYI, though, that's usually outside the scope of these questions, which is why I didn't at first.
– Ben Leggiero
Feb 16 '16 at 21:52
@stvn66 Done! Just FYI, though, that's usually outside the scope of these questions, which is why I didn't at first.
– Ben Leggiero
Feb 16 '16 at 21:52
2
2
Downvoting, sorry. I'm not a fan of installing 3rd-party software to fix a problem that can be fixed with the default software. As Chris Johnson pointed out above,
zip -d will remove the resource forks from a zipfile. In fact, I think if you use zip in the first place, the resource forks don't get added in the first place.– Edward Falk
Jun 22 '16 at 18:44
Downvoting, sorry. I'm not a fan of installing 3rd-party software to fix a problem that can be fixed with the default software. As Chris Johnson pointed out above,
zip -d will remove the resource forks from a zipfile. In fact, I think if you use zip in the first place, the resource forks don't get added in the first place.– Edward Falk
Jun 22 '16 at 18:44
1
1
@EdwardFalk That's fair! This answer was meant to solve the "How do I get it to always behave this way?" problem, not the "How do I get it to behave this way once?" one.
– Ben Leggiero
Nov 9 '16 at 14:24
@EdwardFalk That's fair! This answer was meant to solve the "How do I get it to always behave this way?" problem, not the "How do I get it to behave this way once?" one.
– Ben Leggiero
Nov 9 '16 at 14:24
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f104500%2fwhat-is-macosx-folder%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
8
They are super-irritating, yes, and usually pointless as the resource forks are so often empty. But at least they're harmless, unlike the non-standard approach Apple have taken to >4GB archive sizes with the built-in OS X stuff, which will confuse any other tool and break again for sufficiently large files. And hey, it could be worse, it could be storing two copies of each file with the same name, one for the data and one for the resource fork, often making it impossible to access either, like pre-OSX Mac used to. Oh Apple, why do you hate standard file formats?
– bobince
Feb 3 '10 at 23:01
3
@bobince: actually, resource forks were a very good idea ... at the time. These days, the same effect is achieved by storing resources as individual files, most of which look pretty much like standard file formats.
– Duncan
Feb 3 '10 at 23:20
16
Nothing wrong with metadata as such, it's just that Apple have such a knack of making up their own formats and messing up existing formats with gratuitously incompatible extensions! Having the content-type data as metadata is in itself a great thing and it saddens me that OS X is moving towards the Windows hack of file extensions as an alternative. Although this isn't as bad as on Linux, where the filesystem supports storing Content-Type metadata, but no desktops use it, preferring a thoroughly broken mixture of file-extension/name-patterns and content-sniffing (urgh!). Sigh, OSes eh?
– bobince
Feb 3 '10 at 23:33
@bobince: But yes, at least the format they made up for this does not do any real harm, other than slightly cluttering directory listings and wasting essentially 1 inode and 1 block per empty resource fork extracted, unless you use something like NTFS (which will store the file contents in the MFT for such small files), in which case it just wastes the "inode" (MFT entry).
– SamB
Feb 15 '11 at 20:52
9
Can be fixed after the fact by
zip -d filename.zip __MACOSX/*– Chris Johnson
Dec 2 '12 at 1:31