[Ecls-list] ecl bug - following symlinks
timothy
tschaef at sbcglobal.net
Mon Jun 26 15:54:49 UTC 2006
Saluete, etc.,
I found a bug in cl_truename in getting the target of symlinks.
When a symlink is relative, si_readlink gets that relative symlink and
replaces filename with it below, changing an absolute name into a
relative one (the symlinks start with ../). Then at the bottom, we go
back to BEGIN, the file name
/usr/share/common-lisp/systems/iterate.asd ->
../sources/iterate/iterate.asd
becomes $PWD/../sources/iterate/iterate.asd, which doesn't exist, and
file_kind() fails.
...
The following seems to solve the problem:
*** orig/ecl-0.9h/src/c/unixfsys.d 2005-11-16 05:13:20.000000000
-0500
--- ecl-0.9h/src/c/unixfsys.d 2006-06-17 11:22:42.925321093 -0400
***************
*** 188,194 ****
--- 188,201 ----
FEcannot_open(orig_pathname);
#ifdef HAVE_LSTAT
} else if (kind == @':link') {
+ cl_object sourcename = filename;
filename = si_readlink(filename);
+ filename =
+ cl_merge_pathnames
+ (2, filename,
+ make_pathname(Cnil, Cnil,
+ cl_pathname_directory(1,sourcename),
+ Cnil, Cnil, Cnil));
#endif
} else {
filename = OBJNULL;
As you can see, I'm working from version 0.9h, not CVS, but I looked at
the CVS version and the context is the same.
Does this patch seem reasonable? It works for me so far, but pathnames
are still new to me. Does anyone know of any situation where it may not
work?
Tim S.
More information about the ecl-devel
mailing list