Community
Participate
Working Groups
Hi, I store my files on a samba drive (as I need to build it remotely for the actual program), but use Eclipse to build locally and for CVS. If I change a file on the target file system, I get an out of sync error that refreshing doesn't fix. I have to open it in eclipse explicitly. However, I also get this for various CVS/Entries files. Refreshing doesn't help, and I have to check out the file system again in Eclipse to get it to work again. This also occurs in 2.0.2 - but I am mostly using 2.1M3
This bug may be related to 16820. Assigning for further assessment.
are you sure the bug # is right? 16820 looks quite unrelated. As an aside, I found that if I CVS update on my local machine on the samba drive Eclipse stops complaining. This makes sense. Seems a problem with the timestamps - but shouldn't be. Both machines (my Linux box and the Solaris box in question) are sync'd off the same NTP server.
any progress on this? unfortunately in our environment it makes Eclipse's CVS unusable. I understand if it is not a priority though.
Rafael, please investigate. Kevin, have you seen any Team vs Samba related problems like this before? Thanks.
Brett, could you confirm your client is Linux? And which OS is Samba running on? Thanks.
Sorry, just noticed comment 2 mentions you use Linux and Solaris, so probably you run Eclipse on Linux and the samba server runs on Solaris.
that's right - when I get back to work I'll try it out with Samba server on Linux as well.
Brett, have you been able to try it on a Linux Samba server? Thanks.
yes, I just tried it now. Same problem unfortunately. My time: 08:33:21 Linux Samba server: 08:32:23 Solaris samba server: 08:32:19 I'm not sure why my PC continuously drifts into the future, but I guess that could be the source of the problem. I have to get the NTP syncing happening at the same time as the other machines. This doesn't only affect CVS, but a range of other things like searching, refactoring - although a standard refresh will get them back in sync. The standard refresh doesn't work with CVS though - I guess it doesn't tough the CVS files since its controlling them differently? Thanks.
Sorry for taking so long to answer... and it looks like I didn't understand your configuration (because I cannot reproduce it). Tell me what is wrong: You have Eclipse installed locally, and your workspace is local as well. You keep your project files in a remote drive, mounted via samba. You keep your project files in a CVS repository in a third machine, using Eclipse (not an external CVS tool). If (and oly if) you change a file inside the project content area in the samba mounted file system using an external program, Eclipse says it is out-of-sync (makes sense), but refreshing does not synchronize it (bug). What am I missing?
no problem about the timing - I just have to use external CVS tools unfortunately. Would be nice to fix it though - I like the eclipse support. > You have Eclipse installed locally, and your workspace is local as well. correct > You keep your project files in a remote drive, mounted via samba. correct. > You keep your project files in a CVS repository in a third machine, using > Eclipse (not an external CVS tool). I sometimes check out, update and commit files using external tools (cvs command line on remote machine). I think this is the source of the problem. > If (and oly if) you change a file inside the project content area in the samba > mounted file system using an external program, Eclipse says it is out-of-sync > (makes sense), but refreshing does not synchronize it (bug). It is only if I modify CVS/ directory files. To get it working again, I run "cvs -q update -Pd" from the command line locally. This makes me think it is timestamps in CVS/ that cause the problem. Most likely the refresh doesn't try to refresh from those files, but sync requires them refreshed? Thanks.
*** This bug has been marked as a duplicate of 16280 ***
bug 16280 has been closed since it depends on IBM fixing Clearcase. Since this bug has nothing to do with Clearcase it doesn't seem appropriate to resolve it as a duplicate.
See the update on <a href="https://bugs.eclipse.org/bugs/show_bug.cgi? id=16280">bug 16280</a>. This turns out to be bug in Samba.
