Tcl Source Code

Various emails discussing this bug quoted below:



Hi Vince,
(iii) sounds workable with modest "surprise" added
to the design. In this case the special handling seems
appropriate. I say this still w/o seeing the code.
A patch would be great because I think (i) is just
plain goofy. - Thanks.


Roy


> I've looked into this further and I see three 
options:
>
> (i) ignore the bug and define 'glob' to behave in 
this way when the user
> gives a fully-specified file name (i.e. when there's 
no pattern matching).
>
> (ii) add a new filesystem-specific API (i.e. yet 
another Tcl_FS... function
> which must be implemented for each filesystem) which 
matches file-types
> according to 'Tcl_GlobTypeData'.  This function 
could be used to simplify
> each 'TclpMatchInDirectory' implementation, perhaps, 
(loop over each file
> which matches the glob pattern and pass that file to 
the new API), although
> there might be a performance penalty to pay.
>
> (iii) change the way TclpMatchInDirectory works so 
that it can handle the
> special case we need here.  This can be done in a 
backwards compatible way
> as follows: if 'pattern' is NULL then consider 
the 'pathPtr' which is
> passed in not as a directory in which to search, but 
as a fully-specified
> path to check against 'types'.  This is backwards 
compatible because the
> code will currently segfault if pattern is NULL (but 
pattern is currently
> never NULL, of course).
>
> I would lean towards (iii) as the best solution, 
since (ii) is needlessly
> complicated and (i) isn't very good. However, if we 
do adopt (iii) we might
> then wish to change the name of the function too 
(it's a new function in
> Tcl 8.4a3 so changing it isn't a compatibility 
issue).
>
> Any thoughts?
>
> Vince.
>
> Note: my original suggestion of duplicating code in 
tclFileName.c is no
> good, because that code is filesystem/platform 
specific (because matching
> against 'Tcl_GlobTypeData' is platform specific).
>
> At 09:51 AM 1/22/2002 -0800, Roy Terry wrote:
> >Vince,
> >I take your word for it. I wasn't able to find it in
> >my source which which I believe is 8.4a3 and where
> >RCS: @(#) $Id: tclFileName.c,v 1.16 2001/08/07 
01:00:02 hobbs Exp $
> >only has 2360 lines. I must be behind a bit. For my 
2 cents,
> >I'd be a bit concerned about duplicating though 
certainly the essential
> >properties of files seem pretty stable. I will be 
refreshing my
> >code in the next few weeks so if you've not put in 
a fix by then
> >I'll get back in touch and see If I can contribute.
> >
> >
> >Thanks,
> >Roy
> >
> > > Found a few minutes to look more closely at the 
code.  Basic problem which
> > > needs fixing starts in the block of code at line 
2477 of
> > > tclFileName.c.  This code doesn't pay any 
attention to the 'types' argument
> > > of the function (TclDoGlob).  While there may be 
elegant ways of fixing the
> > > code without duplication (as alluded to below), 
if one adds suitable
> > > 'types' checking to that block of code, it'll 
fix this problem.
> > >
> > > cheers,
> > >
> > > Vince.
> > >
> > > At 04:22 PM 1/21/2002 -0800, Jeff Hobbs wrote:
> > > >Roy Terry wrote:
> > > > >
> > > > > In the following transcript, notice how the
> > > > > -types restriction seems to be ignored if
> > > > > a literal file name is given.
> > > >
> > > >Yes, that does seem to be the case, tested on 
the head and 8.3.4.
> > > >Evidently the -types check isn't being heeded 
when there is just
> > > >one file matching, or something like that.
> > > >
> > > > > (tmp) 84 % ls -l
> > > > > ./:
> > > > > -r--r--r--      316 Jan 18 12:56 x
> > > > > (tmp) 85 % glob -types f ?
> > > > > x
> > > > > (tmp) 86 % glob -types f .
> > > > > .
> > > > > (tmp) 87 % glob -types w ?
> > > > > no files matched glob pattern "?"
> > > > > (tmp) 88 % glob -types w x
> > > > > x
> > > > > (tmp) 89 % puts $tcl_patchLevel
> > > > > 8.4a4
> > > > > (tmp) 90 % parray tcl_platform
> > > > > tcl_platform(byteOrder) = littleEndian
> > > > > tcl_platform(machine)   = intel
> > > > > tcl_platform(os)        = Windows NT
> > > > > tcl_platform(osVersion) = 4.0
> > > > > tcl_platform(platform)  = windows
> > > > > tcl_platform(user)      = roy
> > > > > (tmp) 91 %
> > > >

File Added - 21520: tcl-mac-aliases.patch

Logged In: YES 
user_id=90580

attached and checked a patch that fixes alias file handling 
on the mac as discussed. In addition to changing 
TclpObjNormalizePath it was necessary to introduce a new 
alias aware version of FSpLocationFromPath 
(FSpLLocationFromPath).

2002-04-20  Daniel Steffen  <[email protected]>

* generic/tclInt.decls:
* generic/tclIntPlatDecls.h:
* generic/tclStubInit.c:
* mac/tclMacFCmd.c:
* mac/tclMacFile.c:
* mac/tclMacUtil.c: Modified TclpObjNormalizePath to be 
alias
file aware, and replaced various calls to 
FSpLocationFrom*Path
by calls to new alias file aware versions 
FSpLLocationFrom*Path.
The alias file aware routines don't resolve the last 
component of
a path if it is an alias. This allows [file copy/delete] 
etc. to
act correctly on alias files. (c.f. discussion in Bug 
#511666)

Logged In: NO 

Yes, it should -- Vince.

Logged In: YES 
user_id=90580

ok, so this means modifing tcl/mac/tclMacFCmd.c 
(TclpObjNormalizePath) to no longer resolve the last path 
component should take care of all the [file *] problems, 
correct?

Logged In: NO 

Thanks for fixing the glitches on MacOS!

A quick note re. 'normalization and aliases':

The MacOS behaviour (expand all links including final ones) 
is what I originally planned and thought was correct.  
However, 'file copy' 'file delete' etc are all /defined/ in 
the man pages to operate on links in preference to real 
files.  If the results of the normalizePathProcs resolve 
the final alias/link in the chain, then the behaviour of 
file delete/copy etc is wrong.

I'm was wondering whether the Tcl-level command 'file 
normalize' should perform additional checking to resolve 
the final alias in the chain. In the end I decided it 
shouldn't.

Logged In: YES 
user_id=90580

checked into the HEAD:
2002-04-08  Daniel Steffen  <[email protected]>
* mac/tclMacFile.c: minor fixes to Vince's changes from 
03-24.
* tests/fileSystem.test:

with these changes all tests pass and everything works as it 
should; except for [file normalize] behaviour w.r.t to alias 
files, i.e. on the mac, the file commands currently resolve 
the last path component if it is an alias file, so e.g. there 
is no way to delete an alias file, the original will be 
deleted instead...

Logged In: YES 
user_id=32170

committed patch with mac support added.

File Added - 19556: glob18.patch

File Added - 19481: globLinkFix.patch

Logged In: YES 
user_id=32170

upload patch.

File Added - 19480: fileSystem.test

Logged In: YES 
user_id=32170

source forge playing up, try again...

File Deleted - 18047: 

Logged In: YES 
user_id=32170

Uploading a newer patch which fixes some other reported 
bugs, and makes file normalize work as advertised on unix.

The question still remains whether we should 
rename 'Tcl_FSMatchInDirectory' and the Mac implementation 
is still needed.

Logged In: YES 
user_id=32170

Quick thought: once Daniel has fixed the MacOS side of 
things, should we rename 'Tcl_FSMatchInDirectory' 
to 'Tcl_FSMatchPathTypes' because the function might now 
either search all files in the given directory for ones 
with the right type, OR check a single file for having the 
right type.  The old name isn't very logical given the new 
behaviour, is it?

This would only be a change since 8.4a3/a4 and wouldn't 
impact any external code except 'tclvfs' which I maintain 
anyway (and which needs updating as a result of this patch 
anyway).

Logged In: YES 
user_id=32170

Daniel: it works on Windoze and Unix.  Would you mind 
testing on MacOS? --- it will require a (small?) amount of 
work in tclMacFile.c, to get compiled and running, but I've 
made the basic changes required.

Logged In: YES 
user_id=75003

The patch as it is here

* Applies cleanly.
* Compiles cleanly.
* Passes testsuite.

(Linux/Intel gcc 2.95.2, against 8.4cvs as of Feb 25, 7pm)

Did not not teat the Mac part.

File Deleted - 17108:

Logged In: YES 
user_id=32170

Andreas: would you mind taking another look at this; I 
think it should now work better than before.

File Added - 18047: globFix.patch

Logged In: YES 
user_id=32170

Added yet another new patch, since the TIP#72 commits mess 
with the patch!

File Added - 17640: globFix.patch

Logged In: YES 
user_id=32170

recent cvs commits conflicted with this patch, so uploading 
a new one which will apply to cvs head.

Logged In: YES 
user_id=32170

Re-assigning bug since I've done about all I can on it.

File Added - 17303: globFix.patch

Logged In: YES 
user_id=32170

Attached patch which includes an attempt at a version for 
MacOS too.  This is about all I can do.  People on 
unix/macos will have to test and fix from here.

File Added - 17294: globFix.patch

Logged In: YES 
user_id=32170

Attached a fix for andreas's issue.  NativeMatchType should 
begin:

    if (types == NULL) {
/* 
 * Simply check for the file's existence, but do it
 * with lstat, in case it is a link to a file which
 * doesn't exist (since that case would not show up
 * if we used 'access' or 'stat')
 */
if (lstat(nativeEntry, &buf) != 0) {
    return 0;
}
    } else {
        ...indented rest of code ...
    }
    return 1

Logged In: YES 
user_id=75003

Initialization is done only if "typePtr" is not NULL, and 
typePtr seems to come from the command arguments.

Logged In: YES 
user_id=75003

Applies cleanly.
Compiles cleanly.

Starting the testsuite crashes the core immediately,
in NativeMatchType, line 372. argument "types" is NULL.
Going through the call chain shows that the 
variable "globTypes" in Tcl_GlobObjCmd (tclFileName.c, 
1542) is NULL. There has to be a branch not initializing it.

File Added - 17257: globFix.patch

Logged In: YES 
user_id=32170

Added patch with unix implementation (done blind -- needs 
testing for compilation and against fileName.test).

File Added - 17108: globFix.patch

Logged In: YES 
user_id=32170

Here's a suggested fix for this bug (including tests) which 
works for me on Windows.  The code will fail completely on 
Unix/MacOS.  I'm not going to have time for a while to 
complete the patch for those OSes, so please help out!