fileutil cat fails for some and not for others; chan works all the time

[sled...@gmail.com]

file cat:
set script [::fileutil::cat $fileName]

Channel:
# open in the text from source file

set fd [open $inFile r]
chan configure $fd -encoding "utf-8"
set script [chan read -nonewline $fd]

the 'cat' script works on some computers, but not all. However, it does so consistently - that is, if it works once, it works all the time. Similarly, if if fails - unable to access 'filename'.

The channel operation works on all systems.

Can anyone explain this behavior - it would be appreciated. My confidence is shaken...

Details (of course) -
The files are on a drive managed by Isilon.
In addition, I was just informed that some access Isilon via vpn, others via lan.

Not clear yet of the relationship between those with issues and mode of connection.

Regardless, what is it in cat that can explain this behavior...

Rick

[pal...@yahoo.com]

As a starting point, what do ::errorCode and ::errorInfo show you on failure?

[Gerald Lester]

On 07/13/2017 11:33 AM, sled...@gmail.com wrote:
> file cat:
> set script [::fileutil::cat $fileName]

>...

> if if fails - unable to access 'filename'.

As someone else pointed out -- at a minimum you need to supply us with
the values of ::errorInfo and ::errorCode to really help.

Since the above snippet does not show the origin of fileName and sense
that varies from the error only by capitalization -- did you cut and
paste the error message or retype it?

Also what version of the fileutil package are you using on the computers
where it will fail and what version on the ones where it works?

Lastly,> set fd [open $inFile r]

> chan configure $fd -encoding "utf-8"
> set script [chan read -nonewline $fd]

The above is fragile and will not work for binary files and *may* not
work for files with other than UTF 8 encoding.

--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+----------------------------------------------------------------------+

[sled...@gmail.com]

error info: Cannot read file S:/StarPerformer/sims/Public..., read access is denied.

Thing to remember: same script is being executed, including the file name.
The script is identical in all aspects, including versions. It has been compiled into an exe using Active State TCL DEV Kit. The exe is shared among all users.

fileutil: 1.14.10

So the base question goes back to:
1.what is it that open\chan does that cat doesn't with regard to file access, and 2. what machine or network dependencies are there between the functionality or operation that drove this behavior.

The good news is the problem was solved using the open\chan operation. But the overarching concern is how to avoid getting bitten like this again.

The customer is still drilling down through the labyrinth of permissions in Win7 and on the Isilon system manager. So far, each user has has full permissions. However, the thrill is gone in as much as problem 'seems' to have been resolved.

The only glaring discrepancy is that some users accessed isilon via vpn; others not.

[pal...@yahoo.com]

In all likelihood, this problem is caused by the following check in fileutil::cat

} elseif {![file readable $a]} {
return -code error "Cannot read file \"$a\", read access is denied"
}

In my experience, the commands like [file readable|writable etc.] are not reliable when used with "non-native" file systems and I suspect Isilon is one such. Even with native file systems, [file readable] returning true does not mean you can actually read it for several reasons such as integrity levels, locking etc. The only reliable way to check a file is readable/writable is by actually trying to open it in that mode.

It would be interesting if you could try [file readable] on those files causing a problem and see what result you get back.

/Ashok

[Ralf Fassel]

* pal...@yahoo.com

| In all likelihood, this problem is caused by the following check in
| fileutil::cat
>
| } elseif {![file readable $a]} {
| return -code error "Cannot read file \"$a\", read access is denied"
| }
>
| In my experience, the commands like [file readable|writable etc.] are
| not reliable when used with "non-native" file systems and I suspect
| Isilon is one such.

I'd second that. We made the exact same experience on Windows accessing
network shares (though I can't say what the Server OS was).

We replaced all [file readable] by our own version which actually tries
to read-open the file if [file readable] signals 'no'.

However, if [file readable] said 'yes', we had no problems accessing the
files (apart from the usual race condition).

I can't say which security aspects of the problematic files were the
culprit, in Windows they all showed "full-access" in Explorer.

HTH
R'

[sled...@gmail.com]

file readable was, as you cited, no reliable. Tried it several times and sometimes the magic worked, sometimes it didn't.

[sled...@gmail.com]

...not reliable...

BTW: do really appreciate the responses...exceedingly helpful...

[Keith Nash]

I have also found that [file readable|writable] returns 0 on Windows when it
should return 1 - in this case for the pseudo-network shared directory of
VirtualBox when Windows runs in a VM. I could not be sure whether the bug
was in VirtualBox, but the parent post suggests it is common to all Tcl
access to network files.

Keith.

[Harald Oehlmann]

Keith,
could you please contribute to tcl ticket

http://core.tcl.tk/tcl/info/1613456fffffffff

We are collecting test-cases there how to reproduce this behaviour.

Thanks,
Harald