At 09:26 AM 12/9/2002, Dirk-Willem van Gulik wrote:
>No - I maitain that APR should -NOT- solve the problem of abstracting
>retrieval of the name of a tmp directory
What you are maintaining is that APR should not handle the platform
ambiguities of where TMP files should be stored on a given platf
> Great job at ducking the question. It is really simple. The application
> needs to create a temporary file.
I think we agree on this. APR already does this; libc has done this for a
long time.
Solet it do that; preferably using the file descriptor; tmpfile() name
which has a very clear contr
On Mon, 9 Dec 2002, Dirk-Willem van Gulik wrote:
>
> > 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 li
On Mon, 9 Dec 2002, Dirk-Willem van Gulik wrote:
>
>
> On Mon, 9 Dec 2002, Aaron Bannert wrote:
>
> ..cut...
> > Are they lock files, mmap/shared-mem files,
>
> Now -these- I would dearly love to see 'disappear' inside APR.
Which amazingly enough all exist inside APR already.
Ryan
HI all,
Not to add more oil on the fire, but is it maybe not
a reasonable solution
- to do the portability parts in only APR and
- use APR-UTIL for higher level application functionality
(like getting a temp dir from an enviornment variable) ??
This could solve all purposes:
1) application d
On Mon, 9 Dec 2002, Aaron Bannert wrote:
..cut...
> Are they lock files, mmap/shared-mem files,
Now -these- I would dearly love to see 'disappear' inside APR.
Dw.
[I removed a bunch of people from the cc: list who were obviously
subscribers to this mailing list already]
On Sunday, December 8, 2002, at 02:18 PM, <[EMAIL PROTECTED]> wrote:
Fine, then suggest another method for developers to find a system temp
directory so that they can create a valid mask fo
> 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
ap
Seriously?
I must be completely in la la land, because I can't see how. It's
adding a function that's the same as the existing apr_file_mktemp(),
except it makes a directory instead. Add one more to return the system
temp directory. What am I missing? If that's overengineered, then so
i
Damn, I could have sworn this was an apr list!
How did we get from something very simple to this??? Fred, if you really
want to implement this then feel free, but this is a long wqay from what is
needed IMHO and smacks of overengineering :( .
david
>So I'm clear, here's what I suggest. Two
So I'm clear, here's what I suggest. Two new functions, one existing:
// Returns a valid scratch dir (system-defined, eg /tmp)
apr_status_t apr_file_get_temp_directory(char** path, apr_pool_t *p);
// Creates new file with a template, returns handle
// (This already exists in apr_file_io.h)
// (S
On Sun, 8 Dec 2002, Dirk-Willem van Gulik wrote:
>
> > No, that is a problem that YOU do not _need_ to solve. But, it is a
> > problem that other developers have stated they do need.
>
> Right - and I maintain that there are things best -not- done in a
> 'portability' layer. This is one of them
> No, that is a problem that YOU do not _need_ to solve. But, it is a
> problem that other developers have stated they do need.
Right - and I maintain that there are things best -not- done in a
'portability' layer. This is one of them.
..
> This is the first time that this support was requested
> > The only thing I would change, is I would drop it to three functions by
> > getting rid of apr_temp_get_unique. That function can be accounted
> > for by
> > passing NULL into apr_temp_get_filename for the directory. Also, the
> > apr_temp_get_unique really doesn't have anything to do with t
On Sun, 8 Dec 2002, Dirk-Willem van Gulik wrote:
> On Sun, 8 Dec 2002 [EMAIL PROTECTED] wrote:
>
> > GR.
>
> > Guys, please read all the messages. We HAVE that already! We have
>
> GRRR...
>
> > apr_file_mktemp, which returns an apr_file_t, but there are people saying
> > that it isn't
On Sunday, December 8, 2002, at 11:02 AM, <[EMAIL PROTECTED]> wrote:
Can you just implement please? There are three functions below,
between
those three functions and the existing apr_file_mktemp(), we can do
EVERYTHING that people are asking for.
What the hell's the big rush? We can talk and
On Sun, 8 Dec 2002 [EMAIL PROTECTED] wrote:
> GR.
> Guys, please read all the messages. We HAVE that already! We have
GRRR...
> apr_file_mktemp, which returns an apr_file_t, but there are people saying
> that it isn't enough. They want to be given a filename instead of a
> handle.
On Sun, 8 Dec 2002, Dirk-Willem van Gulik wrote:
>
>
> On Sun, 8 Dec 2002, [ISO-8859-1] Wilfredo Sánchez wrote:
>
> >Specifically, I think the API should return a filehandle, not a file
> > name, to avoid the race condition I mentioned. I think that's
> > worthwhile.
>
> +1 to that.
GR
On Sun, 8 Dec 2002, [ISO-8859-1] Wilfredo Sánchez wrote:
>Specifically, I think the API should return a filehandle, not a file
> name, to avoid the race condition I mentioned. I think that's
> worthwhile.
+1 to that.
Dw.
I'm not suggesting that we limit ourselves to the unix
implementation. I'm saying there exists an API that solves this
problem and that rather than plunging headlong into a new API that
looks good, we try to learn something some an API that's been around
the block.
Specifically, I think t
is back on topic so maybe some work can be
> done or are we turning into Jakarta???
>
> david
>
> - Original Message -
> From: "Wilfredo Sanchez" <[EMAIL PROTECTED]>
> To: "Apache Portable Runtime Developers"
> Sent: Saturday, December 07, 2002
avid
- Original Message -
From: "Wilfredo Sanchez" <[EMAIL PROTECTED]>
To: "Apache Portable Runtime Developers"
Sent: Saturday, December 07, 2002 7:36 AM
Subject: Re: APR_TMP_DIRECTORY
> On Wednesday, December 4, 2002, at 10:53 PM, David Reid wrote:
>
Wilfredo Sanchez wrote:
>
>Yes. What I'm saying is that to the degree there is a convention on
> Unix to use TMPDIR, that convention is to let the application decide
> whether to use it.
Agreed. It's up to the app to support it or not.
>
>That implies that the app should, if it wants
* Wilfredo Sanchez ([EMAIL PROTECTED]) wrote :
> On Saturday, December 7, 2002, at 01:56 PM, Jim Jagielski wrote:
>
> >Wilfredo Sanchez wrote:
>
> That implies that the app should, if it wants to, check for TMPDIR,
> and if not set, then call apr_get_tempdir(). Not to have
> apr_get_tempdir
On Saturday, December 7, 2002, at 01:56 PM, Jim Jagielski wrote:
Wilfredo Sanchez wrote:
I'm on the side that env vars appropriate to the platform should be
honored. But note that BSD Unix and I think POSIX do not dictate such
a variable. TMPDIR, if used, is used at the discretion of
applicat
Wilfredo Sanchez wrote:
>
>I'm on the side that env vars appropriate to the platform should be
> honored. But note that BSD Unix and I think POSIX do not dictate such
> a variable. TMPDIR, if used, is used at the discretion of
> applications, not by the system per-se, though it's not unco
(Had some trouble sending this mail. Sorry if it goes out >1 time.)
-wsv
On Wednesday, December 4, 2002, at 10:53 PM, David Reid wrote:
Actually I think we should have 3 new functions...
char *apr_temp_get_directory(apr_pool_t *)
char *apr_temp_get_filename(char *dir, char *suffix, apr_pool_t
On Wednesday, December 4, 2002, at 10:53 PM, David Reid wrote:
Actually I think we should have 3 new functions...
char *apr_temp_get_directory(apr_pool_t *)
char *apr_temp_get_filename(char *dir, char *suffix, apr_pool_t *)
char *apr_temp_get_unique(char *suffix, apr_pool_t *)
This gives us the ab
On Sat, 7 Dec 2002, Thom May wrote:
> How is the *portable* creation of temporary files a "function of dubious
> use"? Surely our mandate is portability. I'd argue that functionality like
> this should absolutely be in APR.
The portability layer is to facilitate porting; not to hide things whic
* Dirk-Willem van Gulik ([EMAIL PROTECTED]) wrote :
>
>
> On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote:
>
> > You are advocating that we use tempfile() to get a filename. At what
>
> No; I am advocating to -NOT- (or at least grudgingly) give the naive app
> develoepr the means to shoot the poor
On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote:
> You are advocating that we use tempfile() to get a filename. At what
No; I am advocating to -NOT- (or at least grudgingly) give the naive app
develoepr the means to shoot the poor operations guy in the foot by
providing the developer a function of
Dirk, I'm sorry, but you are not paying attention, and inflaming an
already heated discussion.
You are advocating that we use tempfile() to get a filename. At what
point in this discussion did we say we weren't going to do that? However,
that is a _UNIX_ solution, and it isn't portable. The di
On Fri, 6 Dec 2002, Dirk-Willem van Gulik wrote:
> On Thu, 5 Dec 2002, Aaron Bannert wrote:
>
> > I don't like the idea of having environment variables drive things like
> > this. Temp directories are a great way to get programs to write files
> > wherever you want. I'd much rather have a functi
Going back in the discussion; and looking at the code - what do we *need*
it for ? Is it just to construct effective replacements for the
tmpfile/tempnam /tmpnam trio ?
Or is there also a valid direct use of the name of that directory ?
As I certainly would like to not encourage the use of pseud
> Can a single temp directory be discovered by autoconf at build time and
> still apply for binary distributions? (Are there platforms where the
> same binary would work but the default temp dir might change?)
In any serious shop: Your run time system in production is generally !=
build system. A
Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes:
> > What's the hangup here? Every Unix I've ever seen, and every Windows
> > version I've ever seen, has a notion of a temporary directory.
>
> Sure - but where it is depends on the unix, wether you are using a
> secure/trusted unix, who you are
On 6 Dec 2002 [EMAIL PROTECTED] wrote:
> Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes:
>
> > On Thu, 5 Dec 2002, Aaron Bannert wrote:
> >
> > > I don't like the idea of having environment variables drive things like
> > > this. Temp directories are a great way to get programs to write files
Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes:
> On Thu, 5 Dec 2002, Aaron Bannert wrote:
>
> > I don't like the idea of having environment variables drive things like
> > this. Temp directories are a great way to get programs to write files
> > wherever you want. I'd much rather have a functi
> > Obviously, platforms that have a well-known temp directory could implement
> > their own apr_get_temp_dir to just return the correct string, but for
> > Unix platforms, there are three or four "correct" temp locations based on
> > platform and how the admin has things setup.
>
> True. That wou
On Wed, 4 Dec 2002, David Reid wrote:
> If we don't have such a declare maybe we should add one? I say this as
> htpasswd.c (in httpd) uses P_tmpdir that isn't portable and breaks the beos
> build. Also Thom found a note in his stdio.h file saying that it wasn't the
> right way to do things, and
On Thu, 5 Dec 2002, Aaron Bannert wrote:
> I don't like the idea of having environment variables drive things like
> this. Temp directories are a great way to get programs to write files
> wherever you want. I'd much rather have a function where the global
> tempdir can be set and then retrieved
--On Thursday, December 5, 2002 1:28 PM -0800 Aaron Bannert
<[EMAIL PROTECTED]> wrote:
are they consistent. Though, all of that is irrelevant because
allowing environment variables to define program behavior is totally
bogus [on systems I care about].
Oh, I'm sure you've never set EDITOR, SHELL,
<[EMAIL PROTECTED]> writes:
> Unless there is a much clearer explanation of why David's proposal
> shouldn't be used, we should go ahead and implement it.
+1 here.
On Thu, 5 Dec 2002, Aaron Bannert wrote:
>
> On Thursday, December 5, 2002, at 01:26 PM, <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, 5 Dec 2002, Aaron Bannert wrote:
> >> Can anyone think of a case where temp files on Unix do not belong in
> >> either 1) /tmp or 2) a user-defined location?
> >
>
On Thursday, December 5, 2002, at 01:26 PM, <[EMAIL PROTECTED]> wrote:
On Thu, 5 Dec 2002, Aaron Bannert wrote:
Can anyone think of a case where temp files on Unix do not belong in
either 1) /tmp or 2) a user-defined location?
I know of a couple of Unix platforms that use /var/tmp, yes. But more
On Thu, 5 Dec 2002, Aaron Bannert wrote:
>
> On Thursday, December 5, 2002, at 01:07 PM, <[EMAIL PROTECTED]> wrote:
> > What exactly is the argument against using the proposed API? That we
> > shouldn't use environment variables? The environment variables are a
> > mechanism that some platfor
On Thursday, December 5, 2002, at 01:07 PM, <[EMAIL PROTECTED]> wrote:
What exactly is the argument against using the proposed API? That we
shouldn't use environment variables? The environment variables are a
mechanism that some platforms use for locating the temp directory. To
ignore them woul
At 03:07 PM 12/5/2002, [EMAIL PROTECTED] wrote:
>If the application developer really doesn't want to
>use the native method for choosing the temp directory, then they don't
>have to. David's suggestion provided three APIs for generating a
>temporary file, one of them allows the user to provide a
On Thursday, December 5, 2002, at 12:33 PM, William A. Rowe, Jr. wrote:
Ok... here's how I see us finding common ground...
Add an apr_filepath_temp_set() that allows the developer to override
the temp path for an entire app; e.g. those apps which have a config
directive SetTempPath /zzz can suppor
On Thu, 5 Dec 2002, William A. Rowe, Jr. wrote:
> At 01:05 PM 12/5/2002, Aaron Bannert wrote:
>
> >On Thursday, December 5, 2002, at 10:43 AM, William A. Rowe, Jr. wrote:
> >>As a developer/administrator/user, I *really* get ticked off by those
> >>developers who don't respect my system-wide %T
At 01:05 PM 12/5/2002, Aaron Bannert wrote:
>On Thursday, December 5, 2002, at 10:43 AM, William A. Rowe, Jr. wrote:
>>As a developer/administrator/user, I *really* get ticked off by those
>>developers who don't respect my system-wide %TEMP%/%TMP%
>>assignments. This isn't just a personal choice
On 5 Dec 2002 [EMAIL PROTECTED] wrote:
> Aaron Bannert <[EMAIL PROTECTED]> writes:
>
> > I don't like the idea of having environment variables drive things
> > like this. Temp directories are a great way to get programs to
> > write files wherever you want. I'd much rather have a function where
On Thursday, December 5, 2002, at 10:43 AM, William A. Rowe, Jr. wrote:
As a developer/administrator/user, I *really* get ticked off by those
developers who don't respect my system-wide %TEMP%/%TMP%
assignments. This isn't just a personal choice, since on locked down
boxes or with apps installed
At 11:55 AM 12/5/2002, Aaron Bannert wrote:
>My main point here is that it is bad to use environment variables
>for such things, and it's probably bad to have to run something
>every time a temp dir is needed (like check permissions or search
>a list of paths and stat() each one). I'd much rather
On Thursday, December 5, 2002, at 09:38 AM, [EMAIL PROTECTED] wrote:
Aaron Bannert <[EMAIL PROTECTED]> writes:
I don't like the idea of having environment variables drive things
like this. Temp directories are a great way to get programs to
write files wherever you want. I'd much rather have a fu
Aaron Bannert <[EMAIL PROTECTED]> writes:
> I don't like the idea of having environment variables drive things
> like this. Temp directories are a great way to get programs to
> write files wherever you want. I'd much rather have a function where
> the global tempdir can be set and then retrieved
On Wednesday, December 4, 2002, at 10:50 AM, <[EMAIL PROTECTED]> wrote:
On Wed, 4 Dec 2002, David Reid wrote:
I propose that it would simply take the form of a define
#define APR_TMP_DIRECTORY "/var/tmp"
Haven't we discussed this before? I thought we had, and we had
decided to
come up with a hie
;Kevin Pilch-Bisson"
<[EMAIL PROTECTED]>; "Thom May" <[EMAIL PROTECTED]>; "APR Dev
List"
Sent: Wednesday, December 04, 2002 9:03 PM
Subject: Re: APR_TMP_DIRECTORY
>
>
> On 4 Dec 2002 [EMAIL PROTECTED] wrote:
>
> > Juan Rivera <[EMAIL PROTECTE
On 4 Dec 2002 [EMAIL PROTECTED] wrote:
> Juan Rivera <[EMAIL PROTECTED]> writes:
>
> > Along those lines would be the ability to generate a unique temporary file
> > name. Windows provides that functionality. I think it can be very handy.
>
> Subversion has a custom routine for doing that, too.
Juan Rivera <[EMAIL PROTECTED]> writes:
> Along those lines would be the ability to generate a unique temporary file
> name. Windows provides that functionality. I think it can be very handy.
As Mike Pilato described, Subversion has a way of doing this. But
where Windows provides a native mechani
Title: RE: APR_TMP_DIRECTORY
Along those lines would be the ability to generate a unique temporary file name. Windows provides that functionality. I think it can be very handy.
Best regards,
Juan C. Rivera
Citrix Systems, Inc.
-Original Message-
From: [EMAIL PROTECTED] [mailto
Juan Rivera <[EMAIL PROTECTED]> writes:
> Along those lines would be the ability to generate a unique temporary file
> name. Windows provides that functionality. I think it can be very handy.
Subversion has a custom routine for doing that, too. You specify a
prefix path (like "/tmp/svn-commit")
"David Reid" <[EMAIL PROTECTED]> writes:
> Well, repost it then :)
Heh... here's what I had posted (taken from the 200211.gz archive):
This has been mentioned before -- at least by myself, perhaps by
others, too -- but the Subversion folks would *really* like to see APR
grow a gimme
Kevin Pilch-Bisson <[EMAIL PROTECTED]> writes:
> On Wed, Dec 04, 2002 at 05:56:38PM +, Thom May wrote:
> > * David Reid ([EMAIL PROTECTED]) wrote :
> > > If we don't have such a declare maybe we should add one? I say this as
> > > htpasswd.c (in httpd) uses P_tmpdir that isn't portable and br
On Wed, Dec 04, 2002 at 05:56:38PM +, Thom May wrote:
> * David Reid ([EMAIL PROTECTED]) wrote :
> > If we don't have such a declare maybe we should add one? I say this as
> > htpasswd.c (in httpd) uses P_tmpdir that isn't portable and breaks the beos
> > build. Also Thom found a note in his s
On Wed, 4 Dec 2002, David Reid wrote:
> If we don't have such a declare maybe we should add one? I say this as
> htpasswd.c (in httpd) uses P_tmpdir that isn't portable and breaks the beos
> build. Also Thom found a note in his stdio.h file saying that it wasn't the
> right way to do things, an
> > If we don't have such a declare maybe we should add one? I say this as
> > htpasswd.c (in httpd) uses P_tmpdir that isn't portable and breaks the
beos
> > build. Also Thom found a note in his stdio.h file saying that it wasn't
the
> > right way to do things, and I agree it's not.
> >
> > I pro
At 11:41 AM 12/4/2002, David Reid wrote:
If we don't have such a declare maybe we should add one? I say this
as
htpasswd.c (in httpd) uses P_tmpdir that isn't portable and breaks
the beos
build. Also Thom found a note in his stdio.h file saying that it
wasn't the
right way to do things, and I a
* David Reid ([EMAIL PROTECTED]) wrote :
> If we don't have such a declare maybe we should add one? I say this as
> htpasswd.c (in httpd) uses P_tmpdir that isn't portable and breaks the beos
> build. Also Thom found a note in his stdio.h file saying that it wasn't the
> right way to do things, an
69 matches
Mail list logo
