Tcl Source Code

On solaris2.6 platform, if a directory contains a
softlink that refers
to a non-existant file, then the above glob command
results in
error/abort:

hlavana-u5:6> ls -l
total 16
-rw-r--r--   1 hlavana  eng8           0 Apr 18 10:00
junk
lrwxrwxrwx   1 hlavana  eng8           4 Apr 18 09:06
link -> junk
hlavana-u5:7> ~/sw/bin/tclsh8.3
% info patch
8.3.3
% glob -type r *
link junk
% file delete junk
% glob -type r *
stat failed on known file
Abort
hlavana-u5:8> 

Hemang.

Logged In: YES 
user_id=32170

Fixed in cvs head

Logged In: YES 
user_id=79902

The key (I think) is that with [glob -type r *] the user is
asking for all files that can be opened by [open ... r]
without causing an error. Since that is not the case with a
broken link, it should not be returned. This assumption is
also true for -type x, but not necessarily for -type w (it
depends on whether creation is permitted in that directory)
but it wouldn't be harmful to exclude those too (it depends
on the interpretation of 'writable', but arguably a file is
not previously writable if you have to create it as part of
opening it for writing. Which is lucky since it makes the
implementation simpler. :^)

Logged In: YES 
user_id=32170

Ok, I guess I agree with Jeff.  So the choices are:

(i) simply ignore the disappearance
(ii) warn the user by signalling an error (but this will of 
course abort the entire 'glob' in progress)

I guess I would vote for (i) in this particular case -- the 
user wants a list of files, but then one file has 
disappeared (or had some other OS problem) half way through 
so, it shouldn't be returned.  This behaviour kind of 
assumes that if we tried the 'readdir' a second time, it 
wouldn't return this particular file.

Logged In: YES 
user_id=72656

I don't think Tcl should ever panic on inconsistencies in 
the file system like this.  Return an error maybe, but not 
panic - that bombs out of everything.  This is a language, 
and it should be fault tolerant to the underlying system as 
much as possible.  Panics should be reserved for internal 
inconsistencies and Really Bad problems like no memory left.

Logged In: YES 
user_id=32170

I have to say I don't know what the semantics of broken 
links should be in Tcl.  The current behaviour (after this 
patch is applied) is ok, but we probably should examine 
Tcl's filesystem in general and see where it might be 
tripped up by files disappearing on it, and then take 
appropriate, consistent action everywhere.

I'll put this patch into the core and mark this bug closed 
when I apply some other small filesystem changes which have 
cropped up.

Logged In: YES 
user_id=79902

Of course you can't use [glob -type r *] to find all files
of type link; it gives a list of readable files, and links
without a target are not readable in any normal sense.  If
you want links, use [glob -type l *] (if I'm not greatly
mistaken...)

The real question here is what do we want the semantics of
broken links to be?  One possibility is that they are
filenames without a file to go with them...

Logged In: YES 
user_id=81875

I have verified the patch on solaris platform. It does not
abort anymore for the specific example I had submitted
earlier.  However, it does not return the name of link file.
This means that I cannot use "glob -type r *" command to
find and delete all files of tye link. Also, "file exists
link" returns 0 even though the link name exists - I think
it should return 1.

lavana@zodiac: [5] ls -l
total 8
-rw-r--r--   1 lavana   cbltesters      0 Aug 11 12:13 abc
lrwxrwxrwx   1 lavana   cbltesters      4 Aug 11 12:06 link
-> junk
lavana@zodiac: [6] tclsh8.4
% glob -type r *
abc
% glob *
link abc
% file exists link
0
% exit
lavana@zodiac: [7]

Logged In: YES 
user_id=79902

The patch looks OK to me, though it is still possible for
the panic() to be invoked in an unfortunate way if a file
gets deleted between the readdir() and the TclpLstat(),
which could happen (for example) if the OS decided to switch
to another process when the stat() was performed.

All this leads me to ask whether panic() is really the right
behaviour here, or whether it would be better to just fail
that directory entry silently, pretending that it was never
there in the first place.  What is certain is that panic()
is not an appropriate response to a bad link!

File Added - 9378: panic.diff

Logged In: YES 
user_id=32170

This behaviour is clearly determined here in tclUnixFile.c:

    if (TclpStat(fname, &buf) != 0) {
panic("stat failed on known file");
    }

Perhaps a better solution to this would be that in the 
attached patch (which I should point out I have no way of 
testing at all).

Logged In: YES 
user_id=72656

Verified on Linux.  The stat should be caught somehow 
internally.