User forums > Nightly builds
The 05 February 2008 build (4861) is out.
mandrav:
--- Quote from: cacb on February 06, 2008, 10:18:50 am ---I am using C::B on Windows and Linux Kubuntu i386. On Linux, there is a serious C::B problem that isn't seen on Windows: Sometimes, typically when you are debugging or reviewing build errors, you can end up with two views of the same file. If you edit one, the other becomes out of date. This is extremely confusing as you often end up compiling something else than what you have recently edited.
Is this a known problem?
--- End quote ---
I 've seen this before and it had to do with symlinks. Let me explain.
I had my project, say, in ~/projects/frm/tests/unit/des. Now, for convenience, I had that directory symlinked to ~/projects/frm/des_test.
So, I opened the project file from inside the symlink (~/projects/frm/des_test/something.cbp). Then I started debugging. When I landed in a file of that project, the debugger opened the file from its real path (~/projects/frm/tests/unit/des/somefile.cpp).
The result was that the same file was open twice from two different locations.
Is this the same as what you 're describing? If so, the only work-around is to open the project file from its real path... Ideas/patches to properly fix this are welcomed :)
indigo0086:
Hey, the parser's working...
I'm scared
cacb:
--- Quote from: mandrav on February 06, 2008, 11:24:05 am ---I 've seen this before and it had to do with symlinks. Let me explain.
I had my project, say, in ~/projects/frm/tests/unit/des. Now, for convenience, I had that directory symlinked to ~/projects/frm/des_test.
So, I opened the project file from inside the symlink (~/projects/frm/des_test/something.cbp). Then I started debugging. When I landed in a file of that project, the debugger opened the file from its real path (~/projects/frm/tests/unit/des/somefile.cpp).
The result was that the same file was open twice from two different locations.
Is this the same as what you 're describing? If so, the only work-around is to open the project file from its real path... Ideas/patches to properly fix this are welcomed :)
--- End quote ---
You may be right... The "hard" path to my project is /media/sda6/wxDev/proj... but I normally access it via ~/work/wxDev/proj... as work is pointing to /media/sda6 (I have a dual boot win/linux setup and "work" is the common name for this partition on both systems, using a disk label on Win and a symlink on Linux). I have not noticed the paths associated with the different files, I shall certainly check when the problem occurs again. It will for sure, this happens all the time. It looks like the same problem.
How about stripping the path from such files and compare the names? Or maybe it is possible to check the path for symlinks?
It is certainly an annoying thing, and not easy to understand. I might try to access it using the "hard" path and see if that helps, but I suspect this will affect a few of users.
JGM:
--- Quote from: indigo0086 on February 06, 2008, 06:23:32 pm ---Hey, the parser's working...
I'm scared
--- End quote ---
what do you mean?
Jenna:
--- Quote from: cacb on February 06, 2008, 06:49:12 pm ---You may be right... The "hard" path to my project is /media/sda6/wxDev/proj... but I normally access it via ~/work/wxDev/proj... as work is pointing to /media/sda6 (I have a dual boot win/linux setup and "work" is the common name for this partition on both systems, using a disk label on Win and a symlink on Linux). I have not noticed the paths associated with the different files, I shall certainly check when the problem occurs again. It will for sure, this happens all the time. It looks like the same problem.
How about stripping the path from such files and compare the names? Or maybe it is possible to check the path for symlinks?
It is certainly an annoying thing, and not easy to understand. I might try to access it using the "hard" path and see if that helps, but I suspect this will affect a few of users.
--- End quote ---
If your kernel is newer then 2.4.0 you can use mount instead of ln.
I just tested it on my debian-system and it works.
Here is a part of the mount manual:
--- Code: --- Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is
mount --bind olddir newdir
After this call the same contents is accessible in two places. One can also remount a single file (on a single file).
This call attaches only (part of) a single filesystem, not possible submounts. The entire file hierarchy including submounts is attached a second place
using
mount --rbind olddir newdir
Note that the filesystem mount options will remain the same as those on the original mount point, and cannot be changed by passing the -o option along with
--bind/--rbind.
--- End code ---
If you are a normal user, you might need to use
--- Code: ---sudo mount --bind olddir newdir
--- End code ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version