-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exclude common core dump file names by default #8
Conversation
@@ -33,7 +33,10 @@ const defaultRules = [ | |||
'.DS_Store', | |||
'._*', | |||
'*.orig', | |||
'package-lock.json' | |||
'package-lock.json', | |||
'core', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm worried about this one being a bit too general. Are core dumps seriously just called core
? 😱
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zkat That’s the default at least for Linux (although it’s configurable), and Wikipedia agrees by calling it the “traditional” naming of core dumps.
It’s also practical – some people configure their core dump names to have the PID or something like that in them, but that isn’t a sensible default because it can mean your disk filling up with core dumps. Just overwriting a file named core
every time makes quite a bit of sense…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On OS X and other BSD-family Unixes, it's common for core dumps to be in /var/cores
or /cores
, with a name of core.${pid}
. But in those cases, they're not in cwd, so it's less of an issue for this case.
I'm personally fine with ignoring core
by default, as long as it can be explicitly included by a later rule, but it'd be good to see how often this happens empirically by looking at the registry, and how many files named core
are not actually core dumps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, actually, I think some versions of SmartOS drop the core file as core.${pid}
in cwd? Might be worth also adding core.+([0-9])
as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@isaacs yup, done! 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some people do encounter problems with this. Is there any way to make sure directories named core
don't get removed? Something like !core/
+ !**/core/
should work (the latter because just core/
doesn't work in subdirectories), but maybe there's a better way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@larsgw Yeah, that makes sense and I don’t see a better way off the top of my head either. Do you want to open a PR for that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here you go #25
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a "common" utils repo required through git in almost all my microservices, (basically, types and some classes to ease the communication between them). Suddenly, all my classes and types from the "core" service disappeared in my services.
I think this behaviour should be undone as it breaks functional code, and is included in a minor update.
ping @zkat :) |
@addaleax when you get a minute, could you clean up the merge conflict? Looks pretty straightforward. Thanks! |
@aeschright Sure, done! |
I just spent 2 hours chasing down why |
npm introduced [this change](npm/npm-packlist#8) in vesion 6.8.0. Which adds the term `core` the list of default ingores for all files and folders. The shaka-player source code contains such a file which is required for building it manually. There is [a pull request](npm/npm-packlist#40) to revert those changes in npm, but according to the description there will be most likely no patch release and it will be fixed only with next major version 7.0.0.
npm introduced [this change](npm/npm-packlist#8) in vesion 6.8.0. Which adds the term `core` the list of default ingores for all files and folders. The shaka-player source code contains such a file which is required for building it manually. There is [a pull request](npm/npm-packlist#40) to revert those changes in npm, but according to the description there will be most likely no patch release and it will be fixed only with next major version 7.0.0.
npm introduced [this change](npm/npm-packlist#8) in vesion 6.8.0. Which adds the term `core` the list of default ingores for all files and folders. The shaka-player source code contains such a file which is required for building it manually. There is [a pull request](npm/npm-packlist#40) to revert those changes in npm, but according to the description there will be most likely no patch release and it will be fixed only with next major version 7.0.0.
npm introduced [this change](npm/npm-packlist#8) in vesion 6.8.0. Which adds the term `core` the list of default ingores for all files and folders. The shaka-player source code contains such a file which is required for building it manually. There is [a pull request](npm/npm-packlist#40) to revert those changes in npm, but according to the description there will be most likely no patch release and it will be fixed only with next major version 7.0.0.
/cc @zkat