☰

编辑

tag-icon • tag-icon shell linux-mint symlink xfce make
编辑

在运行一些 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

这是有关 nautilus 文件管理器上的文件属性的图像：

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

删除文件后，它又像那个疯狂的链接一样死而复生。现在，我可以在这两个命令中整天玩 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太旧了，Mint 17.3而不是18.0，但是当我安装它时，大多数东西都不能像17.3上那样工作，然后我又恢复了回来。

答案1

最有趣！

您的producer_consumer.cc文件是一个符号链接。但这不是任何旧的符号链接。这是一个与完全疯狂的目标的象征性链接。这是因为链接的目标是一个非常长的文件名，而且恰好是 C++ 程序的整个源代码。当然，这个符号链接是悬空符号链接；您看到的 和 nautilus的行为head正是这种符号链接的预期行为。

你没有提供任何证据来证实存在任何形式的“腐败”的结论。这是一个完全允许的符号链接，尽管是一个疯狂的链接。有很多方法可以使用各种普通工具来建立这样的符号链接。例如，这是使用 shell 替换的初学者练习。

你是如何陷入这离奇的混乱之中的，只有你自己知道，但你却没有向我们透露。如何摆脱它完全是轻而易举的事情。这是两个命令，其中之一您大部分已经运行过：

阅读链接 Producer_consumer.cc > Producer_consumer.cc.new
mv Producer_consumer.cc{.new,}

同样，你如何阻止自己在未来再次陷入困境也是只有你自己才能知道的事情，因为你已经向零世界提供了具体的信息，而不仅仅是模糊的“哦，我做了一些事情”。您可能运行了一些 makefile，在某个时候做了一些事情。它可能会或可能不会影响此符号链接的存在。

因此您可能会再次运行这两个命令。

答案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命令将无法显示它们之间的内容。因此，您首先需要提交删除，然后在另一个提交中更正它们的添加。

相关内容