New (Feb 20 2003), tclvfs now contains a nice debugging feature for those writing tclvfs implementations:
vfs::filesystem internalerror report
proc report {} { puts stderr $::errorInfo }will do wonders! Tcl implementations are now not allowed to throw Tcl errors, only Tcl ok or posix errors.
Notice that you need to Mount non-native filesystems before you can use them. There are two kinds of mounts that tclvfs supports. The first kind is a particular mount point such as an archive 'foo.zip' or 'ftp://ftp.scriptics/com/pub ' which can be mapped onto any point in the local filesystem. The contents of those mounts (i.e. the contents of the zip archive or the contents of the remote ftp site) are then accessible as normal, local files.
LV When using a Starkit, one accesses files within the starkit via TclVFS. Please list here some of the differences one will see when accessing files via TclVFS rather than accessing them via a normal file system.
For instance, file ownership and permissions are not supported within many (most? all?) the VFS modules.
A user reports on comp.lang.tcl that when accessing files via VFS on Windows, the file names are case sensitive.
Vince adds that each filesystem module can choose whether to be case-sensitive or not. Most are, I believe, implemented in a case sensitive fashion. I'd be interested to know how, say vfs::ftp works when the relevant ftp site is running on a windows server (not case sensitive)...
In a recent web search I noticed some misinformation about 'load foo.dll' not working inside a .zip, and how it can't possibly work and is impossible and .... Tclvfs is designed to allow this to work just fine, and will transparently copy the .dll to the native temporary directory and load it there (and arrange for it to be deleted on exit). If any of this doesn't work it is a bug and should be reported!
"... a remark by Jean Claude, Steve Landers and perhaps someone else discussing the fact that shared libraries had to be written out to a real file system before many OSes would dynamically load the library." -- Indeed that is true, and Tcl's core provides transparent support for a copy-to-temp-then-load behaviour as default. It would be nice to be able to load directly, and this is discussed here: loading from memory.
Matthias Hoffmann: The above mentioned automatic copy-to-temp-then-load-feature isn't working always with tclkit-win32(-sh).exe: if launched from within the command.com-Shell (not cmd.exe!), the temp-folder is defined as c:/winnt/temp, which could not be accessed (permission denied) with user privilegs (of course, the temp-folder has to be user specific in a multi user environment). But maybe this phenomen is unique to our server-farm...