MacInTouch Amazon link...
Channels
Apple, Products
I have an old MacBook Pro which needs replacing. It seems to be using most of the 512GB hard drive, so best order the new one with a 1TB SSD.

'About This Mac' says there is 80 GB available and that 206 GB is being used by "System" (rounding the figures here). But Finder reports my usage as 327 GB, but still with only 80 GB free, which doesn't add up to 512.
Is the drive formatted as APFS? What does Get Info on the drive report?

Some disk space reports exclude purgeable files. For example, MacBooks have Mobile Time Machine automatically available, which uses up free space, but macOS won't report that space as used.

On the other hand, APFS creates challenges in reporting the size of files. Let's say you make a copy of a 1 GB file. On APFS this occupies 1 GB, but the Finder counts it twice, for 2 GB. If you migrate it to a new computer, it would then actually take 2 GB, because the cloning or migration won't retain the APFS blocks.

That gives you one way to get a good estimate of drive size needed: use SuperDuper or Carbon Copy Cloner to clone the MacBook Pro to another drive, then see how much space was used. That's how much space it would initially take on a new computer.
 


use SuperDuper or Carbon Copy Cloner to clone the MacBook Pro to another drive, then see how much space was used.
Thanks, that was a helpful idea. I've used ChronoSync and made a bootable mirror of the (APFS) MacBook Pro SSD to an HFS+ hard drive. And, yes, there is less space being used on the hard drive; 300 GB vs 432 GB on the SSD.

So I guess I'd be safe with a new Mac and a 512GB SSD. On the other hand, I wouldn't be able to swap it out for a bigger one if need be...
 


...So I guess I'd be safe with a new Mac and a 512GB SSD. On the other hand, I wouldn't be able to swap it out for a bigger one if need be...
These days I recommend 500/512 GB as the minimum boot SSD size for a "regular" user - large graphics libraries can be stored on an external drive. For notebook users doing heavy graphics, I recommend at least 1 TB.
 




Help, not sure if there a change in macOS or there is some accidental customization I did. "Command L" was a shortcut to make an alias. However, now if I select a video file and select "Command L", the Finder pulls up a box and tries to rotate the video! I want to go back to Make Alias.
 


Help, not sure if there a change in macOS or there is some accidental customization I did. "Command L" was a shortcut to make an alias. However, now if I select a video file and select "Command L", the Finder pulls up a box and tries to rotate the video! I want to go back to Make Alias.
Try Control-Command-A. Can't remember when it changed.
 


On the subject of Apple failing to adhere to user interface guidelines, I'm getting really bugged by how the Finder handles file name extensions in High Sierra. I even opened a bug report, which Apple closed as "duplicate of a closed bug report", which doesn't tell us much.

Long-time OS X users will remember the bombshell when Apple announced that starting with OS X 10.1 Puma, file name extensions are mandatory in OS X. You can read all about it in John Siracusa's Puma review, which references his magnum opus analysis of OS X file system metadata, and why putting file type metadata in the file name is so horribly wrong.

But I suppose that ship has sailed. At least when Apple made extensions mandatory, they also added methods for the Finder to hide the extension and automatically do the right thing (or when unsure, ask the user), following the guiding principle of "what you see is what you typed".

Apple documented the correct behavior in a File Name Extension Guidelines publication. It says things like:
Apple said:
In no case will ... renaming a file ever result in accidental multiple extensions (like "mygroovyimage.jpg.jpg").
But High Sierra is breaking all the rules. Here are a few examples:
  • Have a file named "test.pdf", with the extension not hidden. Attempt to rename it in the Finder to "test", i.e. try to remove the extension from the visible file name. The result in High Sierra is that the Finder will reject the rename. (Previously it would change the visibility attribute to hide the extension.)
  • Have a file named "test.pdf", with the extension hidden, so what you see is just "test". Attempt to rename it to add .pdf. The result in High Sierra is that the Finder rejects the rename. (Previously it would change the visibility attribute to make the extension visible.)
  • Have a file named test.js, with the extension not hidden. Rename it to test.js.bkp. The result is that the file is renamed to test.js.bkp.js, and it changes to hide the extension. This means that it appears to the user that the rename was successful, but in fact, the Finder did something completely different, and then literally hid what it did from the user.
On the first two tests the Finder behaves differently if the user renames any part of the file other than the extension. For example, if you attempt to rename test.pdf to test it fails, but if you rename test.pdf to test1 then it works. Why?

The last test would appear to flat out violate the File Name Extension Guidelines prohibition against user-initiated renames spuriously creating multiple extensions.

Sierra did not have these problems!

What I can't figure out: is all this by design, following some inscrutable logic for what the Finder should be doing? That is, did Apple think that the changes are making the Finder better? That the new Finder knows more than the user about what the user wants to do?

Or, is it just some programmer at Apple breaking things because they don't understand the intent of the documented guidelines? Perhaps the fact that the guidelines are gone from the Apple developer site means that the current developers have nothing to reference for how it should work. The file name extension ship has sailed, but now it is adrift.

What do you want to bet that the duplicate bug report that Apple used to reject my bug report, was closed as "working as designed"? I'd say the current state of the Finder would better be characterized as BAD (Broken As Designed).
 


Ric Ford

MacInTouch
On the subject of Apple failing to adhere to user interface guidelines, I'm getting really bugged by how the Finder handles file name extensions in High Sierra. I even opened a bug report, which Apple closed as "duplicate of a closed bug report", which doesn't tell us much....
As you, too, demonstrate, Apple has not only refused to FTFF for years and years and years, it has actually made it worse and refused to fix stunningly obvious bugs it introduced, years later, even when they were formally reported. It's crazy, and I no longer waste my time and effort reporting even blatent/perverse macOS bugs, because the jerks running Apple just don't care about fixing them.
 



Help, not sure if there a change in macOS or there is some accidental customization I did. "Command L" was a shortcut to make an alias. However, now if I select a video file and select "Command L", the Finder pulls up a box and tries to rotate the video! I want to go back to Make Alias.
Apple says:
Mac keyboard shortcuts
Command-L: Makes an alias of the selected item.
Published Date: April 4, 2019
but, no, it hasn't worked that way for some time. RTFM, indeed.
 


Have a file named "test.pdf", with the extension not hidden. Attempt to rename it in the Finder to "test", i.e. try to remove the extension from the visible file name. The result in High Sierra is that the Finder will reject the rename. (Previously it would change the visibility attribute to hide the extension.)
Here, in Mojave, and as far as I remember (I upgraded two weeks ago) in High Sierra, it works as before: Removing the extension or renaming without the extension hides the extension.
Have a file named "test.pdf", with the extension hidden, so what you see is just "test". Attempt to rename it to add .pdf. The result in High Sierra is that the Finder rejects the rename. (Previously it would change the visibility attribute to make the extension visible
Also this works, and worked, in High Sierra and now in Mojave, as before: Adding the hidden extension will make it visible again.
Have a file named test.js, with the extension not hidden. Rename it to test.js.bkp. The result is that the file is renamed to test.js.bkp.js, and it changes to hide the extension.
Yes, that works the same here.
I can imagine that this is indeed intended behaviour Many users, probably the vast majority, have no idea what the consequences are of changing the file name extension. So the Finder is designed to make it difficult to change it without an extra step. When I want to change (not add) an extension, I get a warning (can be set in Finder preferences) asking me if that is indeed what I want to do.

And one can always change the extension in the Finder Info panel for the file.
 


  • Have a file named "test.pdf", with the extension not hidden. Attempt to rename it in the Finder to "test", i.e. try to remove the extension from the visible file name. The result in High Sierra is that the Finder will reject the rename. (Previously it would change the visibility attribute to hide the extension.)
  • Have a file named "test.pdf", with the extension hidden, so what you see is just "test". Attempt to rename it to add .pdf. The result in High Sierra is that the Finder rejects the rename. (Previously it would change the visibility attribute to make the extension visible.)
Works the way you would like in Mojave.
 



DFG

Here, in Mojave, and as far as I remember (I upgraded two weeks ago) in High Sierra, it works as before: Removing the extension or renaming without the extension hides the extension.
And that would be wrong. File names without extensions are perfectly legal in macOS, as they have been from the very beginning. The change introduced in Puma was that the extension takes precedence over the metadata - a giant blunder by Apple, in my opinion.
 


Another problem with extensions in file names is that files from some servers download with badly formed names. One press site I use regularly serves PDF files so their names download with single quotes around them, e.g. 'sample.pdf' which High Sierra sees a file name without an extension. It's smart enough to open it with a PDF reading app, but it still requires you to change the manually to the correct form. A patient information system accessed by patients and doctors appends two copies of the extension -- .pdf.pdf . I don't know whose fault these mistakes are, but the press site has been doing that for a couple of years.
 


The change introduced in Puma was that the extension takes precedence over the metadata - a giant blunder by Apple, in my opinion.
No mistake in my opinion. It was the start of a deliberate transition from type and creator metadata to file name extensions for the sake of compatibility with other platforms.
 


DFG

No mistake in my opinion. It was the start of a deliberate transition from type and creator metadata to file name extensions for the sake of compatibility with other platforms.
Why does macOS need to regress to the (low) level of other OSes? The extension would still work if you copied a file from Windows, as there are no type/creator data then. So there is practically no downside in terms of actual interoperation with other OSes. This was an abdication by lazy/misguided minds, perhaps a younger generation of Apple engineers who did not grow up with the classic Mac and did not appreciate its many fine nuances.
 


Help, not sure if there a change in macOS or there is some accidental customization I did. "Command L" was a shortcut to make an alias. However, now if I select a video file and select "Command L", the Finder pulls up a box and tries to rotate the video! I want to go back to Make Alias.
Apple decided to change the "Make Alias" keyboard shortcut from "Cmd-L" to "Cmd-Ctrl-A" in Mojave.

At the moment, Apple isn't using "Cmd-L" for anything else in the Finder, so you can revert to the traditional behavior without trouble by creating a custom keyboard shortcut for the Finder. To do so, go to the Keyboard panel in the System Preferences, click "Shortcuts", then "App Shortcuts", then "+", choose "Finder" from the resulting pulldown menu, type "Make Alias" in the "Menu Title" field, click in the "Keyboard Shortcut" field and hold the "Command" and "L" keys simultaneously, and then click "Add."

Keep in mind that Apple may decide to use Cmd-L for something else someday, so this customization may have issues with a future release of macOS.
 


How far Apple has drifted from the days of the six-color icon, the revolutionary operational breakthrough represented by Mac OS 6 and 7, and the "Think Different" campaign that marked the start of Apple's triumphant return from near extinction. When I think of Apple these days I hear the Righteous Brothers singing in my head, "Something beautiful's dying."
 


Thanks. Still I don’t see documentation for "keyboard shortcut” that shows “Command L” rotates things left. Is that normal behavior?
It's not Apple documentation, but this indicates it worked, at least for Preview (not Finder), as far back as Snow Leopard.

And this indicates that Command-L still created an alias in Finder in Sierra.

So my guess is that the change is a gift from Apple in Mojave, concurrent with the introduction of Finder Quick Actions.
 




And that would be wrong. File names without extensions are perfectly legal in macOS, as they have been from the very beginning. The change introduced in Puma was that the extension takes precedence over the metadata - a giant blunder by Apple, in my opinion.
Note that removing an extension will break the Finder's ability to launch the corresponding app if the file doesn't have the correct Type/Creator codes in its metadata. Files you download/transfer from non-Mac systems won't have these. And I suspect you will find many apps where the authors are lazy and fail to use them, or use them incorrectly.
 


Another Finder issue is an annoying problem for me in a Finder window when using folders created by Logic Pro X in Sierra. (I haven't checked to see if the same scenario applies to other types of folders.)

I have many Logic Pro X folders, and I back them up manually to a USB stick to move back and forth between thre different Sierra laptops to work on the most current version of the song project. Sometimes, when making changes to a Logic project, the external folder viewed in the Finder reflects the time/date change of the project file within the individual folder via the "Date Modified" column. Most of the time it does not, and I don't understand why the folder would not reflect the current time/date of the most recently changed .logicx file within it.

One workaround I've used is to not open a current project from inside the application with "Opened Recently", but instead I open it up via the Finder window. I have also added a column to the Finder window called "Date Last Opened", which works to show the most recently changed projects, as long as I open each .logicx project from the Finder window.

Another possible workaround - I haven't tested this yet (because if it works, I have about 100+ current projects I'd have to manually make this change to): I could go into Logic Pro X and re-save each project one at a time as a package instead of a folder. I'm guessing then that the package when viewed in a Finder window would reflect the most current file change from within it?

Am I missing something simple here as to why the Logic folders when viewed in the Finder don't always reflect the most recent .logicx changes from within? I don't want to spend a ton of extra time on this if there is a simple fix for it. Any thoughts on a solution?
 


With regard to the discussion on the move from the pre-OS X type and creator used by the Finder to the present apparent dependence on file extension (à la Windows):

Every other Unix I've worked with, including Linux, supported the use of a "Magic" file. This file defines information for the file command to type and classify the file based on the signatures found in the file. It includes a declaration for the file creator and types that were used up to Mac OS X.

macOS supports it as well. The full documentation can be found by executing
Bash:
man 5 magic
from the terminal (as it's in the administration section, 5, of the Unix manual set).

Why Apple didn't apparently use this features to preserve type/creator or use any other signature to identify the apps that can open the file escapes me.
 



Am I missing something simple here as to why the Logic folders when viewed in the Finder don't always reflect the most recent .logicx changes from within? I don't want to spend a ton of extra time on this if there is a simple fix for it. Any thoughts on a solution?
Sorry, Dave. I can't open the door to that knowledge. What you are missing is by no means simple.

Most project top-level folders contain one or more subfolders that may contain files or additional subfolders. Finder rules for defining modification dates are obscure at best. Changes to subfolder contents generally affect the modification date of the folder enclosing the modified elements. But the modification date change of a subfolder is not considered a change to the subfolder's enclosing folder.

I can only positively state that computers are not programmed to behave as we expect them to be programmed, but rather to meet the expectations of a software development manager. This was often subject to modification by Steve. No longer is this the case.

There is no simple fix, short of modifying your expectations, as in, for instance, using project information to determine change dates rather than guessing from Finder modification dates.
 


Sorry, Dave. I can't open the door to that knowledge. What you are missing is by no means simple.
No worries James. It is what it is. I went ahead and tried the package idea from my previous email:
I could go into Logic Pro X and re-save each project one at a time as a package instead of a folder. I'm guessing then that the package when viewed in a Finder window would reflect the most current file change from within it?
It did work as I thought it might. As soon as I make a change in Logic to the project, it is reflected in the package "Date Modified" column in the Finder window. It only takes about 30 seconds to re-save a project as a package, so within the week, I should have most or all of them done. This will make it much easier to see which songs have changed within the last couple of days for transfer to a different computer.
 


Sometimes, when making changes to a Logic project, the external folder viewed in the Finder reflects the time/date change of the project file within the individual folder via the "Date Modified" column.
Finder rules for defining modification dates are obscure at best.
Modification dates are actually updated in a clear manner: Has the file changed? If so, update the date.

This happens at the OS level, so Finder is not involved at all, except that it reports the date to the user. Directories/folders are stored as a type of file, which contains data about the folders' contents, and thus updated like any other.

What's obscure is the user not always seeing what has changed.

Was a file renamed? Some programs, in order to be sure saves are consistent, write the updated file to a new one, then rename it over the old, making it appear the folder contents haven't changed. Does Apple's versioning system apply here? I don't know.

Was a hidden file added or removed? Finder doesn't show hidden files, so this is easy to miss. And, of course, this also applies to regular files, which are easy to miss if the folder is for a project or bundle whose contents you don't directly control.

And as James points out, a change to the contents of a subfolder won't be reflected in the date of the main folder, because the main folder itself doesn't need to change.

Since the folder in question for Dave G. is for a Logic Pro X project, this means that the Project folder's modification date is determined by whether Logic Pro X does any of those actions to the main folder. So whether Dave sees the project modification date change is likely dependent on what changes Dave makes to the project. It could also be dependent upon how long the project is in use, if Logic uses temporary files that are deleted on save (see rename case above).

A potential issue is that Finder doesn't always notice or immediately report when a file or folder listed within a visible folder window is updated. Finder is actively monitoring the window's folder for changes, not the data about any files or folders within it (it checks them periodically, but likely slower than is helpful here).

Lastly, an issue with using "Date Last Opened" is that Spotlight scans can update this as well.
 



Another Finder issue is an annoying problem for me in a Finder window when using folders created by Logic Pro X in Sierra....
Regarding Logic Pro X files and the Finder, I suspect that Dave G. was experiencing the subfolder-not-updating-the-folder finder behavior. I save my Logic Pro projects as packages, so I didn't have that problem. When saving a Logic project as a folder, that folder has subfolders with the files that get updated.

I ran into this problem using Photoshop (I'm still using CS 6). I keep my Photoshop files organized by folder, within a "Photoshop Files" folder, with subfolders inside those subfolders. Those enclosing folders inside don't get updated when I add new files.

I tend to view windows in the Finder organized by date, so what I'm working on is at the top, but for Photoshop and Illustrator I view them by name, since it's easier to find what I need. But I'd rather view windows organized by date. <Sigh>
 


I have been stupid and downloaded an app named "invisibliX" and before I knew it, I had hidden my "Users" folder. Whist I can confirm that files that reside within the folder are still visible via Spotlight and HoudaSpot, the actual folder is not present at the top-level directory as it once was. I have researched and tried a few Terminal commands without success. I have two Carbon Copy Clones a mere 2 hours old; however, before I wipe the SSD, I would like to at least try to recover the folder. I suspect it is "hidden" rather than "Lost'. Thank you for any assistance provided.
 


… the actual [Users] folder [hidden by invisibliX] is not present at the top-level directory as it once was….
Off to the Terminal, I think. This should find the missing Users folder:
Bash:
sudo find / -name Users -type d
Move the misplaced Users folder to the right place, making sure you are moving the correct folder. (My testing found Users folders in other places.)
sudo mv (/found/path/Users) /
Then either try to use invisibliX to find and fix the folder (File > Browse Hidden Files) or, back to Terminal:
Bash:
sudo chflags nohidden,nouchg /Users
Good luck.

P.S. This was tested by using invisibliX to hide and lock a test folder and inspecting it with
Bash:
ls -lOd folder
For details:
Bash:
man chflags
 




Handy Finder keystroke shortcut to reveal invisible files/folders: Command-Shift-Period
Repeat to hide them again.
Under what OS? That doesn't work under El Capitan (OS X 10.11.6). And I don't recall seeing that option on any previous system. The way I see hidden files is to use something like TinkerTool.
 



It seems to work here under macOS Sierra 10.12.6's Finder.
I haven't played with Sierra much, so can't speak to that. But if the function has been added, I hadn't heard of it. Nice to know that Apple at least occasionally makes an improvement.
 


Under what OS? That doesn't work under El Capitan (OS X 10.11.6). And I don't recall seeing that option on any previous system. The way I see hidden files is to use something like TinkerTool.
Apparently it was introduced with Sierra, but since I don't have anything prior to High Sierra on hand, I can't confirm that. You won't have "seen" that option anyway because it isn't part of any menu (that I know of).
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts