file readable issue on SMB network
jose-v
I'm having problems in testing the readability of files in a SMB
mounted unit (Mac server, Windows client) by using "file readable".
"file readable Y:" returns 0, while I can perfectly read that unit and
all of its contents ("open Y:/test.txt r" works perfectly). In
contrast, "file readable C:" returns 1, as it should.
This problem has been reported some time ago (2006) in this group with
the subject "file readable issue on samba network", for Tcl 8.4. I can
still reproduce it now in my compiled 8.5.4 and the downloaded 8.5.7
in ActiveState. I was thinking on reporting this as a bug, but I
wanted to ask you first in case I'm missing anything important.
Cheers,
j.
Ralf Fassel
| I'm having problems in testing the readability of files in a SMB
| mounted unit (Mac server, Windows client) by using "file readable".
Why don't you just open the file and catch any error? Since the file
status may change between your 'file readable' call and the call to
open, you need to handle those errors anyway...
R'
ZB
> Why don't you just open the file and catch any error? Since the file
> status may change between your 'file readable' call and the call to
> open, you need to handle those errors anyway...
...but despite the above [file readable $xyz] should return proper status
at the time of check-out, shouldn't it?
--
ZB
ho-tse
> Why don't you just open the file and catch any error?
The file is not going to be read by Tcl but sent for reading somewhere
else, so I can not just [catch] it. Of course error handling when
opening is necessary, but [file readable] should do its job reporting
the correct thing, for my interface to decide what to show to the
user.
Your suggestion is a good workaround, I can implement my own proc
isFileReadable and try to [open $file "r"] just to see if that is
possible, return 0 otherwise. But [file readable] is there supposedly
to save me that job!
I will probably use your suggestion while I report this as a bug...
ho-tse
for files, not for directories, as you can not open them...
Programming my own versatile isPathReadable is trickier!
ho-tse
https://sourceforge.net/tracker/index.php?func=detail&aid=1613456&group_id=10894&atid=110894
Ralf Fassel
| ...but despite the above [file readable $xyz] should return proper
| status at the time of check-out, shouldn't it?
Of course it should (in the application of the OP it actually needs to).
I also encountered similar (?) problems with 'file executable' on Samba
shares some time ago:
http://sourceforge.net/tracker/index.php?func=detail&aid=1951574&group_id=10894&atid=110894
R'
Don Porter
> This problem has been reported some time ago (2006) in this group with
> the subject "file readable issue on samba network", for Tcl 8.4. I can
> still reproduce it now in my compiled 8.5.4 and the downloaded 8.5.7
> in ActiveState. I was thinking on reporting this as a bug, but I
> wanted to ask you first in case I'm missing anything important.
Can you please try the same testing with Tcl release 8.4.12 and confirm
that this unwelcome behavior was introduced in the 8.4.13 release?
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
ho-tse
> Can you please try the same testing with Tcl release 8.4.12 and confirm
> that this unwelcome behavior was introduced in the 8.4.13 release?
I can not test 8.4.13 right now, but indeed [file readable Y:] worked
correctly in 8.4.12 but returns a wrong answer in 8.4.14.
j.
Koen Danckaert
Are you sure it worked "correctly" ?
My impression is:
- In 8.4.12, [file readable] always returned 1 on an SMB drive.
- In 8.5.4, it returns the whether the file is world readable.
So both are incorrect, but the new behaviour causes more problems.
Koen
ho-tse
Well, you're right, I haven't properly tested it.
All I noticed is that in 8.4.12 [file readable Y:] returned 1 when
that was what I was expecting, but 0 in a later version. And because
Don's email suggested that a bug could have been introduced in there,
I was eager to confirm it :-)
Don Porter
>>> Can you please try the same testing with Tcl release 8.4.12 and confirm
>>> that this unwelcome behavior was introduced in the 8.4.13 release?
ho-tse wrote:
>> I can not test 8.4.13 right now, but indeed [file readable Y:] worked
>> correctly in 8.4.12 but returns a wrong answer in 8.4.14.
Koen Danckaert wrote:
> Are you sure it worked "correctly" ?
> My impression is:
> - In 8.4.12, [file readable] always returned 1 on an SMB drive.
> - In 8.5.4, it returns the whether the file is world readable.
>
> So both are incorrect, but the new behaviour causes more problems.
Ok, those impressions tend to confirm my impression that the unwelcome
behavior arrived in the patch that was committed to fix Tcl Bug 1193497.
The challenge for the party with the right interests, skills, and tools
is to look at that patch, and see how [file readable] was implemented
before and after it, and craft some new implementation that corrects
the unwelcome behavior now being observed without restoring the
Tcl Bug 1193497 at the same time.
Until such a person follows through on that, I expect the problem
to remain.