Remaining issues

[Bernd Gehrmann]

On Tue, 10 Jul 2001, Matthias Hoelzer-Kluepfel wrote:
> 
> Ah, that was one thing I would liked to have talked to you in Stuttgart, but 
> obviously, I forgot. What is the exact reason for using the inode instead of 
> the URL? And does it work via, e.g., NFS correctly?

Take the following example:

  cd 
  mkdir -p foo/bar
  ln -s foo/bar headers
  <create foo/bar/header.h>
  
Now take a project that uses '-I$HOME/headers' for setting
the include directory. Load header.h in the editor and compile
something. Now, if there is an error in header.h, the following
happens:

a) When you loaded header.h into the editor, it will be known
   (depending on how you used the file dialog) as 
   $HOME/foo/bar/header.h 

b) gcc will report the error in a file called
   $HOME/headers/header.h

=> by comparing file names, you now have two independent editor 
buffers which edit the same file.

We had lots of bug reports about something like this for the
1.0beta releases. I'm not sure if the above example is the
real use case for it, but here you can see how it may happen.
Also, in our, ehem, Ultrix cluster in Muenster we frequently
had file names over NFS reported as /tmp_mnt/home/something when
they were used as /home/something elsewhere. I don't know
when this happens - somehow it doesn't happen in our NFS system
here - but it is something that has to be considered. 

In KDevelop 1.x, I introduced some kind of canonicalizing file
names which seems to work pretty reliably, but it can't really
detect all possible problems. Emacs for example even detects
files to be equivalent if one is a symbolic link on the other
one. I'm quite sure that using devno and inode solves this 
problem. You could quickly test this by creating a symbolic link 
for a file and then loading both into the editor.

Bernd.


-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«