On 4/27/15 4:10 PM, Jens Rehsack wrote: > >> Am 24.04.2015 um 05:37 schrieb Aristotle Pagaltzis <pagalt...@gmx.de>: >> >> * David Golden <x...@xdg.me> [2015-04-23 17:40]: >> [...] >>> Please see https://rt.cpan.org/Ticket/Display.html?id=60340 for context. >>> >>> I think File::Temp needs to be able to work around File::Spec::Win32 >>> returning a non-writable directory. >>> >>> My proposal was to warn and fall back to ".". That's a small breaking >>> change, but I think doing something in a different place than >>> requested is better than failing entirely. >>> >>> Alternatively, it needs to validate the Win32 response and throw an error >>> early, before attempting to make the directory so that the error message is >>> more informative. >>> >>> Thoughts? >> >> Windows considers the current directory an implied part of %PATH%, > > True > >> has no concept like the executable bit of Unixoid OSes, > > Nope - it has such a concept, but it's in ACL's, not in attributes. History of > Windows was non-multi-user *shrug* - weird implementation, crummy supported ;) > This also depends on the filesystem, and isn't really the same concept.
>> nor does it allow >> unlinking files while they’re open. > > Depends on Filesystem ... > >> So I’d feel uncomfortable about just >> unexpectedly dropping junk into the current directory, announced or not. >> Therefore I’d tend toward the latter. > > Is there a reason not to tryout Win32 API function GetTempPath > (https://msdn.microsoft.com/en-us/library/windows/desktop/aa364992%28v=vs.85%29.aspx)? > I dunno how File::Spec/File::Temp on Unix behaves tmp points to a > non-writable directory (think r/o file-system). This uses the environment just like File::Spec->tmpdir does. The only important difference is that File::Temp checks for tainting. Switching to GetTempPath would be the same thing as removing the taint checks. > >> But someone with better instincts for Windows may be able to call this >> bunk. Mostly I didn’t want to leave the question warnocked. > > I agree - '.' is the worst choice one can make - and I intend to say 'start > again with TMP="."' or so. > The closest thing I can think of would be using the local application data directory. This is the same place that the user's temp directory lives. Win32::GetFolderPath(Win32::CSIDL_LOCAL_APPDATA)."\\Temp" should give you the current user's temp directory. It would probably be wrong for programs not running under a login user account, like daemons or CGI scripts. Those would likely want to fall back to C:\WINDOWS\Temp.
