Ajay Askoolum wrote:...due to the vagaries that are possible when the OS provides access to a given file using multiple names.
I am not sure that I understand this; perhaps you can elaborate?
There are many possibilities, but think about a simple one: Let's say you've tied a file to F:\ABC\xyz.sf, where the F: drive is mapped to a network machine named NNNN. That file can also be referenced with a UNC path by \\NNN\C\ABC\xyz.sf. This equivalence is not easy to detect.
Ajay Askoolum wrote:That was going to be my suggestion but I realized that, for native files, if I have lost track of the tie number in the current context I would have no idea at which byte the read head is and there is no way to query this problematically. Moreover, if I've lost track of the (existing) tie number it is highly likely that I've lost track of the variable holding any index that I might have built for the file. In other words, if using the existing tie number, I would have no way of determining the fourth argument of []nread; hence the preference for 0⍴0 so that I can re-tie the file (read figure out why the file was tied in a context where I need to use the file and tidy up my code).
I seldom need such features for native files, but you can always reset the file pointer as mentioned.
Also, none of this is a matter (for me) of "losing track of the tie number". The issue that I have trouble with is when I have a routine to access a file independently, typically by tying and untying it at the beginning and end of the function. But I don't know (and sometimes can't tell) if the file is already tied by some other program in the stack, nor to what tie number the other program has tied it. So I'd like to be able to use the existing tie (and not untie it afterwards) because I can't create a duplicate tie to the file.
Also, you can detect a negative tie number (or positive, in the case of a native file) just as easily as an empty vector. The value can be ignored if you don't need it.