> 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 ;) > 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). > 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. Cheers -- Jens Rehsack rehs...@gmail.com
