> Am 27.04.2015 um 22:29 schrieb Graham Knop <ha...@haarg.org>: > > 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.
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 rehs...@gmail.com
