Tcl Source Code

Environment:
Linux Gentoo Dual Processor AMD64
Tcl 8.5a6(CVS) - problem located (and solved) here
Tcl 8.4.9 - system version, displays same problem

In my university shell account, we use afs filesystems
on our home directories.

When i try to use [file copy $src $dst] and the $src
file is located on the afs filesystem, the $dst file
will be an empty file (size = 0).

I tracked the problem to the following code located in
the file tcl/unix/tclUnixFCmd.c(TclUnixCopyFile):

    #ifdef HAVE_ST_BLKSIZE
        blockSize = statBufPtr->st_blksize;
    #else

in this case, blockSize will have the value 0, which
leads to (un)expected results when reading from the
source file and it treats it as EOF.

Why does this happen (blockSize = 0)? I have no idea...
but most likely related to the fact that the source
filesystem is afs.

A workaround would be to test the blockSize value when
it has a nonpositive value and replace it with a
default value when it happens. With this check all
files were copied correctly.

I noticed there is another similar situation when this
also might happen; when statfs information is used on
the source file i guess this behaviour might lead to
similar problems, but i'm just guessing on this one.

The problem was found while building/testing tcl from
cvs HEAD, but the tcl installed on the system -
tcl8.4.9 - was showing the same problem.

Logged In: YES 
user_id=75003

Committed the proposed fix to both 8.4 and 8.5 branches,
with an additional comment describing the reason for the change.

Logged In: YES 
user_id=75003

Thank you for doing the tests and checking them out.

Logged In: YES 
user_id=699329

I finally had some time to take a better look at the test
output.

All the errors are related with filesystem permissions
(read/write) which is understandable. The filesystem i
tested tcl on is using ACLs for filesystem permissions and
the tests ignore that, and the test results get unexpected
results.

The only serious problem, copying files (the contents), is
the only one worth fixing and the proposed fix is given in
the patch file attached to the bug report.

Hope to see the fix included in CVS soon (both 8.4 and 8.5
versions).

File Added - 201374: tcl.test.output.0.gz

Logged In: YES 
user_id=699329

I didn't think about running the test suite...

I did it now, after doing a cvs update on the HEAD branch,
but i am getting some errors and most, if not all, seem to
be related with filesystem operations.

I will upload the test output and will try to investigate
the problem further in the next few days (as i get some free
time to do it).

As it seems, the problem initially reported may be only one
of the issues related with afs filesystem.

Logged In: YES 
user_id=75003

Thank you for the patch. I begin to understand the problem,
and I see that the fix is truly trivial. I guess that you
ran the core testsuite and no problems appeared which were
not present in the unchanged core, right ?

I see no problem in putting that in.

File Added - 201252: patch.diff

Logged In: YES 
user_id=699329

I attached a diff file with my changes to fix the problem
described initially.

The main problem is that tcl sources trust values given by
the OS to get an optimal buffer size to use when copying
files and sometimes that value is zero (0). And when tcl
starts copying the file, it will behave as if an EOF was
reached when it did not copy a thing at all.

Logged In: YES 
user_id=75003

IMHO it is a bit difficult to re-create your work from this
description. As you have the changed Tcl sources available,
and also the unchanged Tcl sources, can you please create a
patch comparing unchanged and modified sources ? ... Please
use 'diff -u' so that the result is a patch in the 'unified
diff' format, which is human-readable.

Logged In: YES 
user_id=699329

has anyone even looked at this problem?

i believe this is a very serious problem and should be fixed
soon.