From owner-freebsd-bugs Mon Jun 8 02:59:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA07599 for freebsd-bugs-outgoing; Mon, 8 Jun 1998 02:59:26 -0700 (PDT) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from dana.clari.net.au (dana.clari.net.au [203.27.85.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA07574; Mon, 8 Jun 1998 02:59:12 -0700 (PDT) (envelope-from peter@clari.net.au) Received: from localhost (peter@localhost) by dana.clari.net.au (8.8.7/8.8.7) with SMTP id TAA11586; Mon, 8 Jun 1998 19:58:36 +1000 (EST) (envelope-from peter@clari.net.au) X-Authentication-Warning: dana.clari.net.au: peter owned process doing -bs Date: Mon, 8 Jun 1998 19:58:34 +1000 (EST) From: Peter Hawkins To: Heikki Suonsivu cc: Peter Hawkins , freebsd-bugs@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG Subject: Re: bin/4599 In-Reply-To: <13690.63746.682220.142200@katiska.clinet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm happy to reopen if you can show there is a bug, ie give a case where mktemp(3) doesn't do what it is supposed to do according to the documentation but at present, either I misunderstand you or you've misread the documentation or you know of a document I have not seen... >I do not understand how mkdtemp would change anything related to my PR (it >does not help in rdist6 problem I reported). Neither it addresses the What's wrong with adding this to rdist?... #ifdef _FreeBSD_ mkdtemp(... #else mktemp(... #endif from mktemp(3): The mktemp() function returns a pointer to the template on success and NULL on failure. ^^^^^^^^^^^^^^^ [snip] The mktemp() and mkstemp() functions may set errno to one of the following values: [ENOTDIR] The pathname portion of the template is not an existing directory. Isn't this what it is in fact doing in your case? >problem I described. mktemp is not supposed to fall over when the path It doesn't "fall over" - it returns NULL (correctly). rdist(6) uses _PATH_TMP to place the temp file which should not be modified from /tmp. To cause rdist to fail, you have to modify _PATH_TMP or move /tmp and if you were to do that then a great many things (including vi) will fail. Perhaps you could request that rdist(6) detect the error and report it and abort (as vi does if you move your /tmp) but this does not constitute a bug. The parameter to mktemp is also returned appropriately and is truncated at the end of the path stem when there is no path. It isn't over-written, just truncated and is a valid string. It's up to the programmer to check for a NULL return and abort. If the programmer wishes to be able to create temp files in potentially non-existent locations then he/she can use mkdtemp(3). rdist(6) uses a path that *should* exist on all machines by definition (_PATH_TMP - a system-wide define). You have to break your machine to make this call fail in the way you described. >being created does not exist, as it is supposed to create a path name, not mktemp() is *supposed* to return a NULL when the directory portion is a non existent directory. If you wish to create a path, you use mkdtemp. There is no reference in the documentation to it creating a path. Where did you see that? >a directory, file or anything else. Please reopen this until the actual >bug is fixed. So far as I can see, there isn't a bug - the call behaves as described and there is a separate call for full path creation which was recently added. mktemp(3) should (and does) return NULL when requested to create a file in a non existent directory. Perhaps I am misunderstanding what you are saying? Thankyou for your feedback and, as I said, if I've misunderstood you I'm happy not only to reopen, but to fix it. My problem at the present is that I can't see exactly what it is that mktemp(3) does that it shouldn't (at least according to its documentation - I admit I haven't gone and checked any of the standards documents). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message