Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a problem accessing file in linux Mint. The reason is obviously the unrecognized character(s) in the filename but none of the techniques I know helped me to rename it.

So, here are details: filename is something like:

êà_0_4àíòè_0_7-_0_7_0_8ó_0_1à333333.mp3

or at least this is how my filemanager and terminal display it.

I cannot open the file with any program I use under linux Mint. media players, etc...

It cannot be renamed, moved or copied via file manager. All of these operations produce error messages similar to these:

(for rename):

Error renaming file: No such file or directory.

(for copy/move):

No such file or directory.

I have also tried rename command from terminal using wildcards. The command correctly picks the file name but cannot copy, here is the output:

cp *0_7-_* 1.mp3
cp: cannot open `êà_0_4àíòè_0_7-_0_7_0_8ó_0_1à333333.mp3' for reading: No such file or directory

I have also tried using mv command,

mv *0_7-_* 1.mp3
mv: cannot move `êà_0_4àíòè_0_7-_0_7_0_8ó_0_1à333333.mp3' to `1.mp3': No such file or directory

If I try to sudo rename then I get:

Unrecognized character \xC3; marked by <-- HERE after <-- HERE near column 1 at (eval 1) line 1.

File itself is a valid MP3 file. It can be opened by Windows Media Player under XP.

The problem is: I have a big music library (over 100Gb) and there are few dosens of similar files with invalid characters in names. I don't want to loose these files and I would like to figure out how to handle such situations in future (in linux preferably, because I don't own a pc that runs windows).

Any help will be appreciated

UPDATE: as requested by terdon, here is the outout of locale:

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

UPDATE 2 I have just checked with my friends XP machine. And I can confirm following findings. The original file can be played by Windows Media Player but it cannot be played by Winamp. However after accessing and renaming it through filemanager it is played by both players.

So I conclude that this is a problem with unrecognized character. I am still interested in solution under linux though,

share|improve this question
1  
Could you show us the output of locale please? I'm guessing you are not using UTF8. –  terdon Dec 28 '13 at 15:45
    
please see above. I have updated the question adding the output of locale –  smc Dec 28 '13 at 18:51
1  
Hmm, that is weird. I tried simply creating a file with the same name and it worked fine. What filesystem are these on? –  terdon Dec 28 '13 at 18:59
    
its NTFS. not sure if creating file with this name proves anything. I have just tried it myself and I can do it too, I can also modify, open, rename and delete the file after I have created it. I assume that what I have pasted in my original question is not the actual filename but the way my systems sees/interprets it. –  smc Dec 28 '13 at 19:05
    
@smc Is the filesystem clean? chkdsk x: in an elevated command line does an read-only check, so nothing will be altered. (Sorry, your on linux... this should be then ntfsfix -n /dev/sdX, -n for dry run). –  mpy Dec 28 '13 at 19:08

2 Answers 2

Four things:

Try the complement of the solution - move everything else, then remove everything.

mkdir ../everything_else
mv problematic/folder/path/* everything_else
sudo rm -rf problematic/folder/path

Make sure there is no ACL on the file, and remove any that may be causing problems:

$ /bin/ls -le problematic/folder/path
total 16
-rw-r--r--+ 1 whmcclos  staff  1918 Dec 18 09:00 README
0: user:_spotlight inherited allow read,execute,readattr,readextattr,readsecurity
$ chmod -a "..."

Try a Perl script to smooth out OS/FS naming dependencies?

For instance, something along the lines of this code fragment - keep the filename in anonymous $_:

$ mkdir fred; cd fred; touch a b c d e f
$ cat > try.pl
#!/usr/bin/perl
opendir(D,".") or die "cannot open .\n";
@files=readdir(D);
closedir(D);
foreach (@files) {
  next if /\.{1,2}/;                      # Skip directory entries
  print; print "? "; $r = <>; chop($r);   # Provide some level of control
  if($r eq "y" or $r eq "Y") {unlink;}    # Should report if cannot unlink unnamed file - tbd.
}
^D
$ /usr/bin/perl try.pl
a? 
b? 
c? y
d? 
e? 
f? 
$ ls
a       b       d       e       f       try.pl

[Updated to reflect authors original intent - copy the beast to a well behaved file(name):]

To see if Perl can copy the misbehaved file to a well behaved file, I'd use the below Perl script - still along the lines of the above - let Perl "anonymously" access the filename.

(Also, the ACL should really be checked; the ACL can even prevent root from normally accessing the file as root, from what I recall dealing with.]

Here's the Perl script:

$ cat try3.pl
#!/usr/bin/perl
# A code fragment to ask to copy a displayed file to $TO; chg $TO on next line:
$TO="my_new_behaved_filename";       # This is the name that will be copied to
opendir(D,".") or die "cannot open .\n";
@files=readdir(D);
closedir(D);
foreach $f (@files) {
  next if $f =~ /\.{1,2}/;           # Skip directory entries, "." & ".."
  print "$f? "; $r = <>; chop($r);   # Provide some level of control; "y" or "Y"
  if($r eq "y" or $r eq "Y") {       #   to copy the displayed filename to $TO
    print "copying it to $TO...\n";
    # Now, see if we can copy the darn thing to $TO:
    open(FROM,$f) or die "sorry - couldn't open it...";
    open(TO,">$TO");
    while(read FROM, $buf, 16384) {
      print TO $buf;
    }
    close(TO);
    close(FROM);
  }
}

Which you'd use as such, assuming try3.pl is the aforementioned Perl script:

$ ./try3.pl 
a? 
b? 
d? y
copying it to my_new_behaved_filename...
e? 
f? 

Access the file through a symbolic or hard link and see what milage you get.

I'd use vi's filename [tab] expansion to try to "identify" to the shell what file you want to link to.

I moved my ~/{.vim,.viminfo,.vimrc} aside so as to restrict things, like wildmenu input. You may want to do the same.

Now, kick off the following command line sequence in the bogus file's containing folder:

$ vi

In vi, type precisely this sequence of characters

!!ln -s [tab]

So that key sequence was, in words: exclamation point, exclamation point, el, en, blank, dash, es, blank, tab. As soon as you hit the [tab] key, the first file of the current working directory should display after the blank character (following the "s") on vi's status line. Hit the [tab] key numerous times to cycle through to the bogus filename. When the bogus filename appears, press the space bar to add a space, and then type a new file/link-name.

The result on vi's status line should look something like this

!!ln -s bogus_filename new_sym_link_name

Hit the return key to see if the link command (spawned from vi to replace the current null line in vi's empty buffer, which we don't care about, here; we want the side effect of executing a shell command with tab expansion) will create the link, new_sym_link_name.

Exit vi with :q![return], and see if you can access your file through the symbolic link.

(You could also try a hard link by leaving off the -s in the above ln command.

Because I just noticed that you could change the filename through Windows, I'm thinking that somehow, a carriage-return linefeed sequence got into the filename, and that is confusing the various approaches.

share|improve this answer
    
This comment is on your perl script. I tried it but it did not work. Thanks for help though. I was hoping that something like this should solve my problem.. What happened was, I created the script in the directory with affected files. I ran the script. I tried it first by removing the files that I have created for testing (a,b,c,d,e and f). worked fine. then I tried removing other random files in the directory. worked as well. But when trying to remove files affected by the problem nothing happened. Files were not removed and no error was reported. I will try other two methods that you suggest –  smc Dec 28 '13 at 21:03
    
moving then removing everything did not work either. moving was successful, removing reported error (no such file or directory). I think it is important to note here that I am not trying to remove files. As noted in my original question I am trying to access files and I cannot because the invalid filename. So I am looking for a way to rename the file to be able to access it. (thanks for your help). I only mentioned that i am unable to remove files in order to give as much details as possible, still my actual task is to rename. –  smc Dec 28 '13 at 21:09
    
I have installed radiance package in order to run total as you advised. I ran the command : total 01\ _0_1cie_0_4ka\ 1.mp3 and the result was 01 _0_1cie_0_4ka 1.mp3: cannot open –  smc Dec 28 '13 at 21:12
    
Bill, thanks a lot. I see you know much more then I do on the subject. And about ACL... I guess this is not the case. all affected files state rwxrwxrwx. Once again I will repeat, I am pretty sure that this is the case of having an invalid character in the name. I guess you have already read my update on original question: renaming file from windows pc makes it accessible on any system. I still cannot find a way to rename it from linux. I will try the second version of the script tomorrow first thing. –  smc Dec 28 '13 at 23:16
    
Couldn't resist and tried it right now. script works for all other files (which means it is correct and compiles perfectly). But when I try to use it to rename affected files it dies with ""sorry - couldn't open it..."" –  smc Dec 28 '13 at 23:24

Use ls -li to get the inode number of the file in question. Make a note of of the inode number (first field). I'll use 123456 as an example.

Then, use find to remove the file:

find -inum 123456 -exec rm {} \;

or to rename it:

find -inum 123456 -exec mv {} some_better_filename \;
share|improve this answer
    
thanks for your reply. here is what happens: ls -li will list the files (and display inodes). In my case the inode number was 28623. then running find -inum 28623 -exec mv {} some_better_filename.mp3 \; results in mv: cannot move "./01 _0_1cie_0_4ka 1.mp3" to "some_better_filename.mp3": No such file or directory as you can see, using inode number to identify file - works, but accessing it doesn't. –  smc Dec 28 '13 at 20:23
    
I think the culprit is that find passes filename to mv and the filename is problematic. Don't know how to fix it, though. –  gronostaj Dec 28 '13 at 21:10
    
I completely agree with gronostaj. It is the filename that is problematic. Also see update 2 at the bottom of original question. Still no solution though. I appreciate any suggestions –  smc Dec 28 '13 at 21:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.