Jeff and I iterated a bit off-list and opal/util/path.c in tonight's trunk tarball (1.9a1r30255) works for all of my systems. With the help of Jeff's recently-enhanced test/util/opal_path_nfs.c I was able to verify that NFS mounts are now correctly identified on the *BSD systems (and still correct on Linux, Mac OSX, and Solaris).
Marco, Can you please verify on Cygwin? -Paul On Fri, Jan 10, 2014 at 6:34 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com > wrote: > On Jan 10, 2014, at 9:18 AM, "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> > wrote: > > >> It seems to indicate that even if one does find a statfs() function, > there are multiple os-dependent versions and it should therefore be > avoided. Since statvfs() is defined by POSIX, it should be preferred. > > > > Sounds good; I'll do that. > > Gah. The situation gets murkier. I see in OS X Mountain Lion and > Mavericks man pages for statvfs() where they describe the fields in struct > statvfs: > > f_fsid Not meaningful in this implementation. > > This is the field I need out of struct statvfs to know what the file > system magic number is. Arrgh! > > I'll keep looking into what would be a good solution here... > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
