Tcl Source Code

Patch doesn't yet contain documentation for the new C 
API.  Tcl level docs are all there.

Logged In: YES 
user_id=32170

This patch has (since July 31st 2001) been incorporated 
into the cvs repository.  Here is a reminder that:

I've placed an implementation of a 'vfs' extension which 
exposes the current vfs API to Tcl at:

ftp://ftp.ucsd.edu/pub/alpha/tcl/vfs.zip

It includes a zip vfs (read-only), and a variety of other 
partially implemented vfs's.  It's pre-alpha software, but 
might be of interest to those testing this patch -- Vince

File Added - 8920: fileName+.test

Logged In: YES 
user_id=32170

Adding the tests which should be included in fileName.test 
(following on from test 11.35) to exercise the code for the 
new '-tails' flag.

Logged In: NO 

Have taken a look at Daniel's 'mac-aware' patch and the 
small differences it made to the generic code.  These all 
seem fine to me. -- Vince.  I think we are now at a stage 
where we can apply this patch to the cvs tree.

File Added - 7698: tip17-tip17mac.diff

Logged In: YES 
user_id=90580

attached diff from a tree with tip17.patch applied to one 
with tip17-mac.patch applied

File Added - 7697: tip17-mac.patch.gz

Logged In: YES 
user_id=90580

attached tip17-mac.patch.gz with my changes for the mac, an 
incremental diff from a tree with tip17.patch already applied 
is also available in tip17-tip17mac.diff

I had to make modifications in some platform independent code 
and some tests, so relevant maintainers should probably have 
another look at the code to see if they are happy with my 
changes. I would also be grateful for review of the new mac 
specific bits.

Some notes on the changes:

- numerous separator related issues had to be fixed.

- error messages have changed due to the way filenames are 
built up now, namely by joining path components together 
starting with an empty string. On the mac joining with {} 
adds (correctly) a ':' at the start of the path, this results 
in e.g. 'open non_existent' to return 'couldn't open 
":non_existent": no such file or directory'. A number of 
tests as well as tclTest.c had to be changed to account for 
this.

- added unix style relative path compatibility mode to 
TclpMatchInDirectory, if a directory is not-found this checks 
for a relative path of the same name and uses that if it 
exists, this allows for e.g. 'glob -directory some_subdir *' 
to work instead of the correct 'glob -directory :some_subdir 
*' (or better 'glob -directory [ file join {} some_subdir ] *
' ) this change allows a large number of tests to newly pass 
and should be backwards compatible as it acts as a fallback 
only

- TclpObjNormalizePath() mac implementation patterned along 
the lines of FSpLocationFromPath(). This is new, please 
review.

- most time related changes have more to do with a bug in mac 
tcl than with tip17, I discovered that metrowerk's MSL 
library uses the unix time epoch internally and moved mac tcl 
to that epoch now (many clock.test newly pass with this), if 
this is felt to be too radical a change, the problem can be 
gotten around in other ways.

- CodeWarrior needed prototypes for the new TclpObj* procs 
introduced in tcl*FCmd.c, I have added them to tclInt.h, 
maybe there is a better place (e.g. in tcl*FCmd.c)? Is there 
a reason they weren't added in a global header originally?

Logged In: YES 
user_id=99768

I approve the effect of this implementation
on the 'dde' and 'registry' packages.

There's an unrelated bug that I'm reluctant
to fix until these changes are committed,
because I'm not sure how forgiving cvs is
about nearby changes.

The file 'tests/winDDE.test' announces that it is
skipping registry tests when it should announce
that it's skipping DDE tests.  If Vince could
correct that (it's two lines after each of his two
changes), I'd appreciate it.

File Added - 7283: FileSystem.3

File Deleted - 6085:

File Added - 7282: tip17.patch.gz

Logged In: YES 
user_id=80530

Updated the patch to apply clean to the 2001-Jun-12 HEAD.

This mostly involved updating the Stub numbers in
generic/tcl.decls to account for those numbers consumed
by other TIPs in the meanwhile.

File Deleted - 6086:

Logged In: YES 
user_id=75003

I completed my review of the implementation of TIP #17 and
can give it a go. The biggest thing I saw were the missing
tests for the new "-tails" option to [glob], and Vince said
that he would do them immediately after coming back from the
2nd part of his honeymoon, so I see no problem here too.

Logged In: YES 
user_id=72656

I approve this patch for all related areas that I 
maintain.  I had initially worried about 64-bit access, but 
only on Windows does stat64 return an int64 (for whatever 
reasons, it isn't clear).  Otherwise these are still 
abstracted into the stat structure itself.

I think it would be nice to have Vince's vfs stuff added in 
part to the testing code, for consideration for future 
inclusion in the core (like JAR support), as was done with 
the iogt work to test channels.

Logged In: NO 

I've placed an implementation of a 'vfs' extension which 
exposes the current vfs API to Tcl at:

ftp://ftp.ucsd.edu/pub/alpha/tcl/vfs.zip

It includes a zip vfs (read-only), and a variety of other 
partially implemented vfs's.  It's pre-alpha software, but 
might be of interest to those testing this patch -- Vince.

File Deleted - 6132:

File Added - 6342: FileSystem.3

Logged In: YES 
user_id=32170

Clarified a few pieces of the documentation.

File Added - 6341: tip17-3.patch.gz

Logged In: YES 
user_id=32170

Uploaded tip17-3.patch.gz which fixes two minor problems, 
and improves a few comments here and there.  The problems 
fixed were: (i) 'glob *' defaulted to the native filesystem 
instead of using the filesystem of the current cwd, (ii) if 
there are no file attributes, a file attributes read 
operation could segfault (accessing a null Tcl_Obj).  Both 
of these problems obviously don't affect Tcl's native 
filesystem itself, but lead to bugs in the Tcl-only zip vfs 
I'm experimenting with (requires vfs, memchan and Trf 
extensions).

File Added - 6133: FileSystem.3

Logged In: YES 
user_id=32170

Documentation updated with Tcl_FSRegister etc.

File Added - 6132: tip17-2.patch.gz

Logged In: YES 
user_id=32170

Uploaded patch with modifications in message below 
(Tcl_FSRegister is public, split long lines, etc).  Also 
have simplified the Tcl_FSMatchInDirectory logic so there 
is no need for the 'dirOnly' flag.  Re-ran test suite on 
Windows and Unix to ensure no problems.  Updated 
FileSystem.3 to remove the 'dirOnly' flag and add 
documentation of Tcl_FSRegister.

Logged In: YES 
user_id=32170

Since the Tcl_Filesystem structure is now public, I've also 
decided to rename TclRegisterFilesystem to Tcl_FSRegister 
(and similarly Tcl_FSUnregister and Tcl_FSData) and place 
them in the public API.  At some point I'll upload a new 
version with those changes (it's only a cosmetic, not a 
functional change, so it should impact anyone's testing of 
the patch.  I've also noted a few long lines in 
tclFileName.c which will be split).  This allows a 'vfs' 
extension to be written which only uses tcl.h.  I've now 
written just such an extension which exposes perfect vfs 
ability at the Tcl level.  I'll release that as soon as 
this patch is final (if someone wants to help write a 
client of that extension to implement zip or ftp 
filesystems, please contact me!).

Logged In: YES 
user_id=79902

Looking through the changes to generic/tclCmd*.c, I find
that evaluating them will take a little bit of time;
understanding whether object handling is done right can't be
done instantly...

File Deleted - 6075: 



File Added - 6086: FileSystem.3

File Deleted - 6074: 



File Added - 6085: tip17.patch.gz

Logged In: YES 
user_id=80530

Updated patch after a 'make mklinks'.
Updated FileSystem.3 -- a few typos.
Deleted older versions.

APPROVED for "Init - Library - Autoload" and
"Embedding Support" categories.

Thanks for putting up with all my demands, Vince.
I think you've put together a very nice new subsystem.
Hope the other maintainers agree.

File Deleted - 4636: 

Logged In: YES 
user_id=80530

Deleting obsolete files

File Added - 6075: FileSystem.3

Logged In: YES 
user_id=32170

Upload new documentation.

File Added - 6074: tip17f.patch.gz

Logged In: YES 
user_id=32170

I'm uploading a new patch and new documentation which 
address all issues in private email, and put the 
documentation into a pretty complete, final state (except 
perhaps for inadequacies caused by my lack of knowledge of 
nroff).

On the two issues below:

(i) library/init.tcl

This error message is there so that a completely wrapped 
Tcl implementation (e.g. a TclKit including the tcl test 
suite) can pass the test suite.  We could easily add a 
better error message to the code in init.tcl (in fact the 
error message should always be about moving a directory 
into itself, I believe), which would then require changes 
to the test suite, but the equivalent code in tclFCmd.c 
only does a check on 'errno == EINVAL' and then reports 
that error message.  For the sake of compatibility and 
simplicity, I would suggest leaving the code as is at 
present.  We can file a feature request against Tcl that 
init.tcl and tclFCmd.c should be improved to give a better 
error message in these cases.

(ii) TclpVerifyInitialEncodings.

This is actually mentioned in TIP#17.  It is required by 
any attempt to completely wrap up a Tcl installation.  This 
is because in Tcl's init sequence, an attempt is made to 
set up the encodings *very* early, which will fail.  We 
need a way for a tclkit or prowrapped app to set the 
encodings correctly.  I've now re-done this code so that 
rather than adding a new function, the 
TclpSetInitialEncodings can now be called multiple times, 
and is exported in the stub table.  This also avoids 
unnecessary code duplication.

p.s. I also am not getting copies of comments.

p.p.s. It would be good if someone deletes the old patch-
uploads here.  I don't seem to have appropriate permissions.

p.p.p.s.  The patch has Windoze EOLs

Logged In: YES 
user_id=80530

Sent a few more minor code cleanup issues to Vince
via private e-mail.

Now, putting on the maintainer hat...

library/init.tcl:
  Some error messages are "trying to rename a volume
  or move a directory into itself".  Can't we tell the
  difference?  Let's report a particular error, not leave
  the user guessing.
*/*Init.c:
  the TclpVerifyInitialEncodings() is new, but not called
  by anyone.  It's not mentioned in TIP 17.  What's it for?
  How does it help support VFS?

Logged In: YES 
user_id=80530

Although SF claims I am monitoring this patch, I am
NOT getting copies of the comments.  I just happened
to wander by today, wondering why nothing was happening.

Now that I know there are updates, I'll look them over.

File Added - 5919: FileSystem.3

Logged In: YES 
user_id=32170

Adding documentation.

File Added - 5918: tip17e.patch.gz

Logged In: YES 
user_id=32170

Attached another version of the patch, and an improved 
documentation file (now that some stuff has moved from 
tclInt.h to tcl.h, there was more to document).

The new patch basically address some cosmetic issues.  The 
order of items in the filesystem table has been modified to 
make things more logical (the first items are for 
infrastructure, the second items are pretty vital, and the 
third set are less important or optional).  The patch also 
implements some of the fallbacks listed below, since this 
will make writing new filesystems much easier (and less 
error prone), and the additional code is very modest.  None 
of these changes can have any impact on the native 
filesystem at all.

Logged In: YES 
user_id=32170

Along the lines of (ii) below, there is an opportunity to 
add another such fallback:

(iii) Tcl_FSChdir -- if a file system accepts a path, but 
does not implement the chdirProc, we could fallback to 
Tcl_FSStat to check whether the directory exists and has 
appropriate permissions.  Then a filesystem could decide 
not to implement chdir if it so desired.

In general I think it is a good idea to add these 
fallbacks, since they make writing new VFS's simpler, and 
they accord with the pre-existing Tcl filesystem code which 
has many of them already.

Logged In: NO 

I have a couple more comments:

(i) It may be a good idea to re-order the entries in the 
Tcl_Filesystem structure according to a perhaps more 
logical arrangement (or an arrangement in which the entries 
which are least likely to be implemented are at the end).  
I am NOT going to do this myself, since I'm so ingrained in 
the code it's not easy for me to think objectively about 
the different items.  However if someone else wants to take 
a look, please do (the order in tcl.h will only impact 
tclIOUtil.c and tclTest.c).

(ii) I don't know that any non-native FS is really going to 
implement 'Tcl_FSLoadFile' as anything other than 'copy-to-
temp and reload' (and this means they should also implement 
Tcl_FSUnloadFile to unload and cleanup the temp).  Now, 
this is quite similar to the way in which when Tcl sees an 
EXDEV ("unimplemented") posix error message it falls back 
from 'file copy' to open-r/open-w/fcopy/file-mtime.  We 
could therefore make Tcl fallback from load to a core 
implementation of copy-to-temp/reload with appropriate 
cleanup.  For the moment I'm simply raising this issue here 
so it is documented, but in the future we may want to add 
that to Tcl.

cheers, Vince.

File Added - 5889: tip17d.patch.gz

Logged In: YES 
user_id=32170

On the remaing issues:

1) [tcl::CopyDirectory] is called from 
    CopyRenameOneFile() in generic/tclFCmd.c, but
    [tcl::CopyDirectory] will not be available in a safe
    interp.  Will CopyRenameOneFile() ever be called on
    a safe interp?

No, 'file copy' and friends are hidden in safe interpreters.

 2) All the issues of naming conventions and public stubs
    vs. private stubs need to be settled.  My preference:
    make the Tcl_ things public.  Also I'd like the 
    typedefs, etc. around the FileSystem types to follow
    conventions more like those of the Tcl_ChannelType.

I've made changes along the lines you suggest: Tcl_ things 
are public, FileSystem types and structure elements are 
named in a more standard way (like the Channel stuff).  The 
Tcl_Filesystem structure is now more clearly explained in 
tcl.h, including small notes on each element to clarify 
whether it is absolutely required or not.

 3) Several private stub entries are removed by this patch.
    That's OK, but do we know of any affected extensions?

None that I know of.  I did look at some obvious 
contenders.  I would suggest if any problems arise in the 
Tcl 8.4 alpha/beta releases we can add in some backwards 
compatibility support there.

 4) As mentioned before, I think many of the functions in
    generic/tclIOUtil.c could be static now.

I've made a lot of them static (all that I think are 
possible, actually).

 5) In several places, lines exceed 80 columns.  I'm not
    sure if that's an official part of our style guide, but
    I would like them 80 columns or less.

Good point.  I've fixed these now, I think.

The patch I'm uploading (tip17d) includes all the above.  
The changes are mostly to tcl.h, tclInt.h and tclIOUtils.c.

It is a unified diff now (but is still likely to be in 
Windows-eol format).

File Added - 5862: tip17c.patch.gz

Logged In: YES 
user_id=80530

Uploading an updated patch with these changes:

 1) The CONST is removed from Tcl_JoinPath()
    and Tcl_PathType() and any CONST-poison removed.

 2) Line 2594 of generic/tclIOUtil.c used an
    initialization not supported by all compilers.
    Changed to something more portable.

 3) Several new functions were defined with only
    ANSI prototypes.  Changed those to match the
    rest of the Tcl code to support pre-ANSI compilers.

 4) Regenned the patch against HEAD as a unified diff
    (easier to review) and using Unix line endings.

Remaining issues:

 1) [tcl::CopyDirectory] is called from 
    CopyRenameOneFile() in generic/tclFCmd.c, but
    [tcl::CopyDirectory] will not be available in a safe
    interp.  Will CopyRenameOneFile() ever be called on
    a safe interp?

 2) All the issues of naming conventions and public stubs
    vs. private stubs need to be settled.  My preference:
    make the Tcl_ things public.  Also I'd like the 
    typedefs, etc. around the FileSystem types to follow
    conventions more like those of the Tcl_ChannelType.

 3) Several private stub entries are removed by this patch.
    That's OK, but do we know of any affected extensions?

 4) As mentioned before, I think many of the functions in
    generic/tclIOUtil.c could be static now.

 5) In several places, lines exceed 80 columns.  I'm not
    sure if that's an official part of our style guide, but
    I would like them 80 columns or less.

Logged In: NO 

We can certainly remove those added CONSTs and move them to 
TIP27.  They are not important to the functioning of this 
patch -- Vince.

Logged In: YES 
user_id=80530

The CONST added to the prototype of Tcl_JoinPath
hasn't been completely traced through all the its
callers.  I've started the task and it grows quickly.

Can we remove the added CONSTs to Tcl_JoinPath
and Tcl_PathType in this patch, and make their addition
part of the TIP 27 effort?  They aren't crucial to the
functioning of this patch are they?

File Added - 5767: tip17b.patch.gz

Logged In: YES 
user_id=32170

The attached patch, after some helpful explanation by 
Brent, now seems to work in a threaded environment.  The 
new file is tip17b.patch (which still requires the separate 
new documentation file).

I think we are now extremely close to a final patch.

Logged In: YES 
user_id=32170

I've now tried debugging this last 'thread' issue, but my 
distinct lack of knowledge of how mutexes and threads work 
(more than the most trivial details) has left me somewhat 
lost.  Anyone care to help?

Logged In: YES 
user_id=32170

Having looked at the main code changes, I can't see 
anything obvious that should break the threaded version
(tclIOUtil.c is the most obvious place where this might 
happen, since it contains lots of 'mutex' calls).  
Unfortunately, I'm not at all expert with threads, so I may 
well be missing something.  Will continue to look, but if 
anyone wants to help??

File Added - 4889: tip17.patch.gz

File Deleted - 4665: 

Logged In: YES 
user_id=80530

Updated the patch to include the [file exists ""] fixes,
and the be generated against latest CVS HEAD.

Problem: Result doesn't seem to work at all with
--enable-threads.

Logged In: YES 
user_id=80530

Note that Patch 403532 has been committed to CVS HEAD,
so that issue is resolved.  Another patch should still
offer the rewritten TclInExit().

Logged In: NO 

Note: surprisingly, none of Tcl's test suite caught 
the 'file exists "" == 1' bug fixed below.  We should 
probably add a test for it.  Something like this:

test cmdAH-5.4 {Tcl_FileObjCmd} {
    list [catch {file exists ""} msg] $msg
} {0 0}

Logged In: YES 
user_id=32170

I've found one little problem with the current patch, after 
extensive testing.  'file exists ""' returns 1!!  This is 
due to the new code considering "" to be a relative path in 
the cwd.  The fix is simply to change tclIOUtil.c line 2766 
to:

if ((path[0] != '\0') && (Tcl_GetPathType(path) == 
TCL_PATH_RELATIVE)) {

then the new code has the same behaviour as the old.

Logged In: YES 
user_id=32170

All of Donald's changes look very good to me.  Only one 
bears a little bit of thought --- the 'TclInExit()' fix 
which has been removed.

TclInExit() is basically broken in current Tcl, in that it 
usually returns 0 when we are in fact in the exit sequence. 
The changes made simply fix that, and were 'required' by 
TclKit so that it can properly clean up under all 
circumstances without causing new actions to be triggered.  
I say 'required', because there may actually be an 
alternative solution TclKit can use, which is why I don't 
feel too strongly about this.  If we remove that fix, we 
should make sure we file a bug report against TclInExit(), 
since it is clearly buggy as it stands.

File Deleted - 4635: 



File Added - 4665: tip17.patch.gz

Logged In: YES 
user_id=80530

tip17.patch.gz is an updated patch.  Changes include:
1) Removed unused StatProc typedef in generic/tclCmdAH.c
2) Fixed bug in line 749 (TclpObjReadLink) of
   unix/tclUnixFile.c
3) Removed some CONST-casting of args to Tcl_JoinPath().
4) The TIP 17 patch included Patch 403532 and a rewrite of
   TclInExit().  Unless there is some dependence, these
   patches should be considered, approved, and integrated
   separately.  I've removed those changes from
   tip17.patch.  The test suite still succeeds.
5) Renamed [tcl::copyDirectory] to [tcl::CopyDirectory] to
   indicate it is an internal command not for public use.
6) Removed the changes to win/makefile.vc that appear to be
   temporarily present just to support debugging.
7) Regenned the patch for generic/tclInt.decls, taking care
   to use consistent EOL conventions to get a clean patch.

The patch still does not include the separate file
doc/FileSystem.3.  It will have to be added separately.
Also, it looks like some of the new routines use ANSI
prototypes.  If we're going to continue to support ancient
pre-ANSI compilers, they'll need some modifying.

Still to consider: many of the Tclp*() functions that make
up the native filesystem and are defined and used only in
generic/tclIOUtil.c could and probably should be file static
functions.  In that case their names should not begin with
"Tcl".  There may be some other strangeness going on with
the naming conventions (function pointer typedefs ending in
"_" ?).

File Deleted - 4395: 

Logged In: YES 
user_id=80530

Deleted out of date files

File Added - 4636: FileSystem.3

Logged In: YES 
user_id=32170

Updated FileSystem.3 file

File Added - 4635: tclobjvfs3.diff.gz

Logged In: YES 
user_id=32170

Latest patch.  Now there are no known bugs in it.

Logged In: NO 

The newest patch ('3') fixes the segfaults using the agreed 
on Preserve/Release scheme and fixes the bug on Solaris.  
It also contains updated documentation in which the 'older' 
Access/Stat/Open man pages contain links to the newer 
FileSystem page --- Vince.   I'll upload the patch now.

Logged In: YES 
user_id=80530

Problem appears to be line 849 of the patched
generic/tclIO.c .  It attempts to write to statePtr->flags
after returning from Tcl_Close(), which may have freed
statePtr.

Either rewrite Tcl_UnregisterChannel to avoid this, or
use Tcl_Preserve to prevent a free() until statePtr is
no longer needed.

Logged In: YES 
user_id=80530

Here's one test case on one of my old Linux boxes.  I see
similar problems with newer installations.

$ uname -a
Linux rhea 2.0.35 #1 Tue Jul 14 23:56:39 EDT 1998 i686
unknown
$ cd tcl/unix
$ ./configure --disable-shared --enable-symbols
...
$ make
...
$ gdb ./tclsh
...
(gdb) run
Starting program: /home/dgporter/cvs/tcl/unix/./tclsh 
% set a 1

Program received signal SIGSEGV, Segmentation fault.
chunk_alloc (ar_ptr=0x400bebd0, nb=136) at malloc.c:2622
malloc.c:2622: No such file or directory.
(gdb) bt
#0  chunk_alloc (ar_ptr=0x400bebd0, nb=136) at malloc.c:2622
#1  0x40069fa5 in __libc_malloc (bytes=130) at malloc.c:2566
#2  0x80dc001 in TclpAlloc (nbytes=130) at
./../generic/tclAlloc.c:671
#3  0x806cddc in Tcl_Alloc (size=130) at
./../generic/tclCkalloc.c:983
#4  0x805ad76 in Tcl_NewStringObj (
    bytes=0x810e7ea "\n    variable history\n    if {![info
exists history]} {\n\tarray set history {\n\t   
nextid\t0\n\t    keep\t20\n\t    oldest\t-20\n\t}\n   
}\n}\n\n# history --\n#\n#\tThis is the main history
command.  See the man page"..., length=129) at
./../generic/tclStringObj.c:208
#5  0x8056f31 in Tcl_EvalTokens (interp=0x80f1a70,
tokenPtr=0xbfffe1b4, 
    count=1) at ./../generic/tclParse.c:1259
#6  0x805717d in Tcl_EvalEx (interp=0x80f1a70, 
    script=0x810e5a8 "# history.tcl --\n#\n# Implementation
of the history command.\n#\n# RCS: @(#) $Id: history.tcl,v
1.4 2000/05/15 21:48:44 ericm Exp $\n#\n# Copyright (c) 1997
Sun Microsystems, Inc.\n#\n# See the file \"license"..., 
    numBytes=9002, flags=0) at ./../generic/tclParse.c:1381
#7  0x80b0cad in Tcl_FSEvalFile (interp=0x80f1a70,
fileName=0x8106798)
    at ./../generic/tclIOUtil.c:995
#8  0x8076822 in Tcl_SourceObjCmd (dummy=0x0,
interp=0x80f1a70, objc=2, 
    objv=0x80f9128) at ./../generic/tclCmdMZ.c:886
#9  0x8056929 in EvalObjv (interp=0x80f1a70, objc=2,
objv=0x80f9128, 
    command=0x80dd9aa "", length=0, flags=262144)
    at ./../generic/tclParse.c:932
#10 0x8056aab in Tcl_EvalObjv (interp=0x80f1a70, objc=2,
objv=0x80f9128, 
    flags=262144) at ./../generic/tclParse.c:1019
#11 0x8068d0b in Tcl_EvalObjEx (interp=0x80f1a70,
objPtr=0x81067c8, 
    flags=262144) at ./../generic/tclBasic.c:2679
#12 0x8058d44 in Tcl_UplevelObjCmd (dummy=0x0,
interp=0x80f1a70, objc=1, 
    objv=0x80f340c) at ./../generic/tclProc.c:604
#13 0x808fed6 in TclExecuteByteCode (interp=0x80f1a70,
codePtr=0x80fd3c0)
    at ./../generic/tclExecute.c:874
#14 0x8069012 in Tcl_EvalObjEx (interp=0x80f1a70,
objPtr=0x80fa140, flags=0)
    at ./../generic/tclBasic.c:2837
#15 0x805947f in TclObjInterpProc (clientData=0x80fa3d0,
interp=0x80f1a70, 
    objc=3, objv=0x80f33f8) at ./../generic/tclProc.c:1014
#16 0x808fed6 in TclExecuteByteCode (interp=0x80f1a70,
codePtr=0x80ff8b8)
    at ./../generic/tclExecute.c:874
#17 0x8069012 in Tcl_EvalObjEx (interp=0x80f1a70,
objPtr=0x80fa260, flags=0)
    at ./../generic/tclBasic.c:2837
#18 0x805947f in TclObjInterpProc (clientData=0x80fa688,
interp=0x80f1a70, 
    objc=4, objv=0x80f33e8) at ./../generic/tclProc.c:1014
#19 0x808fed6 in TclExecuteByteCode (interp=0x80f1a70,
codePtr=0x80fc9c8)
    at ./../generic/tclExecute.c:874
#20 0x8069012 in Tcl_EvalObjEx (interp=0x80f1a70,
objPtr=0x80f07f0, 
    flags=131072) at ./../generic/tclBasic.c:2837
#21 0x80a25db in Tcl_RecordAndEvalObj (interp=0x80f1a70,
cmdPtr=0x80fa128, 
    flags=0) at ./../generic/tclHistory.c:133
#22 0x8053bc4 in Tcl_Main (argc=1, argv=0xbffff8f0, 
    appInitProc=0x805353c <Tcl_AppInit>) at
./../generic/tclMain.c:315
#23 0x805352a in main (argc=1, argv=0xbffff8f0) at
./../unix/tclAppInit.c:99

Logged In: NO 

Is there any chance you can find a small test case to 
reproduce a linux segfault?  (Since I can't reproduce any 
of them!).  My first hypothesis is that perhaps the tests 
which segfault are testing invalid paths and that the new 
code is now more stringent about these.  The result could 
be that some system call (access/stat/lstat/chdir/etc..) is 
being passed NULL rather than the old invalid path.  This 
is just a hypothesis, however (and it doesn't quite seem to 
mesh with the 'segfaults only when no TCL_MEM_DEBUG' 
observation).

File Deleted - 4333:

Logged In: YES 
user_id=80530

First, I'm trying my luck removing the obsolete patch...

With the latest patch I still see the same problems with
[file type] on Solaris and Segmentation Violations on
Linux.  The SIGSEGVs show up only when I compile without
TCL_MEM_DEBUG, and I'm using the native malloc(), which is
where the crashes occur.  I'm configuring with
--disable-shared, so there's no problem with a library
mismatch to blame this on.

File Added - 4396: FileSystem.3

Logged In: YES 
user_id=32170

New manpage 'FileSystem.3'.

File Added - 4395: tclobjvfs2.diff.gz

Logged In: YES 
user_id=32170

Tried to remove old patch, but denied, in any case, 
uploaded a new patch (with '2' in the name).  I can't seem 
to get cvs diff -N to add new files to the diff, so I will 
upload the one new file in the next comment.

I was able to reproduce the segfaulting-all-over-the-place 
on linux, but only by some library mismatching, it seemed.  
Various 'make clean/make/make install' removed all the 
segfaults.  I've re-done 'make genstubs' so the stubs 
should be correct.  I hope (but am not sure) this fixes 
the 'file type' problem on Solaris.

Logged In: YES 
user_id=32170

Removed old path

Logged In: NO 

Not sure what the linux problem is; I'm running fine 
there (I've compiled with TCL_MEM_DEBUG, so there 
is some slim chance that could hide a problem, I 
suppose).  If you have any more info/easy-to-reproduce 
problems/fixes/etc, it would help a lot!

I'll re-gen the stubs for the next patch; not sure what 
could've happened there.

Finally on the 'Tcl_' procs in the 'tclInt' interface issue. 
I'm afraid there are lots of other commands sharing that 
status. (e.g. all the Namespace related stuff is still 
inexplicably in the private interface).  I put the API in the 
private interface so that if changes were needed in the 
near future, that would be more acceptable.  This was 
the justification I read for leaving the namespace 
functions private, so I followed suit. -- Vince.

Logged In: YES 
user_id=80530

Some more problems:
  1) Running the test suite on Linux, I get Segmentation
     Violations all over the place.  Don't know why yet.

  2) Looks like the stub declarations got messed up.  The
     *Decls.h files are no longer what would be generated
     from the *.decls files using 'make genstubs'.

  3) Some of the routines in the tclInt interface now 
     match Tcl_*.  Everything matching Tcl_* should be
     public (part of the tcl interface).  We'll need to
     determine what routines need to be public vs. internal.

Logged In: NO 

Forgot '-N' flag to diff, so that's why the new 
FileSystem.3 man page is not there.  I'll add it to a new 
patch as soon as I've resolved the 'file type' issue you 
kindly reproduce below.

One other issue:

'tclIOUtil.c' is not the most descriptive name for this 
file, given its new contents (most of the vfs code).  It 
might be good to introduce a new file 'tclFilesystem.c' 
which contains most of the new stuff, but that will 
obviously involve changes to various makefiles.

I'll leave things as they are unless people feel strongly a 
new file should be added.

Logged In: YES 
user_id=80530

Note: the patch still does not include any of the docs
for the new/changed C APIs.

Logged In: YES 
user_id=80530

With the new patch, I see only one test suite error
on Solaris, unixFCmd-2.3.

Here's an interactive session that demonstrates the problem:

landau:solaris: ./tclsh
% set null /dev/null
/dev/null
% file type $null
link
% set null [file join [file dirname $null] [file readlink
$null]]
/dev/../devices/pseudo/mm@0:null
% file type $null
could not read "/dev/../devices/pseudo/mm@0:null": no such
file or directory
% file type /devices/pseudo/mm@0:null
characterSpecial

It looks like [file type] behaves differently whether its
path argument is "normalized" or not.

File Deleted - 4288:

Logged In: YES 
user_id=80530

Deleted out of date patches

File Added - 4333: tclobjvfs.diff.gz

Logged In: YES 
user_id=32170

The gzipped patch I have just uploaded contains now fixes 
to the various comments below (to the best of my ability to 
verify things), renames everything to Tcl_FS*, and has 90% 
of the C API properly documented.

Note the patch is gzipped because (i) it is huge, so not 
much point in viewing source online, and (ii) sourceforge 
rejects it because it is too big.

Logged In: NO 

I've fixed all of the tests below now (well actually the 
latter ones showed up a small bug in the code, the former 
ones were simple message changes).  At least for me on 
Windows and Redhat 6.2 linux I get all the 
fileName/fCmd/cmdAH/unixFCmd/unixFile/... tests to pass 
with one exception (which is in fact not listed in your 
problem list; we'll have to see if others also see this one 
problem).  Note: I completely do NOT see problem (4) below.

In regard to other questions below, I'm happy to be the 
maintainer of any of the files I'm heavily modifying in 
this patch.

Vince.

Logged In: NO 

Could you please give details on these four test suite 
errors:

fCmd-6.24
fCmd-6.25
unixFCmd-1.1
4) One other test suite failure in test unixFCmd.test:
could not read "/dev/../devices/pseudo/mm@0null,": no such
file or directory

what were the wrong error messages, for the first three, 
and exactly which test failed in (4)?  The others have all 
been dealt with now.

Thanks!
Vince.

Logged In: YES 
user_id=80530

Maintainers from the following areas must approve this
patch before it can be integrated:

Commands A-HDKF
Commands I-LDKF
Commands M-ZDKF
Memory Allocation
Compiler and ObjectsMS
Event LoopsJN
File SystemDS, JI(*)
Pathname ManagementDS, JI(*)
Channel SystemAK
Channel CommandsAK
Dynamic LoadingKK, DS, JI, JN
Init - Library - AutoloadDGP, DS, JI
resource CommandDS, JI
registry PackageKK
dde PackageKK
Configure and Build ToolsMD

(*) Dan Steffen and Jim Ingham are Mac-specific maintainers
of the Pathname Management and File System areas.  There's
no general maintainer for those sections.  Would you be
interested in that job, Vince?  After this patch, you'll
probably know that part of the code better than anyone.

Logged In: YES 
user_id=80530

Problems with this patch:

1) No C API documentation.
2) Tclfs_* routines should be Tcl_FS*
3) Changed error messages cause these tests to fail:
cmdAH-5.2
cmdAH-30.1
cmdAH-30.2
cmdAH-30.3
cmdAH-30.4
cmdAH-30.5
cmdAH-30.6
cmdAH-30.7
fCmd-6.24
fCmd-6.25
unixFCmd-1.1
   These tests should be updated to expect the new error
   messages.
4) One other test suite failure in test unixFCmd.test:

could not read "/dev/../devices/pseudo/mm@0null,": no such
file or directory

It appears that [file type] requires a "normalized" path
name to function properly.  It probably should not have that
requirement.  If it must, then the test needs updating.

Also the comma appended to the end of the file name in the
error message doesn't look good.  It's not in the file name
itself.  Could be a problem with [file join].

That's all I see so far on Solaris.  Things look
considerably worse on my Alpha.  More on that later...

File Added - 4289: tip17-other.patch

Logged In: YES 
user_id=80530

...and second, the changes to the other files.

File Added - 4288: tip17-generic.patch

Logged In: YES 
user_id=80530

OK.  SF replied that patch sizes must be > 20 bytes
and < 256000 bytes.  This patch is too big.

So.... trying to upload it in two parts.  First, the
changes to files in generic/ (except tclTest.c)...

Logged In: YES 
user_id=80530

Attempt to upload the patch file...

Logged In: YES 
user_id=80530

In case you didn't know, there's no patch file attached.
More trouble with SF's file uploading?!