Re: File::Temp/File::Spec problems on Window s under taint mode – breaking change needed?

> Am 27.04.2015 um 22:29 schrieb Graham Knop <[email protected]>:
> 
> 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.

Not the same concept, but a concept like executable bits on Unices. It is possible
(investing enough effort) to implement a simplified access. Since POSIC specifies
ACL's meanwhile showing that the idea itself wasn't that wrong (and ACL's > i-node
attributes, if any).

But there is no reason to fight this - the result stays the same whatever we
finally agree ;)

>>> 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.

IIRC it checks some more and has %system%/temp as fallback. As non-native
speaker (checked several translations) I don't get the sanity of tainting
at all.

>>> 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.

/me nods - that's fine at all. 

Cheers
-- 
Jens Rehsack
[email protected]