Apple Mail Filing Issue

Apple Mail has started to be unable to perform filing functions that it has always done until now. For example, using the "Move To" function....after a long pause I will get a dialogue box that says:

Message could not be moved to the mailbox â€œMailbox Nameâ€
Couldnâ€™t load body for â€œMessage Nameâ€

And, at the bottom of the window with the list of Mailboxes, it says:

Preparing to move messages 6 of 9

If I try to file the same message using the "Copy To" function it still says:

Message could not be moved to the mailbox â€œMailbox Nameâ€
Couldnâ€™t load body for â€œMessage Nameâ€

Except, this time, at the bottom of the window with the list of Mailboxes, it says:

Preparing to move messages 1 of 2

Anyone else having this issue? Anyone have any ideas?

Is "Mailbox Name"...

On my Mac?
An IMAP mailbox?
Google Mail?
what and where?

â€¢ Yes
â€¢ Yes
â€¢ No. Apple Mail
â€¢ In the Inbox. An email sent, and two replies in chain

All of the above doesn't now matter. I did a directory rebuild with Disk Warrior, rebooted, and the email filed without issue. Go figure.

It's all little zips and zaps of electrical charge moving through the aether. The fact that any of it works at all is amazing!

Originally Posted By: ryck

Apple Mail has started to be unable to perform filing functions that it has always done until now.

Just an FYI, but the problem inexplicably popped up again, in exactly the same conditions as described just above, and the solution was the the same....run a Disk Warrior directory rebuild and reboot.

Two failures like that would make me very suspicious of a deeper problem with your boot volume. If it is a rotating rust drive I would run a full surface scan. If it is ab SSD I would take a close look at the detailed S.M.A.R.T. report. Unfortunately I only know of one app that provides either report â€” TechTool Pro 11.

Originally Posted By: joemikeb

If it is a rotating rust drive I would run a full surface scan. If it is ab SSD I would take a close look at the detailed S.M.A.R.T. report.

I have a foot in both camps with a Fusion Drive. My "About this Mac" says:

Physical Volumes:
disk0s2:
Device Name: APPLE SSD SM0032L
Media Name: APPLE SSD SM0032L Media
Size: 27.55 GB (27,551,166,464 bytes)
Medium Type: SSD
Protocol: PCI-Express
Internal: Yes
Partition Map Type: GPT (GUID Partition Table)
Status: Online
PV UUID: 9A1E38C3-B6DF-462A-927F-90707416F920
disk1s2:
Device Name: APPLE HDD ST1000DM003
Media Name: APPLE HDD ST1000DM003 Media
Size: 999.35 GB (999,345,127,424 bytes)
Medium Type: Rotational
Protocol: SATA
Internal: Yes
Partition Map Type: GPT (GUID Partition Table)
Status: Online
S.M.A.R.T. Status: Verified
PV UUID: 50B19383-F528-492E-B3A4-2841AF4C391D

Originally Posted By: joemikeb

Unfortunately I only know of one app that provides either report â€” TechTool Pro 11.

Would Drive Scope provide sufficient information? If so, it would be a lot cheaper way to go without duplicating a lot of the functionality I already have with Disk Warrior.

I will be honest and say I have no experience with Drive Scope on a Fusion Drive, but the NVMe report is essentially the extended S.M.A.R.T. report but gives no indication of the acceptable/expected range. It does NOT offer a surface scan function for the HD portion of the Fusion drive, which is by far the largest component. Unfortunately S.M.A.R.T is quite good at detecting failures, but Surface Scans are superior at PREDICTING failures on rotating rust media. That is specifically why I have stuck with TTP instead of DiskWarrior albeit DiskWarrior probably has the edge in performing volume repairs.

Although it seems as if it should, I don't know specifically that it relates to fusion drives, but I can post a Terminal command for running a surface scan.

It seems like something Apple should have built into the OS when they stopped giving us TechTool Deluxe discs with our Macs; there's no reason we should have to buy $100 software to accomplish so basic and simple a task.

Originally Posted By: artie505

Although it seems as if it should, I don't know specifically that it relates to fusion drives, but I can post a Terminal command for running a surface scan.

It's worth a try. Thanks.

Since I've got zero experience with fusion drives, and the command was written before there were fusion drives, let's start at square one with the results of running

Code:

diskutil list

in Terminal.

More: Just to be on the safe side, I"ll remind you to edit out your name.

Originally Posted By: artie505

....let's start at square one with the results of running

Code:

diskutil list

in Terminal.

And the winning number is:

Last login: Mon May 13 01:51:23 on console
iMac:~ myname$ diskutil list
/dev/disk0 (internal):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 28.0 GB disk0
1: EFI EFI 314.6 MB disk0s1
2: Apple_CoreStorage Macintosh HD 27.6 GB disk0s2
3: Apple_Boot Boot OS X 134.2 MB disk0s3

/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_CoreStorage Macintosh HD 999.3 GB disk1s2
3: Apple_Boot Recovery HD 650.0 MB disk1s3

/dev/disk2 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD +1.0 TB disk2
Logical Volume on disk0s2, disk1s2
E101F0BD-BB8D-4EBD-9B01-37434753D47C
Unencrypted Fusion Drive

/dev/disk3 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *320.1 GB disk3
1: EFI EFI 209.7 MB disk3s1
2: Apple_HFS Time Machine 319.7 GB disk3s2

iMac:~ myname$

Originally Posted By: man

DESCRIPTION
diskutil manipulates the structure of local disks. It provides information about, and allows the administration of, the partitioning schemes, layouts, and formats of disks. This includes hard disks, solid state disks, optical discs, disk images, APFS volumes, CoreStorage volumes, and AppleRAID sets. It generally manipulates whole volumes instead of individual files and directories.
VERBS
Each verb is listed with its description and individual arguments.
list [-plist]
[internal | external] [physical | virtual] [device]
List disks, including internal and external disks, whole disks and partitions, and various kinds of virtual or offline disks.
If no argument is given, then all whole disks and their partitions are listed.
You can limit the number of disks shown by specifying filtering arguments such as internal above, and/or a device disk. When limiting by a disk, you can specify either a whole disk, e.g. disk0, or any of its slices, e.g. disk0s3, but filtering is only done at the whole disk level (disk0s3 is a synonym for disk0 in this case).
If -plist is specified, then a property list will be emitted instead of the normal user-readable output.
A script could interpret the results of diskutil list -plist and use diskutil info -plist as well as diskutil listFilesystems -plist for more detailed information.
The top-to-bottom appearance of all whole disks is sorted in numerical order by unit (whole disk) number. However, within each whole diskâ€™s "sublist" of partitions, the ordering indicates actual on-disk location. The first disk item listed represents the partition which is located most near the beginning of its encompassing whole disk, and so on.
When viewed this way, the slice (partition) parts of the BSD disk identifiers may, in certain circumstances, not appear in numerical order. This is normal and is likely the result of a recent partition map editing operation in which volumes were kept mounted.
Note that both human-readable and plist output are sorted as described above.
See the DEVICES section below for the various forms that the device specification may take for this and all of the other diskutil verbs.

In other words "diskutil list" lists the volume structures on the drive(s) â€” the same as found in the System Report. It does NOT perform anything remotely resembling a surface scan which can take an hour or more to perform depending on processor speed, I/O speed, and drive capacity. The key number in a surface is NEW bad/remapped data sectors which indicates the magnetic media is beginning to flake off of the drive surface.

Originally Posted By: joemikeb

..."diskutil list" lists the volume structures on the drive(s) â€” the same as found in the System Report. It does NOT perform anything remotely resembling a surface scan....

I asked ryck to run "diskutil list" because I wanted to ensure that I incorporate the correct disk ID in the command I'm going to post.

My uncertainty arose from the fact that ryck is running a fusion drive, and the command I've got is for either a HDD or SSD, and it was well founded, because the disk ID for ryck's FD differs from the HDD/SSD ID, necessitating a change in the command. (See screenshot)

Surface scan command coming in a bit.

Edited by artie505 (05/14/19 03:56 AM) ET
Edit Reason: Add link

Thanks for the posting your "diskutil list" output; it enabled me to tailor this command for your fusion drive.

Code:

sudo dd if=/dev/rdisk1 of=/dev/null conv=noerror bs=1024000

If you've never run "sudo" before, Terminal will pop up a warning along the lines of you're risking starting a nuclear war between Bora Bora and Pago Pago if you do something wrong; just click past it.
Terminal gives you no indication that you've entered your p/w...no dots, dashes, or stars; just hit return after you've entered it.
A traditional surface scan runs one 512 byte block at a time and can take an awfully long time depending upon various factors, so to speed this up, I've defined a block as 1,024,000 bytes; if you've got bad blocks, it's output won't be fully detailed, but you can rerun it in exquisite detail if that turns out to be the case.
joemike is spot on about the critical factor being newly developed bad blocks, but since your drive has never been scanned (I assume), the best we can do is whatever comes up.

If you'd like to set your head spinning, you can read through Surface scan doesn't run from Terminal? and Permission Repairs Error Messages.

Originally Posted By: artie505

Thanks for the posting your "diskutil list" output; it enabled me to tailor this command for your fusion drive.

I gave it a shot and didn't get any dire warnings, but neither did I get any action. When it asked for password, I entered my login password and got this response:

Last login: Tue May 14 18:17:00 on ttys000
iMac:~ myname$ sudo dd if=/dev/rdisk1 of=/dev/null conv=noerror bs=1024000
Password:
dd: /dev/rdisk1: Operation not permitted
iMac:~ myname$

I've run that command successfully on both HDDs and SSDs, so I guess something about your fusion drive is stymying it.

I'd try again after changing "rdisk1" to "disk1," and if that's still a no-go, we may need some input from V1 (who originally posted the command).

Originally Posted By: artie505

I'd try again after changing "rdisk1" to "disk1," and if that's still a no-go, we may need some input from V1 (who originally posted the command).

Still a no-go. The result I got, after entering my password, was the same:

Last login: Wed May 15 11:49:50 on ttys000
iMac:~ myname$ sudo dd if=/dev/disk1 of=/dev/null conv=noerror bs=1024000
Password:
dd: /dev/disk1: Operation not permitted
iMac:~ myname$

OK, I'll start a new thread and see if V1 or someone else knows what's happening.

Posted in error...no useful content.

I just discovered what may be stymying your Surface Scan. Beginning with High Sierra (MacOS 10.13) Apple no longer permits a surface scan of the boot drive. You have to boot from another volume to run the surface scan on your normal boot drive.

Thanks for the input, but since this sequence began I've run the command on my SSD while booted into my boot drive...Mojave (macOS 10.14.5), so whatever reference you've found doesn't seem to be applicable.

Maybe it's applicable to fusion drives only?

I hope it's worth a few minutes of ryck's time for him to experiment.

Afterthought: That doesn't compute!

Did you mean that you've got to run a scan from a DRIVE other than your boot drive, i.e, an external (which I"ve already disproved).

Originally Posted By: artie505

Did you mean that you've got to run a scan from a DRIVE other than your boot drive, i.e, an external (which I"ve already disproved).

My understanding is that it can be done from the Recovery Drive or from another bootable partition such as TTP's EDrive.

Originally Posted By: joemikeb

Originally Posted By: artie505

Did you mean that you've got to run a scan from a DRIVE other than your boot drive, i.e, an external (which I"ve already disproved).

My understanding is that it can be done from the Recovery Drive or from another bootable partition such as TTP's EDrive.

How about another macOS bootable partition?

Under any circumstances, though, as I've said, I've run the command on my boot drive from my boot volume in macOS 10.14.5, so... Got me beat!

Back to the start of this thread....trying to file a message but getting a dialogue box that says: Message could not be moved to the mailbox â€œMailbox Nameâ€

I'm beginning to think the issue is not about a bad sector, but rather a glitch in Apple Mail. Why? Because I have gone through a disk partition and then back to a single partition which, I assume would likely have Apple Mail installed somewhere other than where it was previously.....perhaps not where a bad sector might be.

Today's solution was the same as in April....I did a directory rebuild with Disk Warrior and Apple Mail started filing correctly again.

ðŸ¤¦ðŸ»â€â™‚ï¸Doh!

I just re-read your initial post and your response to my first questions and promptly gave myself a "dope slap" for having overlooked the obvious. This is an IMAP account and unless you are moving the message to a mailbox you have created "On My Mac" mailbox you are moving the message to IS NOT ON YOUR COMPUTER! â€” it is on the email provider's IMAP server. There are myriad of reasons the message could not be moved, but all of them are completely outside of your computer and your control.

If that is the case, a reasonable question would be, "Why would the volume rebuild correct the situation?" The answer is that it would not have any direct effect but there would be a time interval for the email provider, ISP, whoever, or what ever was the source of the problem to correct itself or to be corrected. I use Airmail rather than Mail as my email client and in retrospect I saw a similar message recently and since it was not critical I didn't think anything about it. However, I don't recall which of my email accounts it was on, but the likelihood is it was Apple.