mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comment

Browse source
This commit is contained in:
Joey Hess 2019-12-20 16:11:21 -04:00
parent 0141c5436e
commit 14897ec8e2
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 23 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
doc/bugs/be_robust_to_additions_of_more_specific_mime_types_to_libmagic___40__e.g._application__47__json__41__/comment_2_08448687578634b6281ea285f18d87e7._comment Normal file
View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2019-12-20T20:00:14Z"
content="""
Yes, mimeencoding=binary is intended for those cases where you just want a
robust (presumably) text/binary division.
The "any mimetype matches" approach seems like it could break things too.
Consider:
(not mimetype=text/plain and (mimetype=text/* or mimetype=application/json)) or mimetype=AI/buggy
Currently a shell script is found to be only text/x-shellscript,
so it would match the above. If git-annex were changed to consider
all reported mime types, the shell script, being also text/plain
would not match.
And then, once the mime database solves the halting problem and helpfully
starts flagging shell scripts as AI/buggy (all shell scripts are presumably
buggy so maybe that AI has an easy job), the behavior on the above example
would change for a third time, back to matching.
"""]]