編集する

編集する

いくつかのmakeファイルやエミュレータなどを実行した後、ソースコードファイル(* .cc)はまだ同じファイルであるにもかかわらず、「壊れたリンク」として読み込まれます。 (*.cc)ファイルは私のgitリポジトリから来ており、そことは別のコンピュータでは(*.cc)ファイルがソースコードファイルとして正しく読み取られているので、これは正しいファイルであることを知っています。また、gitコマンドを使用してgit statusファイルが変更されていないことを確認することもできます。もしそうなら、唯一の結論は、Linuxファイルシステムのプロパティが破損しているということです。

これらのエラーを修正する方法は?

以下は、ファイルから実行するいくつかのコマンドです。

$chmod 777 producer_consumer.cc 
chmod: cannot operate on dangling symlink ‘producer_consumer.cc’

$lsattr producer_consumer.cc 
lsattr: Operation not supported While reading flags on producer_consumer.cc

$readlink producer_consumer.cc
// EPOS Synchronizer Abstraction Test Program

#include <utility/ostream.h>
#include <thread.h>
#include <semaphore.h>
#include <alarm.h>

using namespace EPOS;

const int iterations = 100;

OStream cout;

const int BUF_SIZE = 16;
char buffer[BUF_SIZE];
Semaphore empty(BUF_SIZE);
Semaphore full(0);

int consumer()
{
    int out = 0;
    for(int i = 0; i < iterations; i++) {
        full.p();
        cout << "C<-" << buffer[out] << "\t";
        out = (out + 1) % BUF_SIZE;
        Alarm::delay(5000);
        empty.v();
    }

    return 0;
}

int main()
{
    Thread * cons = new Thread(&consumer);

    // producer
    int in = 0;
    for(int i = 0; i < iterations; i++) {
        empty.p();
        Alarm::delay(5000);
        buffer[in] = 'a' + in;
        cout << "P->" << buffer[in] << "\t";
        in = (in + 1) % BUF_SIZE;
        full.v();
    }

    cons->join();

    cout << "The end!" << endl;

    delete cons;

    return 0;
}

私のLinuxは次のとおりです Linux Mint 17.3 XCFE - 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22 09:37:25 UTC 2015 i686 i686 i686 GNU/Linux

以下は、ノーチラスファイルマネージャのファイルプロパティのイメージです。

https://i.stack.imgur.com/FyD9g.png

編集する

I have no idea how you ended up with this.

ただ前回のようにどうするか調べて、直してからまたやりました。私はGUI gitツールであるSmartgitを使用していますが、ファイルシステムからファイルを削除するたびにSmartgitインターフェイスに移動し、クリックしてステータスをリセット(つまり元に戻す)するたびに、次のようなクレイジーファイルリンクが表示されます。しかし、奇妙なことは、git statusコンソールで表示してもファイルが変更されず、リモートのgitリポジトリにあるファイルとまったく同じです。

また、コマンドラインを介して次のことを行う場合、Smartgitに固有のものではありません。 git checkout HEAD -- philosophers_dinner.cc

ファイルを削除すると、クレイジーリンクのように生き返ります。これで、次の2つのコマンドで一日中Linuxを使用できます。

# firstly we delete the file
rm philosophers_dinner.cc

# this command will break the file
git checkout HEAD -- philosophers_dinner.cc

# these command will fix the break file by git reset
readlink philosophers_dinner.cc > philosophers_dinner.cc.new
mv philosophers_dinner.cc{.new,}

最初は古いGitかもしれないと思いました(1.9.3を使っています)。その後、2.9.3にアップデートし、まだこれを行います。私のLinuxが古すぎるため、18.0ではなくMint 17.3かもしれませんが、インストールしたとき、ほとんどの作業は17.3のように動作しませんでした。

答え1

最も興味深い!

あなたのproducer_consumer.ccファイルはシンボリックリンクです。しかし、これは古いシンボリックリンクではありません。これは完全に狂った目標への象徴的なリンクです。これは、リンク先がC ++プログラムの完全なソースコードである非常に長いファイル名であるためです。もちろん、このシンボリックリンクはぶら下がっているシンボリックリンクです。ノーチラスで見られる動作は、headこれらのシンボリックリンクで予想されるものとまったく同じです。

お客様は、いかなる形でも「腐敗」が存在するという結論を立証する証拠を提供していません。奇妙ですが、これは完全に許可されているシンボリックリンクです。さまざまな一般的なツールを使用してこれらのシンボリックリンクを作成する方法はいくつかあります。たとえば、以下はシェル置換を使用した初心者の練習です。

あなたがどのようにこの奇妙な混乱に陥ったのかはあなただけが知っているだけで、私たちには公開しませんでした。それを削除する方法は非常に簡単です。以下は2つのコマンドです。そのうちの1つは主に実行されました。

linkProducer_consumer.cc> Producer_consumer.cc.newを読む
mv Producer_consumer.cc{.new,}

同様に、今後どのように再び問題が発生しないようにする方法は、単に漠然と「ああ、私が何かをした」ではなく、World Zeroの具体的な情報を提供したので、自分だけが知ることができます。それはおそらく、ある時点で何かをするためにmakefileを実行したかもしれません。このシンボリックリンクの存在に影響を与えることも、そうでない場合もあります。

したがって、これら2つのコマンドを再実行できます。

答え2

ファイルが壊れたリンクなので、壊れたリンクとして表示されます。 C++ コードのように見えるものを対象とするリンクです。通常、リンクの宛先はファイルパスのように見えますが、システムに関する限り、それはほんの一部のテキストです。

いいえ、どうやってこのような結果が出たのかわかりません。たぶん、どこかに間違ったコピーペーストがあったかもしれません。コマンドを実行したか、ln -s '// EPOS Synchronizer …}' producer_consumer.cc同等の操作を実行しました。 makefileコマンドln -s '$(shell cat $<)' $<またはそれに対応するコマンドを実行することもできます。

現在のコンテンツを保持するには、次のコマンドを使用してコンテンツを抽出してreadlinkファイルに保存します。

mv producer_consumer.cc bad-link
readlink bad-link >producer_consumer.cc
rm bad-link

Gitリポジトリにシンボリックリンクを保存したようです。 Gitはシンボリックリンクを保存することができますが、シンボリックリンクを持たないシステムでこれを確認すると、通常のファイルが得られます。 Linuxの作業コピーに通常のファイルがある場合は、それをgitにコミットします。

git -m 'Changed symlink back to regular file' producer_consumer.cc

以前のバージョンを見ると、まだシンボリックリンクがあります。git log producer_consumer.ccシンボリックリンクがいつチェックインされたかを教えてくれますが、理由を説明するのには役立ちません。

答え3

解決策は、ファイルのバージョンが管理されるため、最初にファイルを削除して削除を送信することです。次に、新しいファイルを作成して複製するのではなく、バージョンシステムから正しい内容をコピーします。たとえば、GitHubで許可されている場合は、Webブラウザを介してコミットします。

バージョン管理システムから対応する項目が削除される。これはgit status、コマンドがソースコードファイルとシンボリックリンクを区別できないためです。問題を解決するだけで、git statusコマンドはその間に何があるかを表示しません。したがって、まず削除をコミットしてから、他のコミットで追加を変更する必要があります。

関連情報