From: SourceForge.net <no...@so...> - 2004-11-25 00:52:16
|
Bugs item #1072136, was opened at 2004-11-23 16:51 Message generated for change (Settings changed) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1072136&group_id=10894 Category: None Group: current: 8.4.8 Status: Open Resolution: Invalid >Priority: 9 Submitted By: Colin McDonald (cjmcdonald) Assigned to: Don Porter (dgp) Summary: change to tcl_findLibrary breaks freewrap Initial Comment: A recent change to tcl_findLibrary in auto.tcl, released in Tcl 8.4.8, breaks freewrap. For all platforms freewrap stores its Tcl & Tk library files in a zip based virtual filesystem, under directories named /tcl & /tk. These directories are pointed to by the TCL_LIBRARY & TK_LIBRARY environment variables set in the application initialisation. The recent change to tcl_findLibrary introduced use of file normalize in the section "# uniqify $dirs in order". Unfortunately under Windows, file normalize changes the /tk directory path by treating it as a volume relative name, and applying the default device name e.g to become D:/tk. The result of this is that Tk fails to find its library files and freewrap doesn't initialise. Note that freewrap is not using the modern tcl virtual file system api. Instead it is using the old TclPro hooks, which may explain why file normalize manipulates /tk as a Windows path. Removing the file normalize fixes the problem. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2004-11-24 19:46 Message: Logged In: YES user_id=80530 A serious bug (or two?) escaped in Tcl 8.4.8, so there will be a Tcl 8.4.9 pretty soon. Would it help buy freewrap some bug fixing time if line 133 of auto.tcl were changed from lappend uniqdirs $norm to lappend uniqdirs $i That way, [tcl_findLibrary] would only unquify its search list, and not also normalize its entries. There's still a real bug in freewrap if it can't work compatibility with [file normalize], and it should be fixed, but if this change helps keep freewrap functioning in the Tcl 8.4 series, I'm willing to make it. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2004-11-24 10:15 Message: Logged In: YES user_id=80530 ok, so appears this is really a problem in freewrap, and should be fixed there. Incompatibilities with [file normalize] likely go much deeper than [tcl_findLibrary]. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-11-24 08:16 Message: Logged In: YES user_id=32170 Ok, so freewrap depends on being able to intercept a particular string representation of a file ('/tcl'), and as such init.tcl's new approach of converting that string representation into a real path (by normalization) means that freewrap can no longer intercept what it wants. The root of the problem is that freewrap is trying to intercept a path which (on Windows) is not fixed -- the real interpretation of '/tcl' changes depending on the current working directory. So, anyway, it's not a filesystem bug. ---------------------------------------------------------------------- Comment By: Colin McDonald (cjmcdonald) Date: 2004-11-24 07:53 Message: Logged In: YES user_id=883691 My concern with this problem is that moving from 8.4.7 to 8.4.8 in the stable 8.4.* release series breaks freewrap, a deployment tool which is used by many people. Undoing the change in tcl_findLibrary does actually workaround the problem. Access to files in the freewrap zip file system is expected to be pretty simple i.e. read only, no writing, no globbing and no file normalize (which did not even exist when the TclPro hooks were developed). It is not a full-blown virtual file system in the (excellent) sense of your modern interfaces. The change to tcl_findLibrary introduces a dependency on file normalize for successful access to the tk_library files. As it does not behave as expected for the freewrap /tk files then freewrap breaks. I think it is a bit unfair to say that freewrap is dependant on buggy behaviour in Tcl - it is dependant on the expected behaviour and use of the TclPro hooks as they were originally implemented. I can see that your suggestion of freewrap:/ may work - but would intoduce platform dependant code into freewrap, with different mount points for Unix & Windows. I will notify the freewrap author, Dennis LaBelle of this problem and discussion. Hopefully he will comment. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-11-24 05:13 Message: Logged In: YES user_id=32170 Under Windows paths starting with '/' are _defined_ to be volume relative, therefore Tcl's behaviour is correct. Now it could be there's some bug you have found (certainly a number of volume-relative bugs have existed in Tcl and many have been fixed in the last 12 months). However, the more general point is that freewrap's use of '/tcl' and '/tk' is not correct, and should not have worked in the past -- i.e. freewrap relied on Tcl not having correct handling of volume relative paths, it seems. A possible resolution is for freewrap to claim those paths as absolute by mounting a new volume, like this: vfs::filesystem mount -volume /tcl "#not sure what goes here" (but I see you're not using modern Tcl interfaces). Then Tcl will not treat that path as volume relative (but I would be quite wary of this approach, since it is in some sense fundamentally incompatible with the WinTcl filesystem). Better would be to mount a new filesystem: freewrap:/ with 'tcl' and 'tk' as subdirectories. In summary: * freewrap's use of '/tcl' is relying on bugs in old versions of Tcl * many volume relative bugs have been fixed, it is possible there are more, but Tcl's treatment of '/tcl' as volume relative is correct. Question: does undoing the change in tcl_findLibrary actually workaround the problem? (If so, there is a bug in Tcl still, in its usage of the old char-based TclPro hooks, if not, then it just shows that volume relative paths are now treated correctly). I hope that helps. Do feel free to file bugs in Tcl's volume-relative file treatment, if any still exist, but beyond that this seems to be a freewrap problem, really. So, don't know what to suggest, except that I don't see us making any filesystem changes to accomodate this behaviour. Probably using 'freewrap:/' is the best bet. Vince. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2004-11-23 17:01 Message: Logged In: YES user_id=80530 sounds like filesystem problems to me. if $path and [file normalize $path] do not point to the same file, then something in the filesystem support code is broken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1072136&group_id=10894 |