Temporary paths
-
C:\Windows\system32
Not a good temporary path. Fortunately, the app isn't one of the ones that cleans out it's temporary folder when it starts.
I swear to god the person who installed and configured this shit was DANGEROUSLY stupid if not an active saboteur.
-
If you've got UAC turned on and you're using Windows 7 or later, that might actually work; Windows would end up using %LOCALAPPDATA%\VirtualStore\Windows\System32 instead.
-
Windows Server. Running as a service on a limited domain account. So no UAC - just unexplained failures every time it needed temporary data.
-
And I bet there are zillions of ways of generating a temporary file in Windows. In Linux is as easy as with tempfile
-
Semi-related:
Cleaned 81GB of old temp data on a computer the other day. All of it were .NET installers (ranging from 2.0 to 3.5 SP1) stuck in the Windows installer temp folder. Tens of gigabytes of identical files, just with different timestamps appended to the filename. No clue how and why they got there.
-
And I bet there are zillions of ways of generating a temporary file in Windows.
There's only one correct way: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364992(v=vs.85).aspx
In Linux is as easy as with tempfile
Gee, if only Windows had something like that in its API...
-
Why not
C:\Windows\assembly
?
-
Well...Windows actually gets this one wrong, what do you know? They only supply a way to get the path of the temporary directory and a suitable name for the temporary file, when what you really want is a syscall that does this in an atomic way -- POSIX defines
mkstemp()
to do just that, while Windows only hasGetTempFileName()
, which suffers from the exact same race condition issue asmktemp()
ortempnam()
-- it appears partially workaroundable by using auUnique
value of 0, but the resulting behavior is still time-of-check-to-time-of-use vulnerable, just with a smaller window.Furthermore, the documented semantics of
tmpfile()
in the MSVCRT are useless -- it creates the file in the root directory, which clearly is not the place to do temporary business!
-
when what you really want is a syscall that does this in an atomic way
.net has one, I'd be surprised if the C API doesn't. But I don't know much about it.
Furthermore, the documented semantics of tmpfile() in the MSVCRT are useless
You mean the one that specifically says it's deprecated is useless? Say it ain't so, Joe!
-
-
Fine! Then use this one: http://msdn.microsoft.com/en-us/library/18x8h1bh.aspx
Christ you people are helpless. It's linked right in the fucking sentence that says it uses the root directory. Christ! CHRIST!!!
Maybe I should write a book: Programming For Baby Infants Who Can't Read And Also Are Infants Who Cry Waaah
-
Which makes it useless. I won't return the name calling.
-
Maybe I should write a book: Programming For Baby Infants Who Can't Read And Also Are Infants Who Cry Waaah
I automatically read this in Zoolander's voice which is strange because I've never seen that movie.
-
You mean the one that specifically says it's deprecated is useless? Say it ain't so, Joe!
http://msdn.microsoft.com/en-us/library/b3dz6009.aspx
The replacement also uses the root directory, though.
Why in the name of Gates did they not make the replacement API work properly?Fine! Then use this one: http://msdn.microsoft.com/en-us/library/18x8h1bh.aspx
Sorry, that's time-of-check-to-time-of-use (TOCTTOU) vulnerable. There's a reason that the Linux man page for it is written the way it is...
-
-
I demand that my soothing relaxation mediation sleep sounds come with 4K video.
-
I'm far beyond the giving of any shits. I have a billion Windows programs that all somehow magically correctly find temporary file names as if by magic, so whatever they do, you do also, ok?
-
Since Windows does file locking by default, a call to CreateFile will fail if the file returned by one of these functions already exists.
-
Since Windows does file locking by default, a call to CreateFile will fail if the file returned by one of these functions already exists.
Nope -- file locking doesn't influence creating a new file vs. opening an existing file that nobody else has open.
-
Nope -- file locking doesn't influence creating a new file vs. opening an existing file that nobody else has open.
If you use the CREATE_NEW flag, it will at least fail if the file already exists.
-
the documented semantics of tmpfile() in the MSVCRT are useless -- it creates the file in the root directory, which clearly is not the place to do temporary business!
That doesn't seem to stop .NET installers, which unpack themselves to a randomly named folder in the root of whichever drive has the most free space - a folder which they often fail to clean up after they're done.
-
Maybe I should write a book: Programming For Baby Infants Who Can't Read And Also Are Infants Who Cry Waaah
If it sells, I'll do the sequels: Unix System Administration For Baby Infants Who Can't Read And Also Are Infants Who Cry Waaah, and Command Line Interfaces For Baby Infants Who Can't Read And Also Are Infants Who Cry Waaah.
-
Sorry, that's time-of-check-to-time-of-use (TOCTTOU) vulnerable. There's a reason that the Linux man page for it is written the way it is...
Least-effort way around that issue in Windows scripts is just don't bother with a check:
set tmpfile="%TEMP%\%RANDOM%-%RANDOM%-%RANDOM%-%RANDOM%" whatever >%tmpfile% etcetera <%tmpfile% del /f %tmpfile%
-
If you use the CREATE_NEW flag, it will at least fail if the file already exists.
Yes, this is akin to theO_EXCL
flag toopen()
. This is quite helpful -- but I suspect it's not quite enough, otherwisemkstemp()
would not have been developed.That doesn't seem to stop .NET installers, which unpack themselves to a randomly named folder in the root of whichever drive has the most free space - a folder which they often fail to clean up after they're done.
Haha -- sounds like the .NET installer team needs to get its act together!Least-effort way around that issue in Windows scripts is just don't bother with a check:
[code]
set tmpfile="%TEMP%%RANDOM%-%RANDOM%-%RANDOM%-%RANDOM%"
whatever >%tmpfile%
etcetera <%tmpfile%
del /f %tmpfile%
[/code]
And then someone spams%TEMP%
with symbolic links to some important system file -- say a registry hive, or some executable needed for the system to run. Whoops!
-
Fortunately, the app isn't one of the ones that cleans out it's temporary folder when it starts.
I've seen that back in the dos days. And the default TEMP=C:\DOS didn't help.
-
That doesn't seem to stop .NET installers, which unpack themselves to a randomly named folder in the root of whichever drive has the most free space - a folder which they often fail to clean up after they're done.
That's probably this bug, which was fixed in VS2008 SP1.
And yet you still see new software being distributed with the fucking bug, because Microsoft's weakness has always been: Windows developers are fucking awful.
-
And yet you still see new software being distributed with the fucking bug, because Microsoft's weakness has always been: Windows developers are fucking awful.
True whether they work for MS or not.
The .NET installers I regularly see doing this crap are the ones that arrive via Windows Update.
-
-
That's probably this bug, which was fixed in VS2008 SP1.
Doubt it. The effect I'm talking about is folders named like C:\b39ecdd40a998a32a2 that have a bunch of unpacked installery stuff inside, rather than a spew of loose files directly into the drive root. It looks pretty deliberate, especially coupled with the fact that these things always show up in whatever drive has the most free space.
Sometimes that happens to be a USB flash drive with less-than-stellar performance. If you're wondering why a particular .NET update seems to be taking forever to run, it could well be because it's trying to do things on a drive best rated in kilobytes, not megabytes, per second.
For added irritation points, the left-behind temp folders will quite frequently feature subfolders that don't have Full Control permissions for Administrators, meaning that cleaning up this useless temporary cruft requires fooling with NTFS permissions before the recursive delete will work.
-
That doesn't seem to stop .NET installers, which unpack themselves to a randomly named folder in the root of whichever drive has the most free space - a folder which they often fail to clean up after they're done.
Better than one of the VC runtime installers, which unpacks itself to the root of the system drive, and then leaves the files there.
@blakeyrat said:That's probably this bug, which was fixed in VS2008 SP1.
No, he was talking about Windows updates and .NET installers that unpack themselves to a randomly-named directory on the local drive that has the most available space. At least those clean up after themselves about half of the time (but it's annoying when you have an USB drive connected, some update runs in the background, and you find out that you can't safely unplug the drive because Windows is using it for it's updates).
-
Furthermore, the documented semantics of tmpfile() in the MSVCRT are useless -- it creates the file in the root directory, which clearly is not the place to do temporary business!
Wow, that... both hilariously and infuriatingly stupid. And I checked in the CRT source from VS2010, what the documentation says is true: It does create the file in the root directory (of the current drive, apparently). The only difference between
tmpfile
andtmpfile_s
, beside the way they return errors, is that the former creates the file with full sharing rights (allowing another process to open it), while the latter opens it exclusively.
-
To be fair to the software vendor: The default temp directory for this program is one it creates in the standard API-compliant manner.
Of course, service accounts don't have profile directories in our server setup, so derp and fail and "That directory doesn't exist, so let's use our working directory!" and guess what the working directory that services inherit is?
So the service commandline has to specify a sane, enterprise-compliant working directory and temporary path. Says this right in the docs. On page 2700-some.
-
Yes, this is akin to the O_EXCL flag to open(). This is quite helpful -- but I suspect it's not quite enough, otherwise mkstemp() would not have been developed.
Actually, it is enough.
mkstemp()
is just a thin layer on top of it to do filename generation and retry if the first thing tried fails. It's creating temporary directories (well, without subtle security problems) that is far more problematic, and it's true on all platforms…
-
Doubt it. The effect I'm talking about is folders named like C:\b39ecdd40a998a32a2 that have a bunch of unpacked installery stuff inside, rather than a spew of loose files directly into the drive root.
Huh. I don't think I've ever seen that. (Which doesn't mean it hasn't happened on my box, it just means the files were cleaned-up ok for me.)
-
Sadly it does happen. I just looked at my work computer and noticed I have c:\bc0ef62cb791f2630b5807e125 which contains SQL Server 2008 Express stuff... I assume this was from back when VS2010 was installed.
-
USB drive
I downloaded the 6.8GB ISO of the new VS Community edition or whatever it's called, and tried to copy it to a USB3 drive with 20GB free. It said there wasn't enough space left on the drive. O RLY?
-
Says this right in the docs. On page 2700-some.
Ah, so you are TRWTF after all. In addition to them.
-
Actually, it is enough.
mkstemp()
is just a thin layer on top of it to do filename generation and retry if the first thing tried fails.
Interesting -- why does Windows expect developers to get this right on their own, then, considering the security implications of getting this wrong?It's creating temporary directories (well, without subtle security problems) that is far more problematic, and it's true on all platforms…
Yeah --mkdtemp()
isn't all that hot (it gives you back a name). I suspect the problem has something to do with permissions, though, considering that neithermkdir()
norCreateDirectory()
will clobber an existing thing...
-
Sadly it does happen.
Gee, it's almost as if I specifically called-out that I'm not saying it didn't happen. IT'S ALMOST AS IF I DID THAT VERY THING IN THE VERY POST YOU ARE REPLYING TO.
I'm so glad we have so many sharp people on these forums. Hey how about we summon 463,432 idiot bots???
-
Gee, it's almost as if I specifically called-out that I'm not saying it didn't happen. IT'S ALMOST AS IF I DID THAT VERY THING IN THE VERY POST YOU ARE REPLYING TO.
I'm so glad we have so many sharp people on these forums. Hey how about we summon 463,432 idiot bots???
@accalia ITT
-
No.
If you want that many bots on the forum go deploy the SockBot code yourself. I'm happy with just the 6 I run.
-
I have far better things to do than figure out the precise configuration of every one of my dependencies, running on servers I don't have direct access to.
I only found out when we did an install on another system and shit didn't work because we didn't grant the service account permission to mangle system directories.
-
I downloaded the 6.8GB ISO of the new VS Community edition or whatever it's called, and tried to copy it to a USB3 drive with 20GB free. It said there wasn't enough space left on the drive. O RLY?
Your USB drive is formatted with FAT32, which doesn't support files larger than 4GB (-1 byte). Reformat it as UDF, and you'll be able to copy the file.
-
Your USB drive is formatted with FAT32, which doesn't support files larger than 4GB (-1 byte). Reformat it as UDF, and you'll be able to copy the file.
UDF < NTFS (at least in the windows world unless contrary evidence is presented)
-
Your USB drive is formatted with FAT32, which doesn't support files larger than 4GB (-1 byte). Reformat it as UDF, and you'll be able to copy the file.
I use exFAT.
-
...folders named like C:\b39ecdd40a998a32a2 that have a bunch of unpacked installery stuff inside.
I'm still waiting for a future when installers don't need to unpack temp files anywhere, but just INSTALL files where they are intended to go in the first place. I know, it's pretty unrealistic.
-
I use exFAT.
Same here. I even found a Windows XP exFAT driver so there's literally no reason not to use exFAT anymore. I used to use NTFS but that usually made Linux crap all over itself and me.
-
I used to use NTFS but that usually made Linux crap all over itself and me.
I used to do that - but always had problems ejecting the disk... (device is busy. try later. fuck you.)
-
Your USB drive is formatted with FAT32
A 32GB drive? Seems unlikely, but it's at home and I'm not. I'll try to remember to check that.
In any event, about every other year I have a need for a DL DVD, so I have some handy, so I just burned a fresh disc instead.
-
A 32GB drive? Seems unlikely, but it's at home and I'm not. I'll try to remember to check that.
FAT32 supports volumes up to 2TebiBytes12
1 => http://en.wikipedia.org/wiki/File_Allocation_Table
2 => i hate the use of the Tebi prefix, but i felt it important to be unambiguous this time