From owner-freebsd-current Thu Jun 8 21:56: 4 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id C35EB37B5EA; Thu, 8 Jun 2000 21:55:58 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id AAA245936; Fri, 9 Jun 2000 00:55:57 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Fri, 9 Jun 2000 00:56:22 -0400 To: Kris Kennaway , Boris Popov From: Garance A Drosihn Subject: Re: mktemp() patch Cc: John LoVerso , current@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 8:47 PM -0700 6/8/00, Kris Kennaway wrote: >On Fri, 9 Jun 2000, Boris Popov wrote: > > > Count both, nwfs and smbfs, because any program can > > attempt to create temporary file on these filesystems. Files > > with an invalid file name will be rejected, and this will > > cost an additional lookup operation(s). > >I'm not sure that weird filesystems are a valid argument against >mktemp() naming - there are LOTS of UNIX code which assumes UNIX >namespace conventions, and it's not just mktemp() which is going >to break on weird filesystems. For example, should we limit all >FreeBSD file names to 8.3 single-case in case someone wants to >run from an old-style MSDOS partition? > >Basically, I think the answer is not to use a nwfs or smbfs >filesystem as your TMPDIR :-) Certainly the new version should not worry about any problems (such as 8.3) which are just as much of a "problem" with the current implementation. A thought occurs to me, and it's vile enough that I would not feel insulted if everyone unanimously shouts it down. However, thoughts occur to me so rarely that I feel compelled to share them if there is any chance they might be useful. Should the new mktemp check some kind of environment variable, and use a different list (or maybe even a totally different algorithm) depending on the value? Perhaps have a few specific choices, where even the "least random" option would at least add a few characters to the current list. Maybe have the "most random" option completely drop more of the the UID part, and use that space for more randomly-generated bits? Honest, I won't feel bad if everyone hates this idea or laughs at the absurdity of it... :-) --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message