Other No such file or directory on NTFS

I have mounted an NTFS partition using ntfs-3g() and a number files seem inaccessible to FreeBSD. When trying to access them I get:-
No such file or directory

The files show up under a directory listing so how can I tell what's wrong? I did a chkdsk /f on Windows and was able to access the files which FreeBSD couldn't.
 
Do you have file names that are in interesting character sets?

We used to have these kinds of problems when first experimenting with non-trivial 8-bit characters sets in file names. For example, say your file system has four files in a directory, and they are called "a (7-bit lower case character)", "a with accent expressed using a single unicode character", "a with the same accent but expressed as overprinting accent plus a", and "a with accent expressed using iso8859-1". Those four directory entries are all distinct, and all have different names. If you set your user process environment to "export LANG=C" and use a terminal emulator that only displays 7-bit ASCII, and do "ls", you will see four files, and their names are all simply "a". When you now say "cat a", which file will be printed? Heck if I know (and I was one of the implementors in that file system!). Even better: You have only three files, namely the three files from above whose names are all "a with accent" using various encodings and character sets. You do "ls", and you see three files whose names are all just "a". You do "ls a*", and it will truthfully tell you that there is no file whose name begins with a (because all three files have names that are a character different from a).

I have no idea how one can solve these problems when mounting a foreign file system (like NTFS). My suggestion would be to attach the offending disk to a Windows machine, and get on with life.
 
I'm actually trying to de-dupe 1000's of mp3 files some of which have Polish titles (which include funny Polish characters). I have them on the network hosted on FreeNAS and many are also on WD (NTFS) external drive which I mounted (ntfs-3g) on my FreeBSD system. After finding I couldn't access them on the external disk, I moved them to my network hoping I would be able to de-dupe them. Unfortunately I get the same error msg as before, so it is not NTFS related. This has me completely baffled.

I guess I need to run a program against a directory list to see if the files actually exist...
 
Last edited:
From time to time I see this issue, and in order not to forget what to do about it, I wrote a short article on my BLog, see Batch converting filenames from de- to pre-composed UTF-8.

I was puzzled by how converters/convmv would work if the system couldn't access the files... but on re-reading the description, I see that it only converts filenames in the directory entry but doesn't touch the files themselves. I would never have stumbled across this utility, because the cause seems so obscure. But thanks for pointing out the problem.

Unfortunately it hasn't worked for me. I just copied the command from your blog
Code:
# convmv -r -f utf8 -t utf8 --nfc --notest ./

this file was not validly encoded in UTF-8: "./R�ze Europy - Kontestatorzy.mp3"
To prevent damage to your files, we won't continue.
First fix this or correct options!

I guess the options from your example do not apply in this case. Help! How do I tell what encoding they are in to begin with?
 
The file names are not validly UTF-8 encoded, which means nothing else than that the name's char set is not UTF-8 but anything else.

My best educated guess from the nature of the file is, that it was created on an old (pre-UTF-8) Windows system, perhaps XP, with a Polish localisation, meaning the natural character set at that time was Windows Latin 2 = CP1250.

In case my assumption sounds reasonable, then try the following convmv command:
convmv -r -f cp1250 -t utf8 --nfc ./

In case this command reports success, repeat it with the --notest flag.

In case you get just another filename with non-printable chars inside, you need to dig deep into your memories about the nature/origin of said files, in order to reveal some ideas on possible constituting character sets of the respective file names.

For an exhaustive list of character sets which convmv(1) understands, use:
convmv --list

Then you would try each of these as parameter of the -f (from) flag, and finally once you found out the correct one, execute convmv once again with --notest.
 
It seems I have other issues with being unable to access files...

I have run converters/convmv and that has sorted out many of the problems, but I still have some problems accessing some files. I can copy them and view them but other attempts to access them result in

cannot open `--------------.mp3' (No such file or directory)

What is strange is that audio/mpg123 displays this error but multimedia/vlc has no problem playing the file.

Could it be due to the length of the filename including path? That seems unlikely since I copied one of these files to my home directory and got the same result. Could it be an illegal filename? One of the files I can't process is called
16. Mega Dance - Kocha'c Latem.mp3
 
It is quite possible that mpg123 has bugs in its string parsing. The unpaired single quote in the file name makes me suspect that. But the problem could also easily be that the file name itself isn't being passed to mpg123 correctly, due to incorrect use of the shell.

Personally, I would begin by renaming the file to a name that only contains normal printable 7-bit ASCII characters, no spaces, no shell meta characters,. I don't even like hyphens in file names.

In standard Unix, there should be no concept such as "illegal file name". Other than the limited length, and the fact that a string can not contain a null character, a file name should be able to contain any byte from 1 to 255. If all programs were written correctly, this should even work. But as I said above: anything outside of a [a-zA-Z0-9_] is asking for trouble.
 
I think you're right. Is there another cmd line audio player which is worth trying?
Don't know. At some point, I was using mpg321 (no, that's no dyslexic, the number is spelled backwards). I don't remember what the difference between mpg123 and mpg321 is, might be worth exploring.

And how do I get misc/mc to automatically launch it when I hit enter on a selected mp3 file?
Never used mc, don't know.
 
I'm actually trying to de-dupe 1000's of mp3 files some of which have Polish titles (which include funny Polish characters). I have them on the network hosted on FreeNAS and many are also on WD (NTFS) external drive which I mounted (ntfs-3g) on my FreeBSD system. After finding I couldn't access them on the external disk, I moved them to my network hoping I would be able to de-dupe them. Unfortunately I get the same error msg as before, so it is not NTFS related. This has me completely baffled.

I guess I need to run a program against a directory list to see if the files actually exist...

Problem 1: try to use this kind of parameter on fstab (or ntfs-3g)
Code:
locale=value
        This option can be useful when wanting a language specific
        locale environment.
and fstab....

ping...locale=valueThis option can be useful when wanting a language specificlocale environment.
Code:
/dev/ada0p7     /var/local/trans_ntfs/data     ntfs-3g rw,locale=pt_BR.utf-8,mountprog=/usr/local/bin/ntfs-3g    0       0

Problem 2: I was used to fdupe on linux... (perl script I suppose). Well...! I've found something more eficcient:

Code:
NAME
       dupd - find duplicate files

SYNOPSIS
       dupd COMMAND [OPTIONS]

DESCRIPTION
       dupd scans all the files in the given path(s) to find files with
       duplicate content.

       The sets of duplicate files are not (by default) displayed during a
       scan.  Instead, the duplicate info is saved into a database which can
       be queried with subsequent commands without having to scan all files
       again.

It create a sqlite database very handy for long jobs. It worked fine with my .mp3 with lots of "funny characters" in its names. ;-)
 
Back
Top