I am pleased to add that the cmr'ed changes test out OK in the v1.7 branch
On Fri, Jan 10, 2014 at 7:28 PM, Paul Hargrove <phhargrove_at_[hidden]> wrote:
> 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).
> Can you please verify on Cygwin?
> On Fri, Jan 10, 2014 at 6:34 AM, Jeff Squyres (jsquyres) <
> jsquyres_at_[hidden]> wrote:
>> On Jan 10, 2014, at 9:18 AM, "Jeff Squyres (jsquyres)" <
>> jsquyres_at_[hidden]> 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
>> 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
>> For corporate legal information go to:
>> devel mailing list
> Paul H. Hargrove PHHargrove_at_[hidden]
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
Paul H. Hargrove PHHargrove_at_[hidden]
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900