Archive for February 15, 2018

Thursday, February 15, 2018

Can macOS Tell How Large a File Really Is?

The macOS programming class which provides most information about files is URL. It has quite an elaborate interface which involves telling a file URL object which ‘keys’ you want it to reveal, then accessing those that you want. In this case, the URLResourceKey in question is totalFileSize, which Apple’s developer documentation describes as:

Key for the total displayable size of the file in bytes, returned as an NSNumber object (read-only). This includes the size of any file metadata.

But apparently this refers to metadata from the resource fork. It does not count extended attributes.

The evidence from Precize is that the only accurate way to measure the full size of a Mac file is to total the sizes of each of its xattrs, and add those to the size of its data fork. That doesn’t appear to be a function performed by macOS, or at least it is not exposed anywhere to developers or users. So, as far as I can tell, macOS itself doesn’t have any direct access to the total size of any of its files – which seems a startling omission.

Howard Oakley:

I had not expected xattrs to be so heavily used in the /Library folder, but the average size of xattrs across its files which have xattrs is just over 7 KB per file. I had expected them to be commonplace in my Home folder, but am surprised that the average total size of xattrs across all the files there (not just with xattrs) is just over 2 KB.

[…]

The largest contribution is in ~/Documents, which has a total of 2.6 GB of xattrs across less than half a million files. However, a lot of my images in ~/Pictures still seem to sport thumbnails, so the average total of xattrs per file with xattrs is there almost 21 KB – that’s 0.796 GB in only 38018 files.

Bug Cocoa Extended Attributes Mac macOS 10.13 High Sierra Metadata

2 Comments

GitFinder 1.0

ZigZag:

Apple has finally come up with official way and API to extend Finder functionality and offer custom badges for icons, as well as contextual and/or toolbar menu items (actually, adding contextual menu items was possible prior macOS 10.6, but it required tons of Carbon code, while icon badging was never officially supported). That was in macOS 10.10, also known as Yosemite. I immediately remembered seeing people years before using TortoiseGit/SVN on Windows and thought it would be nice to have something similar on Mac. However, the API in 10.10 was crippled in many ways (especially when it came to menus), that I just filled a bunch of bug reports and stopped thinking about it. As it usually happens in the last 7-8 years, Apple didn't bother fixing those things in minor updates, so most issues haven't been fixed before 10.11 (El Capitan) came out, a full year later.

[…]

The end result is the application, which can be used solely as Finder's extension, giving you quick access to files' git statuses via icon badging and most frequently used git command via Finder contextual and/or toolbar item menu. But, you can also kick its repository browser window and use it as a separate, fully functional git client. Repository browser offers all you could expect from such client; full list of branches, tags, remotes, submodules and other references, commits list, commit diffs, commits search and others. All just a click in a Finder window away.

I’ve been testing this for a while, and it looks promising. I like being able to quickly get the history of a particular file by Control-clicking on it. And it’s nice to be able to click, search, or glob in the Finder to choose which files to stage or revert. The main site has some good screenshots that show what it can do. For me, at least, it’s currently more of an adjunct than a replacement for other clients. Like GitUp, it uses libgit2 rather than the git command-line tool.

Extensions Finder Git Mac Mac App macOS 10.13 High Sierra Version Control

3 Comments

Data Loss on APFS Sparse Disk Images

Mike Bombich (Hacker News):

Earlier this week I noticed that an APFS-formatted sparsebundle disk image volume showed ample free space, despite that the underlying disk was completely full. Curious, I copied a video file to the disk image volume to see what would happen. The whole file copied without error! I opened the file, verified that the video played back start to finish, checksummed the file – as far as I could tell, the file was intact and whole on the disk image. When I unmounted and remounted the disk image, however, the video was corrupted.
[…]
Following the earlier example, suppose you attempt to copy 200GB of data to that 500GB disk image file. This shouldn’t be possible, because there was only 100GB of free space left on the underlying disk. The APFS disk image reports that there’s 500GB of free space available, though, so what the heck, let’s do this! The first 100GB of data does successfully get written into the disk image file – the disk image file has grown now to 100GB. But now the underlying disk is completely full, and the disk image file can no longer grow – the diskimages-helper application is getting “No space left on device” errors when trying to write data to its band files.

But diskimages-helper simply ignores these errors.

Update (2018-02-17): See also: Thomas Claburn.

kbumsik:

These are not even complex problems of the new format. It is just Apple forgot to have basic checks. It is like the root access with an empty password incident happened 2 months ago. Why these serious but basic problems happen?

Update (2018-02-19): See also: MacRumors.

Apple File System (APFS) Bug Carbon Copy Cloner Disk Image Mac App macOS 10.13 High Sierra

5 Comments

Another iOS Crash Caused By Sending Unicode Character

Tom Warren (Hacker News, MacRumors):

A new bug has been discovered in iOS 11 that lets people send a specific character that will crash an iPhone and block access to the Messages app in iOS and popular apps like WhatsApp, Facebook Messenger, Outlook for iOS, and Gmail. Italian Blog Mobile World spotted the bug, and we’ve tested it successfully on multiple iPhones running iOS 11.2.5, and found it also works on the macOS versions of Safari and Messages. Apple plans to fix the problem in an iOS update before the release of iOS 11.3 this spring.

The bug itself involves sending an Indian language (Telugu) character to devices, and Apple’s iOS Springboard will crash once the message has been received.

I wonder if this is why Tweetbot was crashing on my Mac the other day.

Previously: Using Siri to Work Around iMessage Crash.

Update (2018-02-15): Ashley Bischoff:

At this rate, I’m kinda astounded that Apple still hasn’t yet run a fuzzer against Messages.

You’d think that someone at Apple would have brought up fuzzing after the first or second time that this sort of thing happened with Messages. But I guess not.

Update (2018-02-16): Rosyna Keller:

Likely because it’s not an issue in Messages or with the Unicode string itself. It’s a bug in the text renderer (which doesn’t necessarily lend itself to fuzzing).

Since some apps are unaffected, it means it also depends on layout options/factors.

Manish Goregaokar:

The original sequence is U+0C1C U+0C4D U+0C1E U+200C U+0C3E, which is a sequence of Telugu characters: the consonant ja (జ), a virama ( ్ ), the consonant nya (ఞ), a zero-width non-joiner, and the vowel aa ( ా).

[…]

And then I saw that there was a sequence in Bengali that also crashed.

[…]

So, ultimately, the full set of cases that cause the crash are:

Any sequence <consonant1, virama, consonant2, ZWNJ, vowel> in Devanagari, Bengali, and Telugu, where:

consonant2 is suffix-joining – i.e. र, র, য, and all Telugu consonants

vowel is not ై or ৌ

Paul Haddad:

Hey past me, good job on adding support for remotely filtering crashing unicode sequences.

Update (2018-02-20): Juli Clover:

Apple released iOS 11.2.6 to address a bug that causes apps like Messages to crash on the iPhone and iPad due to an inability to render a specific character in the Indian language Telugu.

There’s also a supplemental update for macOS 10.13.3.

Bug Core Text iMessage iOS iOS 11 Mac macOS 10.13 High Sierra Messages.app Springboard.app Unicode

6 Comments

Facebook’s “Protect” Feature

Adam C. Engst:

However, tapping Protect takes you to the App Store and displays an app called Onavo Protect — VPN Security. It is indeed a VPN — a virtual private network — that securely tunnels all your traffic through Onavo’s servers. The problem is that, as you might expect from the link source, Onavo is owned by Facebook. If you were to stumble on Onavo Protect in the App Store, you’d have to tap More and read the full description to discover that. If you read all the way to the end, you’d learn that Onavo Protect “directs all of your network communications through Onavo’s servers,” and that, “as part of this process, Onavo collects your mobile data traffic.”

Clearly, that menu item in the Facebook app should be labeled “Collect” instead of “Protect.”

Jamie Zawinski:

This lets Facebook “protect” you by intercepting and spying on the traffic of every other app on your phone including your web browser.

Nick Heer:

Even if you ignore potential anticompetitive issues, there’s still a question of whether users of Facebook’s VPN are adequately aware of how the company accessed and uses their data.

Previously: How Facebook Squashes Competition From Startups.

In other Facebook news, Kate Conger (via John Gruber):

Facebook is bleeding users, with external researchers estimating that the social network lost 2.8 million US users under 25 last year. Those losses have prompted Facebook to get more aggressive in its efforts to win users back—and the company has started using security prompts to encourage users to log into their accounts.

[…]

The texts are a particularly obnoxious form of spam, and instead of making me want to log into Facebook, they remind me why I’m avoiding it. It’s painful to see my ex’s name popping up on my phone all the time, and while my intern was great at her job, I’m not invested in keeping up with her personal life.

[…]

What’s most frustrating is that Facebook has taken a security feature like two-factor authentication—which gives users valuable protection from phishing and account takeovers—and perverted it into a tool for spam.

Update (2018-02-19): Nick Statt (Hacker News):

Facebook this evening clarified the situation around SMS notifications sent using the company’s two-factor authentication (2FA) system, admitting that the messages were indeed caused by a bug. In a blog post penned by Facebook Chief Security Officer Alex Stamos, the company says the error led it to “send non-security-related SMS notifications to these phone numbers.”