2017-06-05 6 views
0

私のディレクトリに、そのファイルを含むそのディレクトリの合計がsha256であるファイルを作成します。ここでの難しさは、ディレクトリのsha256が前記のsha256でファイルを更新することによって影響を受けることである。これは可能ですか?ディレクトリ内のファイルには、ディレクトリ全体の現在のsha-256が含まれています。

これはコンピュータに未来を予測する方法をほとんど求めていますが、これを行うための再帰的なアルゴリズムがあるのだろうかと思います。たとえば、チェックサムとオブジェクトの間に一定の一貫した関係があり、1バイトが変更されたそのオブジェクトのチェックサムがあるとします。

これは、この問題から出てきた好奇心の問題です。git describe --tagsの出力を.gitディレクトリがないリポジトリ(おそらくこのデータをリポジトリに保存する)に再作成しようとしています。

+0

これの有用性は何ですか?ファイルがリポジトリにある限り、コミットIDはGitを使って簡単に取得できます。レポがなくなったとき(ファイルがエクスポートされたときなど)、コミットIDは役に立たない。さらに、GitコミットIDは、コミットがリベースされたときに変更されます。 – axiac

+0

構築プロセス(ここではAWS codepipeline)がリポジトリ全体ではなくエクスポートされたファイルを使用するビルド成果物にタグ付けするために、コミットID(具体的には 'git describe --tags'の出力)を使用したいと思います。 – joelb

答えて

0

これはできません。解決策がないかもしれません。簡単な例を取ってみましょう:SHA256ハッシュの値が256ビットの代わりに1ビットだけだったとします。ハッシュ0をファイルに入れると、ディレクトリ全体が1という値にハッシュされると仮定します。ファイルに1を入れると、ディレクトリ全体が0の値にハッシュされます。それで解決策はありません。完全な256ビットのハッシュでも同じことが起こる可能性があります。私は確かなことは確かではない。

解決策がある場合は、すべての可能性のあるチェックサムを網羅的に検索して解決策を見つけることができます。安全なハッシュの性質上、それよりも大幅に高速化することはできません。しかし、これはおそらく、太陽が赤い巨人になって地球を呑み込むまで続くでしょう。あなたの実際の状況を(XY problemを注意してください)を改善する

、あなたが構築する前に、ソースファイル内git rev-parse HEADどこかの結果を固執するようにビルドシステムに指示してみてください、またはあなたのプログラムが実行時にこれを実行することができます。

+0

ありがとうございます。私はあなたの最初の段落を理解していません。あなたは詳しく説明できますか? – joelb

+0

あなたが探しているチェックサムが存在するという保証はないということだけです。私は例を挙げて明らかにした。 – Thomas

関連する問題