Re: File::Temp/File::Spec problems on Win dows under taint mode – breaking change neede d?

On 4/27/15 4:10 PM, Jens Rehsack wrote:
> 
>> Am 24.04.2015 um 05:37 schrieb Aristotle Pagaltzis <[email protected]>:
>>
>> * David Golden <[email protected]> [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.