fsck not repairing unreadable files on MacBook Pro M1

phMak wrote:

Here is an example with a simpler file:

$ stat -x ulysse.mp3

File: "ulysse.mp3"

Size: 3503043 FileType: Regular File

Mode: (0644/-rw-r--r--) Uid: ( 501/pn) Gid: ( 20/ staff)

Device: 1,18 Inode: 432239 Links: 1

Access: Tue Oct 21 17:02:17 2025

Modify: Mon May 12 10:11:58 2008

Change: Tue Sep 16 09:12:10 2025

Birth: Mon May 12 10:11:58 2008

$ cp ulysse.mp3 /tmp

cp: /tmp/ulysse.mp3: fcopyfile failed: No such file or directory

$ wc ulysse.mp3

wc: ulysse.mp3: read: No such file or directory

$

•

The file exists in directory structure but is unreachable, whatever the tool I use to open it.

This seems to imply the directory entry is there, but the file itself is no longer connected to that entry. You can interact with the directory entry to get basic file stats, but cannot interact with the file itself as shown by the "cp" & "wc" commands.

Then for safety, I tried fsck and I saw these alarming messages about "alloced_size". I assume there is a relation between these fsk errors and the lost files. fsck didn't repair the errors and claims everything is OK.

First Aid lies about the summary results. It is Apple brushing the problems it cannot resolve under the carpet until things break, then will have people perform a clean install of macOS & restore from a backup.

If you look at the First Aid error messages you provided originally, they line up perfectly with what you are seeing with your "stat", "cp", and "wc" tests above.

error: alloced_size (4096) of dstream (id 403216) does not match calculated size (0)

This is showing the directory thinks the file is of size 4096, but the calculated value is 0. Seems to match the finding of your experiment.

So, I wonder:

if there is a risk that these errors will spread and corrupt more files,

Possibly. We don't know what caused the problem and probably will never know.

• if I can still trust my disk,

Can you? I personally would not trust it.

• if a complete reinstall will change something,

You would need to perform a clean install which involves having that APFS Data volume reformatted (aka "erased" in Apple speak) to create a fresh clean file system. On an M-series Mac you need to follow Apple's instructions in the following Apple article:

Erase your Mac and reset it to factory settings - Apple Support

I personally would use the "Disk Utility" version section of erasing the Mac since I am not 100% certain that Step #2 "Erase All Contents & Settings" will actually reformat that Data volume (likely it will, but Apple doesn't specifically mention that tiny detail...the "erasing" of content could just be macOS deleting items).

• if I should rather change of laptop ?

Do you need a new laptop?

Until you erase the file system or perform a DFU Firmware Restore.....you have not reached that point. You just have a corrupt file system. What corrupted the file system? No idea...it happens. As long as a hardware issue is not the cause, then this laptop can still be used normally once you deal the corrupt file system.

It is basically the file system thinking a file exists when the actual data blocks are gone or zeroed out, fsck can’t “magically” restore those files because the corruption is at the data level, not the directory structure.

Your Mac is reporting the volume as “OK” because APFS considers the container healthy, even if individual files are trashed. There is a small risk of further file-level corruption if the SSD is failing, but the container itself isn’t actively spreading errors.

The safest move is to stick to backups, avoid writing to the affected volume, and if you want a fully reliable system, a clean erase/reinstall is the only way to guarantee a fresh, trustworthy file system.

No need to buy a new Mac unless hardware issues show up.

Provided that you maintain backups (plural) there is no reason for concern. If you remain concerned anyway, erase the Mac and restore its content from one of those backups.

FSCK does not repair unreadable files. It's designed to evaluate file system structures and correct errors in those. Therefore, if the directory structures on your drive are not problematic, then the result of fsck would be "OK" and no repairs would be made.

Still, you may have corrupted files within your directories, but the best way to fix that problem might simply be to replace those files with know good copies from a backup made prior to their corruption.

If the file(s) in question are cache files or system settings, then sometime deleting those files and letting the system or application recreate them is the way to go.

What problem prompted you to run fsck in the first place?

And exactly what files do you believe are unreadable?

Are you backing up your files? You don't need to do this if you don't value your stuff.

Back up your Mac with Time Machine - Apple Support

<< No such file or directory. >>

That is very different from not readable.

You could be using a file reference, such as a file with a $, that is not an acceptable folder-reference to the tool doing the Reading, or that folder could be buried in an unreadable (due to lack of permissions) directory structure.

dollar-sign is most often used to reference temporary files, so it is possible the Parser is pulling it out as a separate token or the shell is treating it differently.

What does Finder show?

Don't mix git repositories with cloud services.

For your third party app / files—if in doubt search the developers website or contact their: Support/Help/FAQ/Known issues/compatibility/updates…

Contact a third-party vendor - Apple Support

Contact a third-party vendor - Apple Support

ref: https://git-scm.com/

ref: https://git-scm.com/community

ref: https://www.atlassian.com/git/tutorials/source-code-management

The current stable release of Tahoe including bug fixes, security updates is macOS 26.0.1

Keep your Mac up to date - Apple Support

Keep your Mac up to date - Apple Support