Re: "glob -types d" inside starpack ...
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


comp.lang.tcl archive

Re: "glob -types d" inside starpack ...

From: Don Porter <dgp@email.nist.gov>
Date: Wed Feb 15 2006 - 17:42:11 CET

MartinLemburg@UGS wrote:
>> First I fetch all the files inside a directory, then I fetch the
>> directories inside the current directory to go deeper.
>> If the given directory is the directory my starpack runs in, than ...

... as I recall, Martin's complaint was that after mounting, the
starpack "file" was reported exclusively as a directory, even though
he knows it's really a file in the native filesystem.

This is a fundamental "feature" of the Tcl_Filesystem interface,
that each path can belong to only one filesystem. Once mounting
makes the path a directory in the vfs, it can no longer be also
a file in the native fs. See Tcl Bug 941872 for lots of discussion
of the implications, and observations that mounting "in place" the
way mkfs does may not be the best choice.

In article <43F35617.8000502@activestate.com>, Jeff Hobbs wrote:
> There is a general VFS issue with -types specifications not being
> propagated down to tclvfs-level drivers. This of course affects
> the mk4-based starpacks.

That sounds like a bug in the tclvfs package to me, rather than a defect
in the Tcl_Filesystem interface ("general VFS issue"). The
Tcl_FSMatchInDirectoryProc driver interface passes in a
(Tcl_GlobTypeData *) argument that seems to work just fine.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| donald.porter@nist.gov             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|
Received on Sun Apr 30 02:07:01 2006