ls: cannot access 'filename': No such file or directory (but file exists)
Clash Royale CLAN TAG#URR8PPP
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=
mount ls hfs+
asked Jun 22 '17 at 5:32
David YoungDavid Young
41114
add a comment |
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=
mount ls hfs+
asked Jun 22 '17 at 5:32
David YoungDavid Young
41114
Please add what is displayed after file name completion by your shell, and which shell you are using.
– daniel Azuelos
Jun 22 '17 at 5:44
Try different locales. Start with C, then with any UTF-8, say en_US.UTF-8
– paul
Jun 22 '17 at 6:42
Please issue "locale" in a terminal and provide the output in your question, I believe you might be using the C locale. Since emoji are UTF-8, you need to set your locale to a UTF8 locale.
– thecarpy
Jun 22 '17 at 6:47
add a comment |
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=
mount ls hfs+
asked Jun 22 '17 at 5:32
David YoungDavid Young
41114
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=
mount ls hfs+
mount ls hfs+
asked Jun 22 '17 at 5:32
David YoungDavid Young
41114
asked Jun 22 '17 at 5:32
David YoungDavid Young
41114
edited Jun 22 '17 at 6:52
David Young
asked Jun 22 '17 at 5:32
David YoungDavid Young
41114
asked Jun 22 '17 at 5:32
David YoungDavid Young
41114
asked Jun 22 '17 at 5:32
David YoungDavid Young
41114
41114
Please add what is displayed after file name completion by your shell, and which shell you are using.
– daniel Azuelos
Jun 22 '17 at 5:44
Try different locales. Start with C, then with any UTF-8, say en_US.UTF-8
– paul
Jun 22 '17 at 6:42
Please issue "locale" in a terminal and provide the output in your question, I believe you might be using the C locale. Since emoji are UTF-8, you need to set your locale to a UTF8 locale.
– thecarpy
Jun 22 '17 at 6:47
add a comment |
Please add what is displayed after file name completion by your shell, and which shell you are using.
– daniel Azuelos
Jun 22 '17 at 5:44
Try different locales. Start with C, then with any UTF-8, say en_US.UTF-8
– paul
Jun 22 '17 at 6:42
Please issue "locale" in a terminal and provide the output in your question, I believe you might be using the C locale. Since emoji are UTF-8, you need to set your locale to a UTF8 locale.
– thecarpy
Jun 22 '17 at 6:47
Please add what is displayed after file name completion by your shell, and which shell you are using.
– daniel Azuelos
Jun 22 '17 at 5:44
Please add what is displayed after file name completion by your shell, and which shell you are using.
– daniel Azuelos
Jun 22 '17 at 5:44
Try different locales. Start with C, then with any UTF-8, say en_US.UTF-8
– paul
Jun 22 '17 at 6:42
Try different locales. Start with C, then with any UTF-8, say en_US.UTF-8
– paul
Jun 22 '17 at 6:42
Please issue "locale" in a terminal and provide the output in your question, I believe you might be using the C locale. Since emoji are UTF-8, you need to set your locale to a UTF8 locale.
– thecarpy
Jun 22 '17 at 6:47
Please issue "locale" in a terminal and provide the output in your question, I believe you might be using the C locale. Since emoji are UTF-8, you need to set your locale to a UTF8 locale.
– thecarpy
Jun 22 '17 at 6:47
add a comment |
1 Answer
1
active
oldest
votes
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.
I am sorry for you.
answered Jun 26 '17 at 12:00
thecarpythecarpy
2,285825
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f372633%2fls-cannot-access-filename-no-such-file-or-directory-but-file-exists%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
I am sorry for you.
answered Jun 26 '17 at 12:00
thecarpythecarpy
2,285825
add a comment |
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.
I am sorry for you.
answered Jun 26 '17 at 12:00
thecarpythecarpy
2,285825
add a comment |
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.
I am sorry for you.
answered Jun 26 '17 at 12:00
thecarpythecarpy
2,285825
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.
I am sorry for you.
answered Jun 26 '17 at 12:00
thecarpythecarpy
2,285825
answered Jun 26 '17 at 12:00
thecarpythecarpy
2,285825
answered Jun 26 '17 at 12:00
thecarpythecarpy
2,285825
answered Jun 26 '17 at 12:00
thecarpythecarpy
2,285825
2,285825
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f372633%2fls-cannot-access-filename-no-such-file-or-directory-but-file-exists%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Please add what is displayed after file name completion by your shell, and which shell you are using.
– daniel Azuelos
Jun 22 '17 at 5:44
Try different locales. Start with C, then with any UTF-8, say en_US.UTF-8
– paul
Jun 22 '17 at 6:42
Please issue "locale" in a terminal and provide the output in your question, I believe you might be using the C locale. Since emoji are UTF-8, you need to set your locale to a UTF8 locale.
– thecarpy
Jun 22 '17 at 6:47