MacOS – are files from macs often encrypted when copied to a hard drive and viewed from Windows

encryptionmacos

Why are files from macs often encrypted when put on an external drive and that drive is plugged into a windows system?

I'll explain what I mean 'cos they don't look encrypted at first sight, as you can open them..

but on closer inspection, they can show up green in windows explorer

enter image description here

and the windows cipher command shows then as encrypted, and their attribute properties show as encrypted.

enter image description here

I'm not the only person that has run into this, looking for example How to list encrypted files in Windows 7? one poster writes "… I was cleaning up a external hdd and came across 150 files that where encrypted. So I wanted to know what and where they were as I do not use a encryption on my computers. Turns out it was from a few downloads that I can easily get. Or seeing "_MACOSX" folders on my pc. They are always encrypted."

An example I ran into is a program I wrote in rails just a directory called "scaffoldingtest1" that I created with the command rails new scaffoldingtest1 and i'd have copied a parent directory to an external hard drive.

I've also seen some PDFs related to adobe, from Mac users.

And they're encrypted as if they were encrypted on the windows machine, in that they can only be viewed from that windows username @ that computer. As shown in the properties of the encryption in windows. And that user at that computer can decrypt them. But they somehow got encrypted like that. If that external drive were taken to another windows computer, then they can't be read.

And i'm wondering what setting on OSX is causing that?

Note- since some moderators have a tendency to delete long comment threads and lose important info, here is a link to the comment thread at the moment backed up here as of 21/11/2020 20:13 UK time https://pastebin.com/raw/f2Aytv6W

Best Answer

The reason for this is a known compatibility issue with the built-in macOS Archive program and the built-in unzipper in various Windows versions.

When you use the "Compress" tool built-in to Finder, you'll get a ZIP-file. The ZIP-file contains, amongst other things, what is known as "external file attributes" for each file. These attributes are host-system dependent (i.e. these attributes are not guaranted to be understood the same way on various operating systems).

Unfortunately, one of the attributes that the macOS tools marks the files with are interpreted by the Windows built-in unzip tool as marking the file as "encrypted" (which is a special form of single-file encryption built-in to the NTFS file system). This means that when unzipped the files have the encrypted attribute and their names are shown in green in the Windows Explorer.

However, there are no significant downsides to this as you can easily open Properties on the files and remove the checkmark on the "encrypted" attribute. The file contents is not really encrypted, so the files can be opened as always.

You can avoid this issue by either using a different compression tool on the Mac, or by using a different decompression tool on Windows.

The technical details are as follows:

The problem is caused by the Windows unzipper incorrectly parsing the "external file attributes" in the ZIP-header for each file/folder. This element of the header is host-dependent, as such the unzipper should check the element of the centrall directory file header known as "Version made by" to inspect which operating system made the file. The macOS compression tool correctly stores the attribute value 3 for "Unix" here.

Unfortunately the Windows tool disregards this value and always interprets the file attributes as though they were created on Windows. The "encryption" issue comes from the fact that ZIP-files created on Windows stores file attributes according to the file attribute constants (FILE_ATTRIBUTE_<...>) defined by Microsoft. In particular FILE_ATTRIBUTE_ENCRYPTED defined by the value 0x4000 means encrypted file or directory. However Unix-systems use the POSIX constants where S_IFDIR is the attribute that means "this is a folder" - and is typically defined as the value 0040000, which is equivalent to 0x4000.