☰

mime-infoでテキスト/一般モード「*、v」を共有するのはなぜですか？

tag-icon • tag-icon mime-types freedesktop rcs
mime-infoでテキスト/一般モード「*、v」を共有するのはなぜですか？

freedesktop.org メディアタイプデータベースshared-mime-infoの場合ファイル名パターン*,vMIMEタイプに関連付けられていますが、そのtext/plain理由を理解できません。なぜなら、,vとは*,v基本的にクエリとして役に立たないからです！

このパターンの2008コミットを追加しました。説明しませんが、テストケースでは指摘しています。RedHat Bugzillaのバグ。そこで誰かが「RCSファイル」で終わるファイル名を持っていたが、,vオーディオファイルとして認識されたというエラーが発生しました。追加のコンテキストがない場合は、「RCSファイル」がレーダー断面データやAutodesk ReCapスキャンファイルではなくリビジョン制御システムを参照していると推測できます。

なぜこのユーザーの奇妙な経験は誰もが変わったのですかshared-mime-info？これは広範な問題ですか？おそらくRCSがそのエンディングを持つファイルを生成するのでしょうか？shared-mime-infoこれらのランダムファイルがオーディオとして処理される理由を見つけるのではなく、エラー†に対する適切な応答にこれを追加するのはなぜですか？

†私は「修正」の代わりに「対応」と言います。したユーザーの問題を解決します。このバグは、明示的に原因が判明していないため、バージョンのソフトウェアには表示されなくなったため終了しましたshared-mime-info。

答え1

,vRCSは次のサフィックスを使用してファイルを生成します。

$ mkdir RCS
$ echo hello > hello.txt
$ ci hello.txt 
RCS/hello.txt,v  <--  hello.txt
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> test file
>> 
initial revision: 1.1
done
$ ls RCS
hello.txt,v

そして、元のファイルとまったく同じようには見えないので、実際には別のファイルとして識別するのが賢明かもしれません。

$ cat RCS/hello.txt,v 
head    1.1;
access;
symbols;
locks; strict;
comment @# @;


1.1
date    2021.08.28.14.44.57;    author ilkkachu; state Exp;
branches;
next    ;


desc
@test file
@


1.1
log
@Initial revision
@
text
@hello
@

また、行ベースの方法ですが、少なくとも一部のバイナリデータを処理できるようです。

なぜオーディオファイルとして認識されるのかわかりません。

答え2

質問に自分で答えるのに十分な情報があります。 「*、v」は、RCSにチェックインされたオーディオファイルがオーディオファイルとして解釈されるのを防ぐために存在します（ファイル形式が異なるため試みると）。遊ぶそれらを）。

RCS ファイルには、以下を含めることができます。バイナリデータを別の「文字列」として扱うからです。これマニュアルページこれはあまり詳しく述べられていません：

文字列は以下に含まれています。@。文字列に以下が含まれている場合@、倍増しなければなりません。それ以外の場合は、文字列に任意のバイナリデータを含めることができます。

プログラムごとに区別できるさまざまなオーディオ/ビデオ形式があります。file）ファイルの内容を確認してください。ただし、MIMEは名前、特にファイルを識別するように設計されています。「サフィックス」）、一部のシステムでは、ファイル名のみを使用してMIMEタイプを自動的に推論しようとします。これは本質的にエラーが発生しやすく、実装に対応するための'*,v'解決策です。

関連情報