Try to use it and see if it generates an exception? (What exactly do
you mean by "stale" anyway?)
Donal.
While running my code on linux (RHEL 4)
I make c file channel(using [open abc.txt])
now somehow my file is deleted or moved to other place
i am getting this type of error
while executing flush command on channel
"error flushing "file5": stale remote file handle
error flushing "file5": stale remote file handle
while executing
flush channelID"
Catch the 'flush' (and 'puts') and inspect ::errorCode if it fails.
I think there is no way to check whether 'the file handle is stale'
other than to actually use it...
HTH
R'
I didn't expect the word "remote" here...
Is this on a network file system? If so, then it may not be a
tcl-related problem.
> Catch the 'flush' (and 'puts') and inspect ::errorCode if it fails.
> I think there is no way to check whether 'the file handle is stale'
> other than to actually use it...
It might be worth a try, whether "eof" suffices as a test, in case
"flush" is doing too much for using it as a test.
Or even "tell" perhaps?
--
Glenn Jackman
Write a wise saying and your name will live forever. -- Anonymous
Yes, this means that the file is on a remote fs like NFS, and that
somebody else has moved/deleted it under your feet while you were
still holding an open fd to it (in the Tcl channel handle). The mere
fact that this can occur means that you have a design flaw: you should
establish some kind of protection to grant exclusive write/delete/
move access to the various actors, instead of trying to detect that
nasty situation.
Can you elaborate on the context, so that we can help you design that
protection ?
-Alex
Yes it is network file system.
File is removed by another host machine.
So is this problem with NFS?
I too feel it is NFS problem.
File is renames by another host and i have handle of that file.
while flushing the file handle i am getting this error.
Read:
http://nfs.sourceforge.net/
go down to
A10: What does it mean when my application fails because of an ESTALE error?
then go down to
"D. Commonly occurring error messages"
Or just read through the complete page.
It passes along all your reported problems and explains them.
Fixing your issue would probly use [catch]
if {[catch {flush $rem_fd} cerr]} {
switch -glob -- $cerr \
"*stale remote*" {
# insert code to handle ...
} default {
puts stderr "$rem_fd : error : $cerr"
}
uwe
The TCL eof manpage reads:
Returns 1 if an end of file condition occurred during the most
recent *input* operation on channelId (such as gets), 0 otherwise.
(** emphasis by me). And even for input, 'eof' will not trigger until
you've actually tried to read something from the channel:
% open /dev/null r
file3
% eof file3
0
% read file3
% eof file3
1
I haven't checked the code for output, but usually you get no eof on
output. write-to-closed-Pipe and disk-full are different conditions...
R'
At the time of writing it, "nfs" being the cause was just a guess.
I also speculated about tcl-channels going stale, themselves,
but that turned out not to be relevant in this thread (if at
all possible, anyway).