Hi,
I don’t if there something not compatible in qnet of in the filesystem if
we try to access from 6.2.1 to 6.3.0 or 6.3.0 to 6.2.1 filesystems that
doesn’t work well. links are not resolved, name completion don’t work…
That works a bit in shells but not at all in pfm.
What is the problem??
Thanks,
Alain.
Alain Bonnefoy wrote:
I don’t if there something not compatible in qnet of in the filesystem if
we try to access from 6.2.1 to 6.3.0 or 6.3.0 to 6.2.1 filesystems that
doesn’t work well. links are not resolved, name completion don’t work…
That works a bit in shells but not at all in pfm.
What is the problem??
Some 6.2.1 filesystems (non-disk, including procnto and nfs) were buggy
in that they did not properly zero out 64-bit reply messages. 6.3 libc
now honours 64-bit semantics according to the X/Open Largefile
Specification (there should be a release note about this), and so these
result in an EOVERFLOW to 32-bit clients. All 6.3 filesystems are fixed
(with respect to proper reply formatting), and ksh has been rebuilt
_FILE_OFFSET_BITS=64 (making it a 64-bit client and thus not sensitive
to EOVERFLOW, hence working around 6.2.1 bugs). The GUI group will have
to comment on the status of pfm.