No Subject

ROTECTED]> > Subject: Re: Programmatically determining FS type > > *smack* > > man 2 statfs. d'oh! boy, did i deserve that one ... Marc W, San Francisco, CA Kiltdown -- a free email client for X www.kiltdown.org -- it's what's underneath that counts. To Unsubscribe

Programmatically determining FS type

Is there a way in code, given a path (/moo/cow/oink) to determine the filesystem type for this given path? any chance there's a posix portable way of doing this, or is it always going to be very system specific? thanks! marc. Marc W, San Francisco, CA Kiltdown -- a

Re: Locking and Mail spool Files

Excellent, I will look for that. However, in the meantime, on older systems (3.x, 4.x, etc ...), is the below assertion correct? thanks! marc. Marc W, San Francisco, CA Kiltdown -- a free email client for X www.kiltdown.org -- it's what's underneath t

Locking and Mail spool Files

data ... ? Thanks! marc. Marc W, San Francisco, CA Kiltdown -- a free email client for X www.kiltdown.org -- it's what's underneath that counts. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

No Subject

Subject: Re:Compiling FreeBSD kernel with Sun's cc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Kiltdown 0.7 i may be wrong on this, but i believe that the reason that freebsd has its 'own' version of gcc is to support some things in the kernel. thu

Generating Core Dump Programmatically

I'm trying to ensure robust shutdown on my machine. Thus, I've installed signal handlers for a bunch of nasty looking signals. In my new handler, after all critical state is saved, I then call abort(3), and all seems to work well. EXCEPT -- some signals generate core files when le

Re: Where can I find out rules on blocking in threads?

ould use before I start digging through headers? thanks :-) marc. > - > From: mouss <[EMAIL PROTECTED]> > To: Peter Dufault <[EMAIL PROTECTED]> > Cc: Marc W <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: Where can

Re: Where can I find out rules on blocking in threads?

> > I think the FreeBSD behavior is wrong, the spec says that when > opening a FIFO with O_NONBLOCK clear that: > > > An open() for reading-only shall block the calling thread until a > > thread opens the file for writing. An open() for writing-only > > shall block the calling thread until a th

Where can I find out rules on blocking in threads?

hello! I'm running into a problem with some threading using pthreads in an application i'm writing for FreeBSD. The application basically 1. initializes some UI goo (but doesn't start any of it UP) using a GUI framework (Qt) 2. creates a FIFO, and then spawns a thread 3

Re: Is mkdir guaranteed to be 'atomic' ??

> > > > I can handle it if there is a case where both fail, but is there a > > case where both can SUCCEED ?? > > What do you mean 'both succeed'? My understanding is that, on non-broken filesystems, calls to mkdir(2) either succeed by creating a new directory, or fail and return EEX

Re: Is mkdir guaranteed to be 'atomic' ??

> - > From: Nate Williams <[EMAIL PROTECTED]> > > >Are there filesystem type cases where this might not be the case > > >(NFS being my main concern ) > > > > No. > > Yes. NFS doesn't guarantee atomicity, because it can't. If the mkdir > call returns, you hav

Why does a named pipe (FIFO) give me my data twice ???

hello! I've got a program that creates a named pipe, and then spawns a thread which sits in a loop: // error checking snipped. // while (1) { int fifo = open(fifoPath, O_RDONLY); // this blocks fprintf(stderr, "somebody opened the other end!\n"); read(fi

Is mkdir guaranteed to be 'atomic' ??

hi! i can never really tell if this alias is for discussions concerning development OF the FreeBSD OS or development ON the FreeBSD OS (or both), but I figure i'll risk the wrath of the anti-social and ask a coupla programming questions :-) is mkdir(3) guaranteed to be atomic? Thus,