Date: Mon, 8 Jun 1998 13:50:58 +0300 (EEST) From: Heikki Suonsivu <hsu@clinet.fi> To: Peter Hawkins <peter@clari.net.au> Cc: Heikki Suonsivu <hsu@clinet.fi>, Peter Hawkins <thepish@FreeBSD.ORG>, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/4599 Message-ID: <13691.49682.498719.688203@katiska.clinet.fi> In-Reply-To: <Pine.BSF.3.96.980608130905.9478A-100000@dana.clari.net.au> References: <13690.63746.682220.142200@katiska.clinet.fi> <Pine.BSF.3.96.980608130905.9478A-100000@dana.clari.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Hawkins writes:
> 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
Do we really need yet another difference to the other world ?
> 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.
This is what I get from man 3 mktemp :
The mkstemp() and mkdtemp() functions may set errno to one of the follow-
ing values:
[ENOTDIR] The pathname portion of the template is not an existing direc-
tory.
mktemp is not mentioned here.
You may be looking at netbsd mktemp manual page, which has the text you are
quoting ?
> 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.
No it does not use _PATH_TMP. If you do not bother to read the code before
closing the related PRs, at least you could trust someone who did.
rdistd (rdist6) takes the path for the file it is creating, snips the
filename out, and adds a string to this path, and calls mktemp for that
string, ie. if it is copying /usr/local/bin/foobar, it will make a string
/usr/local/bin/.rdistdXXXXXX and call mktemp to make this string unique.
Then it calls a function to generate the directories it needs, if any are
missing. All this seems to be logical and correct way of doing this.
Notice it is not creating a temporary directory, but the missing directory
contained in the path name of the file it is copying over.
You cannot put this temporary file to /tmp, because rdist6 is supposed to
link/unlink/rename the file to replace the original file, and this one
cannot do over filesystem boundaries.
mkdtemp says "creates the template directory". It does not say it takes a
path and creates all necessary directories on the path. That might be a
useful feature, but if it does that, but it is not obvious from the manual
page.
> >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?
Reread the line you quoted. It is supposed to create a path name, not
path. Path name is a string of characters. Originally mktemp worked that
way, current way it works is something new, as old programs seem to trust
the old behaviour.
> >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).
Maybe the standard documents would be the best reference. If standards do
not define how it should work, then it should work like it has always
worked to maintain compatibility.
> Peter
--
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND, hsu@clinet.fi
mobile +358-40-5519679 work +358-9-43542270 fax -4555276
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13691.49682.498719.688203>