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.
1) We can open a temporary file based on a template. The template
includes a full path. apr_file_mktemp()
2) We can get the system's temporary directory. If the programmer wants
to ignore this directory, they can. If they want to use it they can.
apr_temp_get_directory
3) We can get a unique filename in a specific directory. This filename
can then be used in opening a temporary file. The user can pass in the
correct directory, so they can create their own, or use the one returned
from apr_temp_get_directory. apr_temp_get_filename
4) We can get a unique filename in any directory. apr_temp_get_unique
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 temporary
files. The PHP uniqid function just generates a unique string, APR
doesn't need to implement that feature, because APR-util already has UUID
support, which is designed to generate unique strings.
The way I see thing working is that the user would do the following to get
a filename in the system's temp directory:
apr_temp_get_filename(apr_temp_get_directory(...), ".foo", pool);
To get a filename without a directory, they would do:
apr_temp_get_filename(NULL, ".foo", pool);
And, to get a filename in an arbitrary directory, they would do:
apr_temp_get_filename("/tmphaha", ".foo", pool);
The ability to use a compiled in default path (PATH_TMP) is harder to deal
with, because most platforms don't have that concept. I don't believe
that it is a good idea to add flags that only really make sense on some
platforms. We are better off IMNSHO, just ignoring that case for now, and
force the app developer to handle it themselves by passing that macro to
apr_temp_get_filename.
Does anybody actually have a problem with this? If not, can we stop
discussing and start implementing it? BTW, when this gets implemented,
it needs a test program at the same time. Preferably one that really
exercises the features.
Ryan
On Sun, 8 Dec 2002, David Reid wrote:
> Can I suggest that before we go headlong into letting the existing unix
> api's decide on our new api we decide exactly what we want???? Jeez - though
> the dog was supposed to wag the tail?
>
> Implementation details are nice, but really until we know what we want to
> implement they're a bit premature aren't they?
>
> So, having spent 10 minutes reading email trying to catch up I'm still no
> further forward apart from seeing a lot of totally irrelevant discussion of
> Unix :( Anyone care to kick this 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" <dev@apr.apache.org>
> 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:
> >
> > > 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 ability to let the users do what they like and
> > > maximum
> > > flexability. apr_get_unique is mean to work along the lines of PHP's
> > > uniqid(), though do we also want to allow for extensions to be passed?
> > >
> > > david
> >
> > For apr_temp_get_directory:
> >
> > 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 uncommon for
> > system applications to do so. <paths.h> defines _PATH_TMP, which we
> > should use. Beware this includes the trailing slash, which I think is
> > more of a bother than a help, but whatever.
> >
> > A note on /var/tmp: On BSD systems, you have both /tmp and /var/tmp.
> > The difference is that /var/tmp tends to be longer-lived (files that
> > haven't been accessed in n days get deleted by periodic tasks, n is
> > sometimes larger for /var/tmp), and, unlike /tmp, is not wiped on
> > reboot. /var/tmp is generally used by system software, but also by
> > editors for backup files (which you'd like to find even if your system
> > crashed). See hier(7). Don't know about System V conventions for
> > that. Anyway, on BSD, I think we want /tmp, not /var/tmp for the
> > default.
> >
> > For apr_temp_get_filename:
> >
> > I suggest you look at the mktemp(3) API family on a BSD system for
> > reference. That API is pretty good. There are some features there
> > (one rather important one) missing in your API.
> >
> > mktemp take a template and returns a tmp file based on that template.
> > Basically, this lets you choose a prefix as well, which is useful for
> > identifying the files. (eg. /tmp/svn_turd.xxxx vs.
> > /tmp/httpasswd_turd.xxxx) I think that's a good idea.
> >
> > Important one: Note that mktemp() is similar yo your API in that it
> > returns a string which is a path to a non-existing file in an existing
> > directory. The problem with that API is that there is a race
> > condition; if the file is opened by another process between the time
> > you get that string and when you attempt to create the file, you may
> > loose. mkstemp() differs in that it creates the file (mode 0600) and
> > give you back a file descriptor. I think we want that.
> >
> > I suggest we use something like this API:
> >
> > char *apr_temp_get_filename(char *dir, char* prefix, char *suffix,
> > apr_pool_t *)
> > apr_file_t apr_temp_file(char *dir, char* prefix, char *suffix,
> > apr_pool_t *)
> >
> > There is also an mkdtemp() for creating a temporary directory (mode
> > 0700). This is also handy. So maybe we also want:
> >
> > char* apr_temp_mkdir(char *dir, char* prefix, char *suffix, apr_pool_t
> > *)
> >
> > And that we use mktemp() and friends (or tempfile() and friends or
> > that crazy Windows API) before falling back to our own implementation.
> >
> > For apr_temp_get_unique:
> >
> > Dunno what that is. No comment.
> >
> > -wsv
> >
> >
>
>
