You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by David Reid <dr...@jetnet.co.uk> on 2002/12/09 16:21:58 UTC
Re: [time to move on I guess] APR_TMP_DIRECTORY
> > > Fine, then suggest another method for developers to find a system temp
> > > directory so that they can create a valid mask for use in
> > > apr_file_mktemp.
> >
> > If they need more than a tmp file handle with a clear contract; i.e.
> > something like pseudo temporarly storage with semantics specific to
their
> > application; then they'd better create an *application* level config or
> > policy for that; with clearly documented requirements (such as max size,
> > livetime, mostly read or mostly write permissions, cleanup (or not) on
> > exit of the application or reboot, etc).
>
> Great job at ducking the question. It is really simple. The application
> needs to create a temporary file. To do so, it would like to find a
> directory that houses temporary files so that if something happens, it can
> be deleted automatically with a cron job. So, the developer is going to
> use apr_file_mktemp, which will return a file handle. Now, what template
> does the developer pass in to that program to ensure that the file ends up
> in the correct directory? Do we just always use a well known temp
> directory if they pass in a relative file? I sure as hell hope not.
>
> You are asking us to solve a problem but then saying that we can't solve
> it completely. This is a bogus conversation and I am done with it.
Yep, this whole thread started off real simple and has gotten totally out of
hand. If apr doesn't want to provide this functionality then we shoudl just
say so rather than trying to answer questions that haven't been asked.
Anyway, I've had enough of this as well. Sorry to the subversion guys but I
tried...
david
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
Thanks Brane... this was very well stated.
Bill
At 01:32 AM 12/11/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>Dirk-Willem van Gulik wrote:
>
>>On 9 Dec 2002 cmpilato@collab.net wrote:
>>
>>
>>>This *is* a portability question.
>>>
>>>
>>
>>Well this is the crux- I think that this going further than abstracting
>>what the OS offer; but trying to put a layer on what a specific machine
>>offers or a specific operations environment.
>>
>>
>>
>>>It *is* inside the domain of the portability layer. It *does* belong in
>>>APR.
>>>
>>>
>>
>>Therefore it it is my strong opinion that this is outside the domain of
>>portability and therefore should not be part of APR.
>>
>>Anything which does more than abstracting the pure OS but touches on an
>>instance of it I see as bad.
>>
>
>I'm getting the feeling that you don't understand what people are
>saying. Most OSes I know have the notion of a (configurable) temporary
>directory. For the purpose of brevity, I'll only mention two families:
>On Unix, you have the standard $TMPDIR,/var/tmp,/tmp search sequence. On
>Windows, it's %TEMP%,%TMP%,%SystemRoot%\TEMP. Windows also has a
>GetTempPath() function, that returns a user- or app-specific temporary
>directory name. On Unix, _all_ three locations can be tailored for your
>application, either by setting the environment variable, or by locking
>the app into a chroot jail and mounting /tmp or /var/tmp appropriately.
>On Windows the path can be set per-program.
>
>What we'd like to see in APR is not something above and beyond what the
>underlying OS already provides; only a portable interface to those
>facilities. There's a very strong argument in favour of putting this
>into APR -- we can make sure that our implementation behaves correctly
>on each target OS, which is something you can't expect of homegrown
>solutions, as you've been saying yourself.
>
>If you're worried about apps not behaving nicely -- why, if APR doesn't
>provide the APIs, people will just go ahead and use the non-portable OS
>functions, or worse, think up their own. From a sysadmin's point of
>view, there will be absolutely _no_ difference; bad programmers will
>behave antisocially whether or not APR provides the portability layer.
>
>The ony one who loses not having this feature in APR is the responsible
>programmer who would _like_ to use a portable API, but can't. Now that
>ain't nice.
>
>--
>Brane Äibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by Branko Čibej <br...@xbc.nu>.
David Reid wrote:
>Yeah nice thought but it's been vetoed by quite a few folks. You do read the
>same list I do don't you? :)
>
Sorry? I haven't seen a single veto. All I've seen is some (admittedly
heated) discussion, and no reply yet from Dirk-Willem (who seems to
oppose this addition the most) to my arguments in
<3D...@xbc.nu> and proposal in <3D...@xbc.nu>.
Perhaps I'm blind.
No, I'm not going to call for a vote. If anyone wants to call a veto on
technical grounds, they should speak up.
(BTW, accompanying the implementation of that proposal with a discussion
in the docs of safe usage of scratch directories would, in my opinion,
be a Good Thing.)
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by David Reid <dr...@jetnet.co.uk>.
Yeah nice thought but it's been vetoed by quite a few folks. You do read the
same list I do don't you? :)
david
----- Original Message -----
From: "Branko Čibej" <br...@xbc.nu>
To: "David Reid" <dr...@jetnet.co.uk>; "APR Dev List" <de...@apr.apache.org>
Sent: Tuesday, December 17, 2002 1:19 AM
Subject: Re: [time to move on I guess] APR_TMP_DIRECTORY
> David Reid wrote:
>
> >Actually my memory is that we don't any form of agreement on how this
should
> >be implemented or even what problem the discussion was trying to solve -
> >that's why I haven't written anything yet. I was all set to write the
code
> >but the discussion and feeling expressed mean I won't now.
> >
> >It'll be nice if we ever do it as it means that apache might build on
beos
> >again :)
> >
> >
>
> O.K., let's restate what we want:
>
> 1) A function that creates and opens a temporary file, accepting a
> template name.
>
> We have that, it's called apr_file_mktemp.
>
> 2) A function that gives us the name of a directory where temporary
> files may be created; this name would be used to create template names
> for apr_file_mktemp.
>
> We don't have that, but need it. Applying the keep-it-simple
> principle, the definitiona would be
>
> const char *apr_filepath_temp_dir_get (apr_pool_t *pool);
>
> The implementation should use any system-specific APIs and/or
> conventions to find a directory that a) is customarily used for
> creating temporary files, and b) is writable by the current process.
> We /may/ want to qualify if the temp dir should be such that files
> in it survive a reboot or not.
>
>
> 3) [I'm not sure we need this, but I'm adding it for completeness] A
> function that creates a temporary directory, accepting a template name.
>
> This would be symmetric to apr_file_mktemp:
>
> apr_status_t apr_dir_mktemp (const char **real_name,
> const char *templ,
> apr_int32_t flags,
> apr_pool_t *pool);
>
>
> It would use the same method as apr_file_mktemp to create a unique
> name, then create the directory and return that name. Unlike
> apr_file_mktemp, it would not automaticlaly remove the directory, of
> course. The caller must still use apr_filepath_temp_dir_get to
> create the template for a name that's within the temporary directory.
>
>
> There. The implementation is an exercise for the reader. I volunteer to
> write the Windows-specific apr_filepath_temp_dir_get when the time comes.
>
> --
> Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
>
>
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by Wilfredo Sánchez <ws...@wsanchez.net>.
Thanks, Brane.
David, I apologize if I contributed to discouraging you from coding.
At the risk of repeating that mistake, I thought of something today I
thought I'd share. :-)
The SVN folks pointed out that we don't have a way of getting a file
name back for the temp file created by apr_file_mktemp(), because it
just gives you the file handle. It was suggested that we need another
function for that.
It dawns on me that it might be way cool if apr_file_mktemp() could
give you back both a filehandle and optionally the file name, so that
you get the name, but it can still also create the file for you and
avoid the race condition between getting the name and opening the file.
We wouldn't be able to implement it with mkstemp() any more, though.
-wsv
On Monday, December 16, 2002, at 05:19 PM, Branko Čibej wrote:
> David Reid wrote:
>
>> Actually my memory is that we don't any form of agreement on how this
>> should
>> be implemented or even what problem the discussion was trying to
>> solve -
>> that's why I haven't written anything yet. I was all set to write the
>> code
>> but the discussion and feeling expressed mean I won't now.
>>
>> It'll be nice if we ever do it as it means that apache might build on
>> beos
>> again :)
>>
>>
>
> O.K., let's restate what we want:
>
> 1) A function that creates and opens a temporary file, accepting a
> template name.
>
> We have that, it's called apr_file_mktemp.
>
> 2) A function that gives us the name of a directory where temporary
> files may be created; this name would be used to create template names
> for apr_file_mktemp.
>
> We don't have that, but need it. Applying the keep-it-simple
> principle, the definitiona would be
>
> const char *apr_filepath_temp_dir_get (apr_pool_t *pool);
>
> The implementation should use any system-specific APIs and/or
> conventions to find a directory that a) is customarily used for
> creating temporary files, and b) is writable by the current
> process.
> We /may/ want to qualify if the temp dir should be such that files
> in it survive a reboot or not.
>
>
> 3) [I'm not sure we need this, but I'm adding it for completeness] A
> function that creates a temporary directory, accepting a template name.
>
> This would be symmetric to apr_file_mktemp:
>
> apr_status_t apr_dir_mktemp (const char **real_name,
> const char *templ,
> apr_int32_t flags,
> apr_pool_t *pool);
>
>
> It would use the same method as apr_file_mktemp to create a unique
> name, then create the directory and return that name. Unlike
> apr_file_mktemp, it would not automaticlaly remove the directory,
> of
> course. The caller must still use apr_filepath_temp_dir_get to
> create the template for a name that's within the temporary
> directory.
>
>
> There. The implementation is an exercise for the reader. I volunteer to
> write the Windows-specific apr_filepath_temp_dir_get when the time
> comes.
>
> --
> Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by Branko Čibej <br...@xbc.nu>.
David Reid wrote:
>Actually my memory is that we don't any form of agreement on how this should
>be implemented or even what problem the discussion was trying to solve -
>that's why I haven't written anything yet. I was all set to write the code
>but the discussion and feeling expressed mean I won't now.
>
>It'll be nice if we ever do it as it means that apache might build on beos
>again :)
>
>
O.K., let's restate what we want:
1) A function that creates and opens a temporary file, accepting a
template name.
We have that, it's called apr_file_mktemp.
2) A function that gives us the name of a directory where temporary
files may be created; this name would be used to create template names
for apr_file_mktemp.
We don't have that, but need it. Applying the keep-it-simple
principle, the definitiona would be
const char *apr_filepath_temp_dir_get (apr_pool_t *pool);
The implementation should use any system-specific APIs and/or
conventions to find a directory that a) is customarily used for
creating temporary files, and b) is writable by the current process.
We /may/ want to qualify if the temp dir should be such that files
in it survive a reboot or not.
3) [I'm not sure we need this, but I'm adding it for completeness] A
function that creates a temporary directory, accepting a template name.
This would be symmetric to apr_file_mktemp:
apr_status_t apr_dir_mktemp (const char **real_name,
const char *templ,
apr_int32_t flags,
apr_pool_t *pool);
It would use the same method as apr_file_mktemp to create a unique
name, then create the directory and return that name. Unlike
apr_file_mktemp, it would not automaticlaly remove the directory, of
course. The caller must still use apr_filepath_temp_dir_get to
create the template for a name that's within the temporary directory.
There. The implementation is an exercise for the reader. I volunteer to
write the Windows-specific apr_filepath_temp_dir_get when the time comes.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by David Reid <dr...@jetnet.co.uk>.
Actually my memory is that we don't any form of agreement on how this should
be implemented or even what problem the discussion was trying to solve -
that's why I haven't written anything yet. I was all set to write the code
but the discussion and feeling expressed mean I won't now.
It'll be nice if we ever do it as it means that apache might build on beos
again :)
david
----- Original Message -----
From: "Greg Stein" <gs...@lyra.org>
To: <de...@apr.apache.org>
Sent: Friday, December 13, 2002 12:05 AM
Subject: Re: [time to move on I guess] APR_TMP_DIRECTORY
> I'm with OtherBill: well said.
>
> Do we have some code for this? Can we just get it checked in already?
We've
> got enough +1 votes for the new feature, and I haven't seen any vetoes on
> the implementation of the feature, so let's just do the code...
>
> Cheers,
> -g
>
> On Wed, Dec 11, 2002 at 08:32:22AM +0100, Branko Cibej wrote:
> >...
> > I'm getting the feeling that you don't understand what people are
> > saying. Most OSes I know have the notion of a (configurable) temporary
> > directory. For the purpose of brevity, I'll only mention two families:
> > On Unix, you have the standard $TMPDIR,/var/tmp,/tmp search sequence. On
> > Windows, it's %TEMP%,%TMP%,%SystemRoot%\TEMP. Windows also has a
> > GetTempPath() function, that returns a user- or app-specific temporary
> > directory name. On Unix, _all_ three locations can be tailored for your
> > application, either by setting the environment variable, or by locking
> > the app into a chroot jail and mounting /tmp or /var/tmp appropriately.
> > On Windows the path can be set per-program.
> >
> > What we'd like to see in APR is not something above and beyond what the
> > underlying OS already provides; only a portable interface to those
> > facilities. There's a very strong argument in favour of putting this
> > into APR -- we can make sure that our implementation behaves correctly
> > on each target OS, which is something you can't expect of homegrown
> > solutions, as you've been saying yourself.
> >
> > If you're worried about apps not behaving nicely -- why, if APR doesn't
> > provide the APIs, people will just go ahead and use the non-portable OS
> > functions, or worse, think up their own. From a sysadmin's point of
> > view, there will be absolutely _no_ difference; bad programmers will
> > behave antisocially whether or not APR provides the portability layer.
> >
> > The ony one who loses not having this feature in APR is the responsible
> > programmer who would _like_ to use a portable API, but can't. Now that
> > ain't nice.
> >
> > --
> > Brane Cibej <br...@xbc.nu> http://www.xbc.nu/brane/
>
> --
> Greg Stein, http://www.lyra.org/
>
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by cm...@collab.net.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> Karl Fogel <kf...@newton.ch.collab.net> writes:
> > It's just been waiting on Mike Pilato (or someone) having enough time
> > to implement it now, that's all. No procedural holdups remain,
> > agreed.
> >
> > -Karl, speaking for Mike, who is perfectly capable of speaking for
> > himself, but it's me checking email right now, not Mike :-).
>
> Heh, or maybe I shouldn't have spoken at all -- the Subversion issue
> that I was thinking of is, in fact, unassigned at the moment, and
> wasn't directly relevant anyway.
Interesting. I thought it was assigned to me.
> Mike or Greg, do you remember exactly what spurred this whole
> discussion? I'm drawing a total blank at the moment, but if we know,
> then we know when we'll need this APR functionality by.
It started when a non-Subversion person asked "how can I figure out
the temp dir?" and I chimed in with, "Yeah, we'd like to know the same
thing."
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> It's just been waiting on Mike Pilato (or someone) having enough time
> to implement it now, that's all. No procedural holdups remain,
> agreed.
>
> -Karl, speaking for Mike, who is perfectly capable of speaking for
> himself, but it's me checking email right now, not Mike :-).
Heh, or maybe I shouldn't have spoken at all -- the Subversion issue
that I was thinking of is, in fact, unassigned at the moment, and
wasn't directly relevant anyway.
Mike or Greg, do you remember exactly what spurred this whole
discussion? I'm drawing a total blank at the moment, but if we know,
then we know when we'll need this APR functionality by.
-K
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> I'm with OtherBill: well said.
>
> Do we have some code for this? Can we just get it checked in already? We've
> got enough +1 votes for the new feature, and I haven't seen any vetoes on
> the implementation of the feature, so let's just do the code...
It's just been waiting on Mike Pilato (or someone) having enough time
to implement it now, that's all. No procedural holdups remain,
agreed.
-Karl, speaking for Mike, who is perfectly capable of speaking for
himself, but it's me checking email right now, not Mike :-).
> On Wed, Dec 11, 2002 at 08:32:22AM +0100, Branko Cibej wrote:
> >...
> > I'm getting the feeling that you don't understand what people are
> > saying. Most OSes I know have the notion of a (configurable) temporary
> > directory. For the purpose of brevity, I'll only mention two families:
> > On Unix, you have the standard $TMPDIR,/var/tmp,/tmp search sequence. On
> > Windows, it's %TEMP%,%TMP%,%SystemRoot%\TEMP. Windows also has a
> > GetTempPath() function, that returns a user- or app-specific temporary
> > directory name. On Unix, _all_ three locations can be tailored for your
> > application, either by setting the environment variable, or by locking
> > the app into a chroot jail and mounting /tmp or /var/tmp appropriately.
> > On Windows the path can be set per-program.
> >
> > What we'd like to see in APR is not something above and beyond what the
> > underlying OS already provides; only a portable interface to those
> > facilities. There's a very strong argument in favour of putting this
> > into APR -- we can make sure that our implementation behaves correctly
> > on each target OS, which is something you can't expect of homegrown
> > solutions, as you've been saying yourself.
> >
> > If you're worried about apps not behaving nicely -- why, if APR doesn't
> > provide the APIs, people will just go ahead and use the non-portable OS
> > functions, or worse, think up their own. From a sysadmin's point of
> > view, there will be absolutely _no_ difference; bad programmers will
> > behave antisocially whether or not APR provides the portability layer.
> >
> > The ony one who loses not having this feature in APR is the responsible
> > programmer who would _like_ to use a portable API, but can't. Now that
> > ain't nice.
> >
> > --
> > Brane Cibej <br...@xbc.nu> http://www.xbc.nu/brane/
>
> --
> Greg Stein, http://www.lyra.org/
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by rb...@apache.org.
On Thu, 12 Dec 2002, Greg Stein wrote:
> I'm with OtherBill: well said.
>
> Do we have some code for this? Can we just get it checked in already? We've
> got enough +1 votes for the new feature, and I haven't seen any vetoes on
> the implementation of the feature, so let's just do the code...
++1. Whoever writes the code, please remember to add some tests for it.
:-)
Ryan
>
> Cheers,
> -g
>
> On Wed, Dec 11, 2002 at 08:32:22AM +0100, Branko Cibej wrote:
> >...
> > I'm getting the feeling that you don't understand what people are
> > saying. Most OSes I know have the notion of a (configurable) temporary
> > directory. For the purpose of brevity, I'll only mention two families:
> > On Unix, you have the standard $TMPDIR,/var/tmp,/tmp search sequence. On
> > Windows, it's %TEMP%,%TMP%,%SystemRoot%\TEMP. Windows also has a
> > GetTempPath() function, that returns a user- or app-specific temporary
> > directory name. On Unix, _all_ three locations can be tailored for your
> > application, either by setting the environment variable, or by locking
> > the app into a chroot jail and mounting /tmp or /var/tmp appropriately.
> > On Windows the path can be set per-program.
> >
> > What we'd like to see in APR is not something above and beyond what the
> > underlying OS already provides; only a portable interface to those
> > facilities. There's a very strong argument in favour of putting this
> > into APR -- we can make sure that our implementation behaves correctly
> > on each target OS, which is something you can't expect of homegrown
> > solutions, as you've been saying yourself.
> >
> > If you're worried about apps not behaving nicely -- why, if APR doesn't
> > provide the APIs, people will just go ahead and use the non-portable OS
> > functions, or worse, think up their own. From a sysadmin's point of
> > view, there will be absolutely _no_ difference; bad programmers will
> > behave antisocially whether or not APR provides the portability layer.
> >
> > The ony one who loses not having this feature in APR is the responsible
> > programmer who would _like_ to use a portable API, but can't. Now that
> > ain't nice.
> >
> > --
> > Brane Cibej <br...@xbc.nu> http://www.xbc.nu/brane/
>
> --
> Greg Stein, http://www.lyra.org/
>
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by Greg Stein <gs...@lyra.org>.
I'm with OtherBill: well said.
Do we have some code for this? Can we just get it checked in already? We've
got enough +1 votes for the new feature, and I haven't seen any vetoes on
the implementation of the feature, so let's just do the code...
Cheers,
-g
On Wed, Dec 11, 2002 at 08:32:22AM +0100, Branko Cibej wrote:
>...
> I'm getting the feeling that you don't understand what people are
> saying. Most OSes I know have the notion of a (configurable) temporary
> directory. For the purpose of brevity, I'll only mention two families:
> On Unix, you have the standard $TMPDIR,/var/tmp,/tmp search sequence. On
> Windows, it's %TEMP%,%TMP%,%SystemRoot%\TEMP. Windows also has a
> GetTempPath() function, that returns a user- or app-specific temporary
> directory name. On Unix, _all_ three locations can be tailored for your
> application, either by setting the environment variable, or by locking
> the app into a chroot jail and mounting /tmp or /var/tmp appropriately.
> On Windows the path can be set per-program.
>
> What we'd like to see in APR is not something above and beyond what the
> underlying OS already provides; only a portable interface to those
> facilities. There's a very strong argument in favour of putting this
> into APR -- we can make sure that our implementation behaves correctly
> on each target OS, which is something you can't expect of homegrown
> solutions, as you've been saying yourself.
>
> If you're worried about apps not behaving nicely -- why, if APR doesn't
> provide the APIs, people will just go ahead and use the non-portable OS
> functions, or worse, think up their own. From a sysadmin's point of
> view, there will be absolutely _no_ difference; bad programmers will
> behave antisocially whether or not APR provides the portability layer.
>
> The ony one who loses not having this feature in APR is the responsible
> programmer who would _like_ to use a portable API, but can't. Now that
> ain't nice.
>
> --
> Brane Cibej <br...@xbc.nu> http://www.xbc.nu/brane/
--
Greg Stein, http://www.lyra.org/
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by Branko Čibej <br...@xbc.nu>.
Dirk-Willem van Gulik wrote:
>On 9 Dec 2002 cmpilato@collab.net wrote:
>
>
>>This *is* a portability question.
>>
>>
>
>Well this is the crux- I think that this going further than abstracting
>what the OS offer; but trying to put a layer on what a specific machine
>offers or a specific operations environment.
>
>
>
>>It *is* inside the domain of the portability layer. It *does* belong in
>>APR.
>>
>>
>
>Therefore it it is my strong opinion that this is outside the domain of
>portability and therefore should not be part of APR.
>
>Anything which does more than abstracting the pure OS but touches on an
>instance of it I see as bad.
>
I'm getting the feeling that you don't understand what people are
saying. Most OSes I know have the notion of a (configurable) temporary
directory. For the purpose of brevity, I'll only mention two families:
On Unix, you have the standard $TMPDIR,/var/tmp,/tmp search sequence. On
Windows, it's %TEMP%,%TMP%,%SystemRoot%\TEMP. Windows also has a
GetTempPath() function, that returns a user- or app-specific temporary
directory name. On Unix, _all_ three locations can be tailored for your
application, either by setting the environment variable, or by locking
the app into a chroot jail and mounting /tmp or /var/tmp appropriately.
On Windows the path can be set per-program.
What we'd like to see in APR is not something above and beyond what the
underlying OS already provides; only a portable interface to those
facilities. There's a very strong argument in favour of putting this
into APR -- we can make sure that our implementation behaves correctly
on each target OS, which is something you can't expect of homegrown
solutions, as you've been saying yourself.
If you're worried about apps not behaving nicely -- why, if APR doesn't
provide the APIs, people will just go ahead and use the non-portable OS
functions, or worse, think up their own. From a sysadmin's point of
view, there will be absolutely _no_ difference; bad programmers will
behave antisocially whether or not APR provides the portability layer.
The ony one who loses not having this feature in APR is the responsible
programmer who would _like_ to use a portable API, but can't. Now that
ain't nice.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Dirk-Willem van Gulik <di...@webweaving.org> writes:
> Anything which does more than abstracting the pure OS but touches on an
> instance of it I see as bad. And yes - if you draw the parallel to an
> almost ridiclious extend; I do think exactly the same when I see
> ./Configure picking things up such as my 'gdbm' in /usr/local/lib and run
> into trouble when I run the binary on the diskless machine an hour later.
So you configured/built on one environment, then ran the binary on
another environment? Maybe I'm missing something, but... why exactly
did you expect this to work? :-)
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 9 Dec 2002 cmpilato@collab.net wrote:
> sensible here, but I get this feeling that you're trying to push some
> sort of "programmer's best practices" policy agenda via crippling the
> portability layer.
Yes, absolutely, guilty as charged.
> This *is* a portability question.
Well this is the crux- I think that this going further than abstracting
what the OS offer; but trying to put a layer on what a specific machine
offers or a specific operations environment.
> It *is* inside the domain of the portability layer. It *does* belong in
> APR.
Therefore it it is my strong opinion that this is outside the domain of
portability and therefore should not be part of APR.
Anything which does more than abstracting the pure OS but touches on an
instance of it I see as bad. And yes - if you draw the parallel to an
almost ridiclious extend; I do think exactly the same when I see
./Configure picking things up such as my 'gdbm' in /usr/local/lib and run
into trouble when I run the binary on the diskless machine an hour later.
> And heck, you can compose the 2-page "why you shouldn't use this" and
> stick in the header file yourself if you'd like.
Should it ever end up in APR - you bet I will :-) as it concerns me
deeply; and I've been bitten by this problem too many times.
Dw.
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by cm...@collab.net.
Dirk-Willem van Gulik <di...@webweaving.org> writes:
> ...
> > its utilities, svnlook needs to create two temporary files to be used
> > by an external 'diff' process. Given only handles, we have no paths
>
> But the svnlook lives longer than the diff process ? Or do you -also-
> postulate something like a 'crontab' which deletes cruft in case of
> accidents ?
In the case of accidents that cause svnlook itself to fail to cleanup
the tmpfiles (in both success and error cases), you can be sure that
some junk is left around. Some externel mechanism must then clean
that stuff up. What's a program to do?
> > to provide to that 'diff' process. CVS gets around this by using an
> ....
> > Now, most of Subversion's operations require a working copy, so we
> > make our tempfiles in the .svn/tmp/ directory in those cases. But we
> ...
> > across the network, with no working copy (and therefore no guaranteed
> > user-writable place to put tempfiles).
>
> Aye - well in that case I would personally would really want to have this
> done on application level and under operator control - as the associated
> environment (especially if you have thousands of accounts/connections to
> worry about) will often require extensive fitting to the maintenance
> model. It's a shame Unix, like windows, has no global registry :-)
Dirk, this is *ridiculous*. I'm sorry, I really am trying to be
sensible here, but I get this feeling that you're trying to push some
sort of "programmer's best practices" policy agenda via crippling the
portability layer. Sure, Subversion could implement the
get_temp_dir() function and use it. But I guarantee that other
programs will have similar situations that require this functionality,
will expect it in the portability layer, will understand the security
consequences of taking this route, and will (now) be forced to
implement the same thing.
This *is* a portability question. It *is* inside the domain of the
portability layer. It *does* belong in APR. And heck, you can
compose the 2-page "why you shouldn't use this" and stick in the
header file yourself if you'd like.
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 9 Dec 2002 cmpilato@collab.net wrote:
...
> its utilities, svnlook needs to create two temporary files to be used
> by an external 'diff' process. Given only handles, we have no paths
But the svnlook lives longer than the diff process ? Or do you -also-
postulate something like a 'crontab' which deletes cruft in case of
accidents ?
> to provide to that 'diff' process. CVS gets around this by using an
....
> Now, most of Subversion's operations require a working copy, so we
> make our tempfiles in the .svn/tmp/ directory in those cases. But we
...
> across the network, with no working copy (and therefore no guaranteed
> user-writable place to put tempfiles).
Aye - well in that case I would personally would really want to have this
done on application level and under operator control - as the associated
environment (especially if you have thousands of accounts/connections to
worry about) will often require extensive fitting to the maintenance
model. It's a shame Unix, like windows, has no global registry :-)
Dw
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by cm...@collab.net.
Dirk-Willem van Gulik <di...@webweaving.org> writes:
> On 9 Dec 2002 cmpilato@collab.net wrote:
>
> > Wow... so our 'svnlook' utility needs to grow config file support or
> > some unwieldy --with-tmp cmdline argument just because the portability
> > layer doesn't want to answer a single portability question.
>
> As you cannot use tmp file (handles) ?
Correct. In this one of several uses of tmpfiles in Subversion and
its utilities, svnlook needs to create two temporary files to be used
by an external 'diff' process. Given only handles, we have no paths
to provide to that 'diff' process. CVS gets around this by using an
internal diff library -- no such BSD-compatible thing exists that we
know of, though Sander Striker has been working off and on at writing
one from scratch.
Another use of temp files is with user's log messages. You know how
CVS will, if a commit fails, keep your log message around in a
temporary file, and tell you something like "Hey, your commit failed,
but that log message you spent 10 minutes composing is over here in
/tmp/cvs121234.tmp". Subversion is doing the same thing. When your
$EDITOR pops up so you can compose your log message, it needs a
temporary file to act on. Again, a handle alone can't be provided on
the commandline to your $EDITOR. Even if we could pass a handle to
the editor, after you close your editor, we *don't* want that tempfile
to disappear, because we have to read that file back in to use as part
of the commit process. And we want the file to persist until we have
a chance to clean it up.
Now, most of Subversion's operations require a working copy, so we
make our tempfiles in the .svn/tmp/ directory in those cases. But we
have several commands that act directly on the repository all the way
across the network, with no working copy (and therefore no guaranteed
user-writable place to put tempfiles).
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 9 Dec 2002 cmpilato@collab.net wrote:
> Wow... so our 'svnlook' utility needs to grow config file support or
> some unwieldy --with-tmp cmdline argument just because the portability
> layer doesn't want to answer a single portability question.
As you cannot use tmp file (handles) ?
DW
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by cm...@collab.net.
Dirk-Willem van Gulik <di...@webweaving.org> writes:
> > Anyway, I've had enough of this as well. Sorry to the subversion guys but I
> > tried...
>
> I honestly thing that if the Subversion guys make their 'Temp' directory
> configurable on application level (and document the use semantics: volume,
> xs-permission, mostly read, mostly write, NO socket/shar-mem files or
> other aspects) that their application will only benefit from an operations
> perspective - and that ultimately they have made a better application than
> when they would defer to the bowels of APR to make a guess as what 'temp'
> means for them.
Wow... so our 'svnlook' utility needs to grow config file support or
some unwieldy --with-tmp cmdline argument just because the portability
layer doesn't want to answer a single portability question.
Interesting...
Re: [time to move on I guess] APR_TMP_DIRECTORY
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> > You are asking us to solve a problem but then saying that we can't solve
> > it completely. This is a bogus conversation and I am done with it.
>
> Yep, this whole thread started off real simple and has gotten totally out of
> hand.
That is because the problem/notion of a Temp directory as opposed to a
temp file (handle) is a very complex and hairy one. With lots of
operational ramfications when used by more than one app. And one which
IMHO clashes with the very notion of portability.
> If apr doesn't want to provide this functionality then we shoudl just
> say so
+1 to saying so.
> Rather than trying to answer questions that haven't been asked.
> Anyway, I've had enough of this as well. Sorry to the subversion guys but I
> tried...
I honestly thing that if the Subversion guys make their 'Temp' directory
configurable on application level (and document the use semantics: volume,
xs-permission, mostly read, mostly write, NO socket/shar-mem files or
other aspects) that their application will only benefit from an operations
perspective - and that ultimately they have made a better application than
when they would defer to the bowels of APR to make a guess as what 'temp'
means for them.
Dw