-1

After some operation as run some make files, and emulators, a source code file (*.cc) is read as a 'broken link', despite it still the same file. I know it is the correct file because the (*.cc) file come from my git repository, and over there and other computer, the (*.cc) file is being correctly read as a source code file. Also, I can see over the git command git status the file is unchanged. Then the only conclusion is the Linux File System atribute corruption.

How to fix such error?

This below are some commands run over the file.

$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;
}

My linux is this: 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

This is a image about the file property over the nautilus file manager:

http://i.imgur.com/p9Jqy0W.png

Edit

I have no idea how you ended up with this.

I just figure it out how to do it as I and did it again after fix it. I am using the GUI git tool Smartgit, and every time I delete the file file on the file system, and go to the Smartgit interface, and click to reset its state, (i.e., undelete it), it comes back from the dead as that crazy file link. But the stranger, is even by console git status show the file is unchanged and is perfectly as it is on the remote git repository.

Also, it is not only on Smartgit, if by command line I do: git checkout HEAD -- philosophers_dinner.cc

After delete the file, it comes back again from the dead as that crazy link. Now, I can stay all day long playing with linux within these two commands:

# 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,}

On the first I thought it could be an outdated git (I was using 1.9.3), then I updated to 2.9.3, but stills doing it. May be my linux is too outdated, Mint 17.3 instead of 18.0, however when I installed it most things are not working as well as on 17.3, then I reverted back.

  • 1
    You can entertain people even more with the output of readlink producer_consumer.cc in your question. – JdeBP Aug 26 '16 at 17:53
  • It just show the source code file contents. The file it self stills being interpreted by the terminal and everything else as nautilus as being a link. Which makes no sense at all. I am missing something? --> head producer_consumer.cc --> head: cannot open ‘producer_consumer.cc’ for reading: No such file or directory – user Aug 26 '16 at 18:27
  • We have absolutely no clue what you are trying to achieve or even what you're actually doing – grochmal Aug 26 '16 at 19:41
  • I should reformulate that then. I will rewrite it. – user Aug 26 '16 at 21:34
4

Most entertaining!

Your producer_consumer.cc file is a symbolic link. But it's not any old symbolic link. It's a symbolic link with a completely nutty target. That's because the target of the link is an exceedingly long filename that happens (also) to be the entire source code of a C++ program. Of course, this symbolic link is a dangling symbolic link; and the behaviour of head and nautilus that you see is exactly to be expected for such a symbolic link.

You've presented no evidence to bear out the conclusion that there's any sort of "corruption" going on. This is a perfectly allowable symbolic link, albeit a bonkers one. There are a fair number of ways, with various ordinary tools, to make such a symbolic link. It's a beginner exercise in using shell substitutions, for example.

How you got into this bizarre mess only you know, and you haven't revealed to us. How you get out of it is a complete doddle. It's two commands, one of which you have mostly already run:

readlink producer_consumer.cc > producer_consumer.cc.new
mv producer_consumer.cc{.new,}

How you stop yourself from getting back into it again in the future is, likewise, something only you can know, as you've given the world zero concrete information beyond vague "oh, I did some stuff" handwaves. You might have run some makefile, that did something, at some point. It may or may not have had a bearing upon the existence of this symbolic link.

So you might be running these two commands again.

  • I fixed it deleting them, committing it, recreating them, and committing it again. Now they stopped doing it on git checkout HEAD -- philosophers_dinner.cc. – user Aug 26 '16 at 23:56
3

Your file is shown as a broken link because it is a broken link. It is a link whose target is something that looks like C++ code. Normally the target of a link looks like a path to a file, but as far as the system is concerned, it's just some text.

No, I have no idea how you ended up with this. Maybe a bad copy-paste somewhere. You ran the command ln -s '// EPOS Synchronizer …}' producer_consumer.cc or did something equivalent. Maybe a makefile command that ran ln -s '$(shell cat $<)' $< or something equivalent.

If you want to preserve the current content, extract it with readlink and save it to a file:

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

It appears that you have stored the symbolic link in your git repository. Git can store symbolic links, but if you check them out on a system without symlinks then you get a regular file. Once you have a regular file in your Linux working copy, commit it to git.

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

You'll still have a symlink if you check out historical versions. git log producer_consumer.cc should tell you when the symlink was checked in, but that might not help with the why.

  • Your file is shown as a broken link because it is a broken link. You are right. I do not know how, but even the GitHub website was saying at least, one of them as a symlink. But it is not a link, it cannot be a link, it is my source code file, when I open them on windows it is fine, I can edit them, except on linux. Whatever, I fixed it deleting them, committing it, recreating them, and committing it again. Now they stopped doing it on git checkout HEAD -- philosophers_dinner.cc. – user Aug 26 '16 at 23:53
  • @RockNinja From your description, I think you committed the symlink to git. Git can store symlinks, but if you check them out on a system without symlinks, you get a regular file. It still is strange that you ended up with a symlink in the first place. – Gilles Aug 27 '16 at 8:16
  • I find out how to. First, I do not know why, but they where ordinary simple relative linux symlinks. !symlinks. Latter, on windows, I opened them and putted the source code file. Them committed it. Later on linux after pull them, I try to run the make file, which complaints strange stuff. Them I go to se the file, I see their extension is good. However I never got to open them with anything on linux. I just notice they open fine on windows. Then I go to see their property on linux file manager, and it shows that crazy image on the main post. – user Aug 27 '16 at 12:47
0

The solution is as the file is versioned, firstly delete it and commit the deletion. Secondly create a new file and copy its correct contents from the version system without cloning it. For example, by an web browser as GitHub allows it, them commit them.

It will remove them from the versioning system. It is due, the git status command cannot tell the difference from the symlink to the source code file. Them if you just fix it, the git status command will cannot show the between them. So, you fist need to commit the deletion, them latter to correct add of them within another commit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.