Acropalypse: Windows Save File API is defective by design | Hacker News Reader

Acropalypse: Windows Save File API is defective by design

twitter.com

140 pointsjve76 comments

> However, the new “more secure” Universal Windows Platform (UWP) sandboxes the file picker in a separate process, allowing neat features like capability-based access control. It returns a file handle which, if the selected file exists, will not overwrite the existing content!

That got me a bit worried, since desktop Linux is going somewhat in the same direction with sandboxed applications. So I did a quick search for the file chooser portal API, and if I understood what I found correctly (https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free... and https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.free...), it does not return an already opened file handle; instead, the file is made available in a FUSE mountpoint within the sandbox (/run/user/$UID/doc/), and the call returns a URI pointing to that file. So, if I understood it correctly, developers can keep using the same traditional POSIX APIs they're already used to, with the same semantics they always had outside the sandbox.

Indeed, and the document portal seems to have built-in support for atomic writes by first writing to a temporary file and then renaming it (https://github.com/flatpak/xdg-desktop-portal/blob/main/docu...), so it should be possible to avoid this scenario altogether.

Basically what Microsoft has been doing since Windows 8 in 2012 is the equivalent of deprecating open(2). The people writing the new APIs have no idea how to design them, they think something like having a flag to overwrite the existing file is useless, confusing, legacy cruft.

I doubt people working in the Linux space would be so brazen.

>I doubt people working in the Linux space would be so brazen.

Have you heard about this little project called Gnome yet?

I haven't used gnome on my own machines since the late 90s, or on machines that aren't mine since the mid 2000s, so I dunno.

I really doubt they'd try to literally destroy open(2). Sandboxing is different from this.

Would receiving an fd via Unix socket be better or worse idea? Then the returned path could be /dev/fd/XXX

Conceptually fd would be more elegant and better overall, but passing a path is probably easier to interoperate with all the libraries etc that are out there

UWP is deprecated. WinUI version 3 is now recommended. At least with the .NET API, file saving now works like a normal Win32 app from a programmer's perspective.

Not sure if it is different under the hood.

>UWP is deprecated.

Win32: "Once more, yet another challenger falls before me. Who's next?"

Sounds like a ripe opportunity to do a parody cover of Tenacious D's The Metal.

Win32 evolved fill a certain ecological niche millions of years ago, and it's only going away if that niche does or if something manages to fill it better.

Have you seen the "save screen" in win 10 ? It makes insects look beautiful in comparison.

> UWP is deprecated

That new shiny thing that Microsoft always pushed on me back when I was using .NET Framework 2.0 with C# is now deprecated before I gave it a try.

I feel like somewhere around the release of Windows 8 Microsoft's OS division completely lost the plot and they've been coasting on profits from their other divisions ever since.

That, and allowing other players to dictate things --- in particular, the dumbing down of active styluses in Fall Creators Update so as to match the behaviour of Android for the sake of the Surface Duo is bizarre.

I had to turn of Windows Ink so that Macromedia Freehand/MX would work.

I need to find a web browser where the stylus selects text, as it has since Windows for Pen Computing, rather than scroll (why is this desirable? Can't one just scroll w/ touch?).

I'm still traumatized by Windows Server 2012 which removed the start menu in lieu of a touch interface. For an enterprise server platform...

They've outsourced a lot development and QA, which may or may not have contributed to that feeling.

On the same line of "did no one ever bother to actually use it ?", you get a brand new computer or laptop, you want something to run over night so you go to settings and you set "sleep after" to "never", and it still goes down. You think you go crazy, you check every single option, and nope, everything is properly set.

Then you go into the details of your power plan, through the old control panel they plan to remove, and you see that the hibernation settings is set to 120 minutes, and is not exposed in any way in the settings menu.

What is even the point of allowing me to disable sleep ? I know sleep and hibernate are two different things on a technical and power usage level, but the end user really doesn't care, what he means is "don't turn the computer off".

There are so many things in that same vein that have gone wrong after windows 7, and by the way the windows 11 start menu and right click contextual menu are as bad as people describe them, thank god third party tools easily exists to remove them.

Microsoft lost the phone battle so now they want my laptop to behave like a phone, this is ridiculous.

What gets me is the extraordinarily basic things you can't do without third-party software. You can no longer just drag a Start menu search result onto your desktop for a shortcut. The Taskbar cannot be set to automatically extend upward when you have a lot of windows open and then back down when you don't. There is no central menu for managing what entries you have on your right-click menu.

Oh, but the hibernation story is event better! If you actually want to have it hibernate, it will randomly wake up at night on its own! It doesn't seem to notice that it has bitlocker enabled and no auto-unlock, it will happily bathe the whole room in that blue light.

Is this perhaps an issue with BIOS settings, such as wake on LAN or something else? When Windows hibernates, it turns the PC off. You need to investigate what is turning it back on, and I don’t think that’s Windows.

Is it possible that it is resuming from standby prior to hibernation which is causing this?

I don't think so. It's an older PC without the new "s2idle" thing. It's either classic S3 sleep or hibernation. It also doesn't do the Linux kind of "sleep + hibernate" (don't know if that's a thing under windows) because the LED doesn't blink (it blinks for s3) and even if I turn it back on right away, it will go through the whole BIOS POST thing, bootloader, etc. The MB has an internal LED showing its state and it shows the same thing as a full shut down.

That particular PC dual-boots windows and Linux.

When the PC is either fully off or hibernates under Linux, it never ever turns on on its own. Wake on LAN and bios timers are all disabled.

I've already complained about this on some other thread, and a poster talked about some kind of timer that windows activates. I think there's some merit to that because it always turns on at night, I don't remember it turning on during the day.

I never went looking for details, since this is only a gaming PC, so it's not that much of a hassle to just turn it off. I'm not confident that an update won't reverse the change.

In that case, you can most likely find it in the event viewer.

I don't doubt that. But the point is that this is an extremely terrible implementation of whatever it is they are trying to achieve.

I've jumped through the obvious hoops of disabling sleep and automatic update installs. If I put my PC to sleep, I want it to stay asleep, I don't want the OS to second-guess me, especially if it's unable to plan for its own configuration that may prevent it from doing what it's doing.

To me, this just reeks of a half-assed attempt at copying apple's "power nap" feature. "Yah, let met check your mail while the pc sleeps (who the hell cares?!) or apply random updates". Except that on macOS, you can disable this with an obvious checkbox in an obvious place. Having to sift through event viewer (which for some reason is unbearably slow even on an 8-core Xeon with an NVMe drive) and going spelunking in the registry looking for undocumented settings is so user hostile.

Sleep has been terrible on Windows for many, many years. Typically, when setting up a PC, in order for it to sleep consistently until _I_ wake it, I have to go into device manager, go over each USB device, and disable it waking the PC. That is a terrible experience that nobody should do. Not sure whether this behavior is due to bad drivers or a bad Windows implementation, and frankly I don’t care.

I’ve never seen what you are describing with hibernation, because it just shuts off the PC. But I have little to none experience with Windows 11.

I think it's the wake timer[0] settings in the energy options.

[0]https://www.softwareok.com/?page=Windows/10/Power-Options/11

It doesn't even have to be waking up from hibernate. Windows will decide it needs to reboot after installing updates even though BitLocker is configured to use an extra PIN.

On mine it wouldn't sit on the BitLocker screen forever. It would reboot after a little bit which would cause the fans to spin to max for a second. It's like having someone revving a car all night, but with the added anxiety of knowing it's wearing out your stuff.

Microsoft owes me some sleep.

Yeah, mine reboots too. But the PC is very quiet, and I sleep with earplugs, so the only nuisance is the bright screen.

The "solution" to your problem is press windows, type "presentation", and select "adjust settings before giving a presentation". Now just select "I am currently giving a presentation" and "Turn off screen saver", click ok, and your computer will stay on. Turn it off afterwards, otherwise it turns off on restart or when you manually initiate sleep. As a bonus you can have normal sleep and hibernation settings that make sense when you don't want to run something overnight.

I'm not sure how you're supposed to discover this though. And it's only available on laptops. Somehow windows is starting to divide people into camps of "everything is turning to crap" and "everything is fine, just follow these arcane steps" where previous versions just worked

I used to be able to set up a new Windows installation from memory in less than ten minutes after finishing installation. Now it takes me damn near an hour and I have to keep a text file with all the steps to un-fuck Windows.

Or install ms powertoys and enable “awake mode”.

Doesn't always work. I have firsthand experience trying to use it on an Asus X13 and it just happily goes to sleep like it wasn't even running and activated.

In fairness I've got a Debian box here which is doing something along the lines of sleep and it has put up enough of a fight that I've temporarily given up on running things overnight on it. I think there's an XML file that didn't use to exist somewhere that sometimes throws away my edits to it and overrides whatever I've told gnome to do.

I've seen kernel code from pre and post Windows 8. The pre Windows 8 stuff is generally nice, from what little I saw the post windows 8 stuff looked like features designed by a PM that engineers were forced to implement.

Things were obviously not as well thought out, Windows 8 was, IMHO, a panicked reaction to the rise of tablet sales at the time.

They tried before, just not so agressive. (clippy, GUI in XP etc). After Win 7 they started taking various drugs.

This might explain why they often change the mood.

I think the claim really should be that the defaults are "defective." Reading the thread, it seems the API does support truncating the opened file.

Interesting gotcha nevertheless.

Yeah even if it didn't, I mean, you could still save to a temp file, delete the old one then move. Not atomic, but it's safer than just doing what they were doing

(or just pad the rest with zeros worse case)

If you really want to, you can make it atomic by using the Transactional NTFS API [1]. Though I suppose you need a non-atomic fallback in case the file is not on an NTFS volume.

[1] https://learn.microsoft.com/en-us/windows/win32/fileio/when-...

TxF is deprecated:

https://learn.microsoft.com/en-us/windows/win32/fileio/about...

Technically it isn't deprecated, just discouraged. Note how the page you linked doesn't contain the word "deprecated", and the "alternatives" page linked from that notice states in the introduction that they are considering deprecating it in a future version of Windows.

Given that this notice seems to exist since at least 2012, and neither Windows 10 nor 11 deprecated it, the TxF API will probably outlive whatever software you're writing today.

I'm not sure what developer would start a new project using TxF when the vendor is stating "we want to remove this", "don't use this feature", "here are alternatives".

It's deprecated in all but name only.

This is the craziest shit I've read all month. How did this make it into production?

"How did this make it into production" is what I've felt every time I've had to use metro apps since Windows 8 was released.

People say it's NOT unique to Windows Snipping Tool but other tools that use this workflow for pngs as well.

Only if they use UWP, which is still somewhat rare, due to Win32 having loads more features and less bugs.

The entire UWP API was a fractal mess of poor decisions implemented sloppily, I can't say I'm surprised. There's so many footguns and glaring oversights that most people probably just gave up on it before they got this far.

Microsoft can do a lot of things right (asp.net core and sql server are awesome products). But they really suck at creating UI toolkits and platforms. The last sane UI toolkit was Winforms, but it didn’t really evolve for 20 over years now.

Yeah, WinForms has been deprecated since 2014. Microsoft spent the last 30 years inventing and deprecating and reinventing and deprecating more UI frameworks than the entire rest of the industry combined (excluding JS frameworks).

The same way it made it into production on POSIX?

O_TRUNC is not default: https://man7.org/linux/man-pages/man2/openat.2.html

I feel this is a bit different. At least O_TRUNC is an option that is shown in documentation right next to the open() function so the programmer has the opportunity to spot it. With the FileSavePicker, there is no such option available and they have to add a line to manually truncate the stream. Also, open() is a low-level call, whereas FileSavePicker is the supposedly easy-to-use high level feature. I would say it is closer to fopen(), which does truncate by default.

These are very minor points. The main one is the same across platforms : bad defaults are common

Notwithstanding the lowest-level function open() working that way (and it’s honestly a somewhat different situation due to what it is and what the flags all are), fopen(), the more user-friendly interface with its mode strings, has "w" equivalent to including O_TRUNC in open() flags: https://man7.org/linux/man-pages/man3/fopen.3.html

I only have a very basic understanding of it, but skimming it makes me think that, in addition to leaving non-truncated files full of garbage around, that kind of open, overwrite, close pattern could be problematic on BTRFS. I wonder if that's one of the scenarios where BTRFS can end up with a bunch of extents that are full of mostly un-referenced blocks, but can't reclaim space because some of the blocks in the extent are (or BTRFS thinks they are) still in use.

If you truncate, write new data, and close fd, nothing (in that file) refers to the old extents, and btrfs will garbage collect them just fine.

The thing that hurts all copy-on-write systems is something like SQLite/Postgres/etc that mutates the file here and there; explicitly not overwriting it. chattr +C is the standard convention to opt out of copy-on-write, for those.

It's a pretty clear sign of how unpopular and rarely used UWP is: they can ship horrible bugs and nobody notices. A similar bug in Win32 would surely have been caught instantly just based on how widely it is used, both inside and outside of Microsoft.

Over the past decade there has been a lot of half-baked Windows stuff that made it into production before needing a rethink.

/me glares at "per-monitor v2" API awareness. I hate spreading rumours, but the one I heard about this was that nobody within Microsoft itself had tried converting any of their first-party GUI apps to per-monitor DPI. Once they started to do so, they finally realized how bad their offering was and came up with v2.

Because our industry and modern society in general dare not slow down long enough to let good work be done, or trust a craftsperson when they say, "This isn't done yet"

>The documentation for FileSavePicker doesn’t mention the problem or truncate files in the example code. It is no surprise that the default behaviour of not truncating existing files is, therefore commonplace, despite being not what most people want. 5/9

The example in the link in the tweet uses .PickSaveFileAsync(). The documentation for that function is https://learn.microsoft.com/en-us/uwp/api/windows.storage.pi... which says:

>The file name, extension, and location of this storageFile match those specified by the user, but the file has no content.

(Emphasis mine.)

And it's not a recent change. It was written in 2017. https://github.com/MicrosoftDocs/winrt-api/blame/docs/window...

So it may just be a bug rather than the intention. Though given that the SO question is from 2016, it seems nobody verified the intention was actually implemented since the very beginning.

Huh.. wh-.. no I did a bit of digging (first)! [0] Could be a coincidence. Either way the explanation here is way better and more detailed ^^;

[0] https://news.ycombinator.com/item?id=35253970

This thread confuses me, possibly because I'm not a UWP dev. OP keeps talking about the FileSavePicker being defective, but isn't that just a control? Isn't the actual writing being done by the FileIO classes? And doesn't it just boil down to someone using them wrong?

In the System.IO namespace we can explicitly specify a FileMode to indicate whether we're appending or overwriting. If the UWP equivalent doesn't exist (and you need to explicitly set the file length to 0 to truncate), why would anyone just assume it does one or the other?

"The API is crap" is still not an excuse for using it wrong. Am I missing something?

I was also wondering along the same lines as an everything except for windows developer so it’s not just you. It would be good if someone could clarify.

yeah it's horseshit. The picker just let's you pick a file path.

The Win32 API also requires you to specify that you want to truncate the existing files.

How the fuck else would it work ? An additional OpenFileButTruncateExisting() API ?

A SaveFileAndOverwriteExisting() API ?

You can argue for those, but this thread is idiotic. He tries to furiously backpedal towards the end, but if he doesn't know the difference between a picker dialog and actually writing a file, I am not sure why I'd pay him any attention.

Not only is the API called `FileSavePicker.PickSaveFileAsync` which any reasonable person would assume would give you a truncated file, but even Microsoft agrees that it should give you a truncated file.

https://news.ycombinator.com/item?id=35277561

`FileSavePicker.PickSaveFileAsync` manages to be redundant and ambiguous at the same time. Definitely wouldn't want to guess what that might do.

Sorry, my "reasonable" interpretation of the name tells me that it's a method to choose the file you want to save. It suggests absolutely nothing about actually writing data.

Now continue reading the rest of the sentence.

you are right. so it is the savefileandoverwriteexisting() api, with a bug. I stand corrected.

This same thing happens with windows 10 video editor if you export a file with the same name.

I've found that Snip & Sketch occasionally just doesn't save my screenshots. I'll click Save, it'll open the file dialog, I'll choose the directory and click Save. But, every now and again, nothing. The file just doesn't save.

so this is very similar to the Acropalypse vulnerability recently published about Google Pixel Pro phones?

https://www.da.vidbuchanan.co.uk/blog/exploiting-acropalypse...

Yes. If you follow the linked thread:

- https://twitter.com/David3141593/status/1638222624084951040

- https://twitter.com/ProgramMax/status/1638217206180741121

Not just the Api but also Microsoft‘s screenshot tool. Which is a tool worse imho. than its predecessor and that was already weak. MFT maybe just fix it by starting from scratch here and do it right this time.

I had this same issue in a .NET program. "Whoops, forgot to SetLength(0)" But now in hindsight I probably used the wrong FileMode, since FileMode.Create is supposed to create or truncate.

Also notable, per the docs[1],

If you try to show the file picker while your app is snapped the file picker will not be shown and an exception will be thrown. You can avoid this by making sure your app is not snapped or by unsnapping it before you call the file picker. The code examples in FileSavePicker and the File picker sample show you how.

The example on the linked FileSavePicker[2] page "shows you how" by presenting a sample excerpt that calls an "EnsureUnsnapped" method that is neither a part of any documented API nor defined in any version of the sample I can find in GitHub.

Wasting considerable time, I managed to dig up an older version of the sample[3], ca. March 2013, that matches the doc excerpt. As it turns out, "EnsureUnsnapped" is defined in terms of a "TryUnsnap" method[4] that is deprecated because "window snapping" in the sense used here apparently only applies to store apps running on Windows 8.1 and earlier — notably, this includes the still-supported Windows Server 2012 R2 — and must not be confused with the current feature also officially known as window snapping.

From this I assume this warning only applies to apps that need to work correctly on obsolete or nearly-obsolete versions of Windows, and it only took me the better part of an hour to figure this out.

One of my biggest gripes with Microsoft is their somewhat recent tendency to memory-hole online-exclusive documentation and related materials for older versions of Windows that some of us, by hook or crook, are required to at least occasionally support, because telling an important customer to fuck off because their otherwise functional, fully security-patched OS is no longer under "mainstream" Microsoft support is a great way to lose said customer.

Is either providing offline documentation or maintaining an online archive of older documentation really too much to ask? Given the time and effort Microsoft has clearly invested in redesigning their developer documentation site every few years, the effort required to do the latter seems like a drop in the bucket.

To provide an illustrative counterexample: I can still find pinouts for the ports on my 128K Macintosh[5] or helpful tips to ensure my desk accessory is compatible with Font/DA Mover[6] if I need them, even if the relevant pages haven't been restyled since the late '90s.

[1] https://learn.microsoft.com/en-us/uwp/api/windows.storage.pi...

[2] https://learn.microsoft.com/en-us/uwp/api/windows.storage.pi...

[3] https://web.archive.org/web/20130403000823/http://code.msdn....

[4] https://learn.microsoft.com/en-us/uwp/api/windows.ui.viewman...

[5] https://developer.apple.com/library/archive/technotes/hw/hw_...

[6] https://developer.apple.com/library/archive/technotes/pt/pt_...

Reply on news.ycombinator.com