|Title:||fileutil::find does not return symlinks|
|Submitter:||coldstore||Created on:||2007-10-18 03:27:51|
|Status:||Open||Last Modified:||2007-10-23 02:44:24|
tcllib 1.9 Running find over a directory containing symlinks does not return any reference to or mention of the symlinked names. I'm not sure whether that's intentional or not, but in looking at the source I see nothing which seems designed to cause this behaviour, so think it's a bug.
andreas_kupries added on 2007-10-23 02:44:24:
Logged In: YES user_id=75003 Originator: NO OTOH, it should be possible to ask for '-types l' and then filter out those which are file/dir and thus not dangling, leaving us with dangling symlinks we can add to the result. We have 'file type' for an easy check. I think I will add a testcase first, if we don't have it already.
andreas_kupries added on 2007-10-22 23:30:21:
Logged In: YES user_id=75003 Originator: NO right. doc update is easy.
coldstore added on 2007-10-20 07:45:37:
Logged In: YES user_id=19214 Originator: YES On further reflection, it's clear that [glob -type XXX] can't return a broken symlink no matter what XXX is, unless it's 'l' for link, because after all it can't determine the type of a loose link. It may be worth noting in the docs that such links won't be returned by find.
coldstore added on 2007-10-20 07:43:03:
Logged In: YES user_id=19214 Originator: YES Further analysis shows that the [glob] used in GLOBF and GLOBD for tcl8.5 doesn't return a reference to a symlink which has a non-existent target. Thus, it's impossible to use fileutil::find to locate and resolve such symlinks (which is what I was trying to do :) I'm not sure if this is a bug or not, anymore. It's unexpected though.
andreas_kupries added on 2007-10-18 22:56:03:
Logged In: YES user_id=75003 Originator: NO Tcllib 1.9 ... Can you try Tcllib 1.10, or even the CVS head, fileutil 1.13.3 ? If the problem is still there please attach a script which creates a directory hierarchy which with it is possible to demo the problem. The traverser has code to avoid following circular symlinks, however the symlinks themselves should appear in the output. Note that we also have 'fileutil::traverse' which might be different, or not. It would be interesting to know, for comparison.