2.4.19 NFS file perms

Hi,

on an NFS mounted fs, executing as root I see this:

[root@sirizidl nfsr]# ll /nfsr/toplev.fig
-rw------- 1 kernel users 48500 Oct 5 11:42 /nfsr/toplev.fig
[root@sirizidl nfsr]# xfig /nfsr/toplev.fig
[snip]
...
stat64("toplev.fig", {st_mode=S_IFREG|0600, st_size=48500, ...}) = 0
open("toplev.fig", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0600, st_size=48500, ...}) = 0 old_mmap(NULL, 48500, PROT_READ, MAP_PRIVATE, 4, 0) = 0xc0011000
read(4, 0xefffe4cb, 1) = -1 EIO (Input/output error)
_llseek(4, 48500, [48500], SEEK_SET) = 0
--- SIGBUS (Bus error) ---

glibc crashes in fgets because it doesn't expect the problem after the file has been successfully opened and mapped.. who is at fault here?

Remote nfs server is an old userspace implementation btw.

Richard

> Hi, on an NFS mounted fs, executing as root I see this:

> read(4, 0xefffe4cb, 1) = -1 EIO (Input/output error)

> glibc crashes in fgets because it doesn't expect the problem > after the file has been successfully opened and mapped.. who is > at fault here?

The 'soft' mount option perhaps?

Cheers,
Trond

If glibc crashes because of an unmap you are I suspect running a gcc 2.3 snapshot with the buggy and bogus mmap stdio option. If so turn it off before it does any more harm.

no, automount entry is
nfsr -rw,noatime rz:/usr/m68kroot

thanks, this seems to be one part of the solution - it is a glibc snapshot from rawhide, somewhat aged in the meantime.
I am still surprised that NFS returns such strange error instead of EACCESS but that is probably bad interaction with the old NFS server.

Richard
.