ls: cannot access 'filename': No such file or directory (but file exists)

Question

HFS+ formatted drive connected to an Ubuntu box via a SATA/USB cradle.

No issues are reported for the partition by fsck.hfsplus.

Attempting to run "ls" (or anything else) on the affected files results in "no such file or directory". Running "ls -lh" on the container folder throws the same complaint but still shows the file in the list, but with the following format:

-rw-r--r-- 1 501 dialout   53M Mar  4 15:26 normal_file
-????????? ? ?   ?           ?            ? uncooperative_file

I'm not concerned about the 501:dialout ownership of the other files (the drive is from a different machine).

There are a few files that are being affected by this. They only seem to be files with Unicode and/or Emoji in the name.

I've tried:

• "ls" with the "-b" and "-q" options, but neither has revealed anything
• "ls -lh > ~/tmp.txt" and editing in "vi" in an attempt to detect extraneous bytes in the name
• "chown root:root filename"
• "chmod 644 filename"

The file shows up in the output of "ls" and tab-completion fills it in as well. But any sort of actual interaction fails.

Anyone able to offer some guidance? Ultimately, I want to be able to rsync/scp these files to another box (which unfortunately doesn't play nicely with the drive cradle) and I figured being able to ls/mv would be a good starting point.

EDIT: Using bash. Tab-completion fills in the full filename, though with some '???' in the place of certain characters (unsure of the original chars at this point). Locale on the source box:

LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_CTYPE="en_CA.UTF-8"
LC_NUMERIC="en_CA.UTF-8"
LC_TIME="en_CA.UTF-8"
LC_COLLATE="en_CA.UTF-8"
LC_MONETARY="en_CA.UTF-8"
LC_MESSAGES="en_CA.UTF-8"
LC_PAPER="en_CA.UTF-8"
LC_NAME="en_CA.UTF-8"
LC_ADDRESS="en_CA.UTF-8"
LC_TELEPHONE="en_CA.UTF-8"
LC_MEASUREMENT="en_CA.UTF-8"
LC_IDENTIFICATION="en_CA.UTF-8"
LC_ALL=

Answer 1

macOS can encode filenames in UTF16 on HFSplus and this means you are out of luck, as Linux does not have UTF16 locales. Basically, your locale is UTF8 and it does not show specific characters, there is a high chance these are UTF16 characters.

Answer 2

Since you are able to tab-complete the name in bash, try renaming the file, excluding any non-ASCII characters in the new filename. e.g.:

mv uncoop???erative_file cooperative_file

I would suggest doing this on the source machine, not on the mounted folder in MacOS, if possible, just to avoid any potential pitfalls due to character translations between the machines. Once you have a filename that MacOS and your ls can recognize, you should also be able to rsync it.

I actually conducted this exact experiment, and was able to execute mv uncoop???erative_file cooperative_file on the Raspian box, and then interact with cooperative_file as it was shared over NFS to my Mac, including rsync'ing that file from an iterm2 window on the Mac.