4 ms·

> Those .DS_Store files are created in arbitrary directories by the Apple file manager or something. .DS_Store files come from Apple's file systems containing

> Those .DS_Store files are created in arbitrary directories by the Apple file manager or something. .DS_Store files come from Apple's file systems containing a separate data and resource fork. APFS can natively store the contents, but for foreign file systems/network shares, a .DS_Store file is created to store those attributes.

remram 3y ago
I never knew that. How come they end up in Git repositories then? They shouldn't be visible to Git running on a native Mac filesystem?
- Ndymium 3y ago
  They are visible to programs, for example if you run `ls -a` you will see them on macOS too. I reckon they're only transparent to Finder (where you can't see them even if you're showing hidden files).
- ckolkey 3y ago
  They're just a file, so git can see it. Good habit would be to add it to the project's gitignore, or your global gitignore (or both)
  - globular-toast 3y ago
    It's a pet peeve of mine when people put stuff like this in a project's `.gitignore`. The proper place is either your global gitignore (probably appropriate for stupid stuff like this) or in your clone in `.git/info/exclude`. `.gitignore` is for stuff that all developers need to ignore, like compiler output, and should be kept to the bare minimum.
    - s1gsegv 3y ago
      I can see an argument for this being semantically correct, but in practice I think it's preferable to have the repo checkout in the closest configuration to correct for new developers who will start contributing. And, for what it's worth, all developers need to ignore .DS_Store files regardless if Finder creates it or it gets placed in when you unzip something created on a Mac, for instance. In the best case, you spend extra time needlessly denying PRs and bothering people who already likely don't know git well enough to cleanly fix their commit. In the case of a repo large enough that you're not the only person approving PRs, I'd say it's almost inevitable that they eventually slip through. Just my 2¢ from experience working in the industry.
    - krisoft 3y ago
      > .gitignore` is for stuff that all developers need to ignore But that is the case, all developers need to ignore the ".DS_Store" files. So by your own rule it is appropriate in there then?
      - Skeime 3y ago
        I think the point is that only developers on Macs need to ignore them. If they properly do so, these files will never appear on other developer’s machines, and they therefore don’t need them in .gitignore.
        lxgr 3y ago
        It’s not that straightforward to ignore files in git without adding them to a local .gitignore, though. Global .gitignore exists, but I just had to look it up again to refresh my memory – chances are, junior devs or hobby developers will never even consider it as an option. That said, arguably ignoring .DS_Storage should be the default on macOS builds of git.
        sodapopcan 3y ago
        I just teach people about global gitignores then they know. If someone were to commit something to an open source project, I'd reject it and teach them about it too. I'm all about the global gitignores. The ignore file can actually act as a form of documentation if kept tidy. It's a single source of truth of all the artifacts an app can produce.
      - bandie91 3y ago
        he must meant that you block something at its origin: dsstore managed by the OS, you block it at system level; `.o` produced by the project stuff, block it at project repo level.
        krisoft 3y ago
        I must admit that my viewpoint is coloured by the fact that I work on repos where most devs use OSX. I can do the principled thing as you describe it. And then I can be angry every time a new dev arrives who doesn't have their computer correctly set up yet, or someone reinstalls their machine, or anything like that. Or I can do the pragmatic thing, add one extra line to the .gitignore file and forget about it forever. In my opinion this is not a hill worth dying on.
    - aldonius 3y ago
      TIL there's a global gitignore, thanks!
  - remram 3y ago
    So they are not a resource fork, then.
- deleted 3y ago
  [deleted]
YetAnotherNick 3y ago
I don't have OCD but the casing of .DS_Store annoys me a lot for some reason. I have turned on option to display dot files in finder and I see this god awful name everywhere. It could be .DSStore, .ds_store, .DS Store or even .DS_STORE, current one is the worst.
lxgr 3y ago
> .DS_Store files come from Apple's file systems containing a separate data and resource fork No, that would be ._<filename> files (containing resource forks, when the corresponding file is stored on a volume with a FS not supporting them natively), which are much rarer these days given that resource forks are not really used anymore. .DS_Store contains Finder metadata, as far as I know (non-default icon sorting or positioning, categories, tags etc.), and they occur on all volumes, including Mac native filesystems. Finder just hides them by default.

remram 3y ago

I never knew that. How come they end up in Git repositories then? They shouldn't be visible to Git running on a native Mac filesystem?

Ndymium 3y ago
They are visible to programs, for example if you run `ls -a` you will see them on macOS too. I reckon they're only transparent to Finder (where you can't see them even if you're showing hidden files).
ckolkey 3y ago
They're just a file, so git can see it. Good habit would be to add it to the project's gitignore, or your global gitignore (or both)
- globular-toast 3y ago
  It's a pet peeve of mine when people put stuff like this in a project's `.gitignore`. The proper place is either your global gitignore (probably appropriate for stupid stuff like this) or in your clone in `.git/info/exclude`. `.gitignore` is for stuff that all developers need to ignore, like compiler output, and should be kept to the bare minimum.
  - s1gsegv 3y ago
    I can see an argument for this being semantically correct, but in practice I think it's preferable to have the repo checkout in the closest configuration to correct for new developers who will start contributing. And, for what it's worth, all developers need to ignore .DS_Store files regardless if Finder creates it or it gets placed in when you unzip something created on a Mac, for instance. In the best case, you spend extra time needlessly denying PRs and bothering people who already likely don't know git well enough to cleanly fix their commit. In the case of a repo large enough that you're not the only person approving PRs, I'd say it's almost inevitable that they eventually slip through. Just my 2¢ from experience working in the industry.
  - krisoft 3y ago
    > .gitignore` is for stuff that all developers need to ignore But that is the case, all developers need to ignore the ".DS_Store" files. So by your own rule it is appropriate in there then?
    - Skeime 3y ago
      I think the point is that only developers on Macs need to ignore them. If they properly do so, these files will never appear on other developer’s machines, and they therefore don’t need them in .gitignore.
      - lxgr 3y ago
        It’s not that straightforward to ignore files in git without adding them to a local .gitignore, though. Global .gitignore exists, but I just had to look it up again to refresh my memory – chances are, junior devs or hobby developers will never even consider it as an option. That said, arguably ignoring .DS_Storage should be the default on macOS builds of git.
        sodapopcan 3y ago
        I just teach people about global gitignores then they know. If someone were to commit something to an open source project, I'd reject it and teach them about it too. I'm all about the global gitignores. The ignore file can actually act as a form of documentation if kept tidy. It's a single source of truth of all the artifacts an app can produce.
    - bandie91 3y ago
      he must meant that you block something at its origin: dsstore managed by the OS, you block it at system level; `.o` produced by the project stuff, block it at project repo level.
      - krisoft 3y ago
        I must admit that my viewpoint is coloured by the fact that I work on repos where most devs use OSX. I can do the principled thing as you describe it. And then I can be angry every time a new dev arrives who doesn't have their computer correctly set up yet, or someone reinstalls their machine, or anything like that. Or I can do the pragmatic thing, add one extra line to the .gitignore file and forget about it forever. In my opinion this is not a hill worth dying on.
  - aldonius 3y ago
    TIL there's a global gitignore, thanks!
- remram 3y ago
  So they are not a resource fork, then.
deleted 3y ago
[deleted]

YetAnotherNick 3y ago

I don't have OCD but the casing of .DS_Store annoys me a lot for some reason. I have turned on option to display dot files in finder and I see this god awful name everywhere. It could be .DSStore, .ds_store, .DS Store or even .DS_STORE, current one is the worst.

lxgr 3y ago

> .DS_Store files come from Apple's file systems containing a separate data and resource fork No, that would be ._<filename> files (containing resource forks, when the corresponding file is stored on a volume with a FS not supporting them natively), which are much rarer these days given that resource forks are not really used anymore. .DS_Store contains Finder metadata, as far as I know (non-default icon sorting or positioning, categories, tags etc.), and they occur on all volumes, including Mac native filesystems. Finder just hides them by default.