I've been doing some Vista testing, and found that I think Vista's UAC is preventing the creation of a tempfile obtained via tempnam. The platform SDK's c runtime library header stdio.h defines the temp file prefix as '\\', which would place temp files at the root of the drive. I think this is causing problems with Vista's UAC (user access control).

I suppose one can turn off UAC, but a better solution would be to just create a temp file in the current directory.

I noticed that the platform SDK's c runtime library does have mktemp (it doesn't have mkstemp, but we already know that). This would suit our purposes just fine, though obviously it doesn't have the atomicity advantage of mkstemp (but neither does tmpnam, so we're no worse off).

Has anyone else run into this?

Would a patch be appreciated, so this gets fixed in the next version? I've already generated a patch...please reply if it's wanted.

Actually, no, it wouldn't be. It used to be like that, which caused crashes in Windows (the famous "grabber crashes when saving a datafile in XP" bug) and UNIX (though no one apparently spotted it there until we found the cause and tried it) if the user doesn't have write permission in the current directory.

I dont mean to be pedantic, but could you make sure? Just to check, are you actually experiencing a problem, or is this something you found that could be a problem (in which case it would need to be confirmed)?

Is it just me or does that sound like Vista is really badly broken?

Anyway, yes, we will accept patches that fix this properly if it really is a problem (but not a patch that places temporary files in the CWD). Please post it here, or on the AD mailing list.

The platform SDK sounds more broken than the UAC stuff. Restricting access to areas of the disk is usually a good idea. Making the "temp" prefix "\\" (ala platform sdk) is astonishingly bad. At least make it use TEMP/TMP or something.

Off topic:
For my 4.3 (vfs-work-4.3 branch) code, I've taken care of this little issue with a custom mktemp function, and a proper way to grab the platform's TEMP directory. Feel free to rip any of it for 4.2.

This is actually a problem, and not speculation.

Yeah, the temp file in the app's current directory wouldn't be so good. What I'm doing is creating the temp file in the directory where you're trying to save your datafile. Either you're going to have write permissions in that directory, or the operation wouldn't have worked anyway. Sorry for the confusion.

A catchall solution to this would also be to have the various apps just take an optional temp directory as a parameter, to get around this problem.

And no, I don't think Vista's really badly broken because of this behavior. I agree with Thomas. The platform SDK shouldn't be defining the temp directory as "\\". As far as I'm concerned, platform SDK's tmpnam implementation is broken on Vista because of this behavior.

It sounds like Thomas has a good fix, in either case (though we'd want to get it tested on Vista anyway, just to make sure). Can we just make sure that fix gets backported to the 4.2.x line?

We can add a allegro version of mkstemp, which I basically wrote for 4.3. I don't think that'll break binary compatability. Its really up to the main devs like Evert and Peter though.

Better, though I don't like ignoring the location for temporary files like that. Seems like TF's solution would be good.

That's more or less what I meant, sorry for being unclear.

Any bugfix that doesn't break ABI compatibility can be included in the next 4.2 update.

Neat. When this does get backported, feel free to give me a shout if you want me to do some testing on Vista.

Currently the latest version of allegro does get the proper "temp" directory in the pack_fopen_chunk functions (related to datafiles).

Where exactly is the error yore seeing?

In the tools. The particular example I ran into was in datedit.c.