This is weird. (And this "answer" started as a comment ;), became a bit long for it.)
Looking at the strace it looks like there are no hidden characters or the like, else I suspect you would have seen it in e.g. (which should have resulted in -1 ENOENT and not 0 if everything was OK):
stat("akorg", {st_mode=S_IFDIR|0755, st_size=21, ...}) = 0
as you do in:
lstat("akorg\342\234\275", {st_mode=S_IFDIR|0755, st_size=21, ...}) = 0
Came across a mail exchange where one person has the opposite problem. ls list the files, but stat give ENOENT – though that was on FreeBSD.
I do not know much about zfs, but could it be that some sync, snapshot or the like has failed and left a corrupted file table? Did you create/have a directory named akorg that you deleted before you tried the mv?
Do not know if you can get some error descriptions by:
# zpool status -v
One thing to try is check the reverse inode lookup (optionally add yet another d) and check path:
# zdb -dddd <pool-name> <inode>
On a folder named baz:
# zdb -dddd qqq 31
Object lvl iblk dblk dsize lsize %full type
31 1 16K 512 1K 512 100.00 ZFS directory
264 bonus ZFS znode
dnode flags: USED_BYTES USERUSED_ACCOUNTED
dnode maxblkid: 0
path /baz
uid 1000
gid 1000
atime Fri Jun 14 12:39:46 2013
mtime Fri Jun 14 11:55:33 2013
ctime Fri Jun 14 11:55:33 2013
crtime Fri Jun 14 11:55:33 2013
gen 1510
mode 40775
size 2
parent 3
links 2
xattr 0
rdev 0x0000000000000000
microzap: 512 bytes, 0 entries
On a directory named foo holding several subdirectories including one named akorg✽:
Object lvl iblk dblk dsize lsize %full type
16 1 16K 512 1K 512 100.00 ZFS directory
264 bonus ZFS znode
dnode flags: USED_BYTES USERUSED_ACCOUNTED
dnode maxblkid: 0
path /foo
uid 1000
gid 1000
atime Fri Jun 14 13:10:38 2013
mtime Fri Jun 14 12:13:18 2013
ctime Fri Jun 14 12:13:18 2013
crtime Fri Jun 14 11:41:53 2013
gen 1482
mode 40775
size 6
parent 3
links 6
xattr 0
rdev 0x0000000000000000
microzap: 512 bytes, 4 entries
foo1 = 15 (type: Directory)
foo2 = 18 (type: Directory)
foo = 19 (type: Directory)
akorg✽ = 30 (type: Directory)
The settings you have on zfs get all storage/home-ak-annex for various name mod also looks sane (as far as I can tell) as well as the other properties by reading ZFS Properties:
storage/home-ak-annex utf8only off -
storage/home-ak-annex normalization none -
storage/home-ak-annex casesensitivity sensitive -
If you build zfs yourself you can enable debug by ./configure --enable-debug and play with the above including -vvvv, -bbbb etc.
Lastly you could open a new Issue on the git.
With 4 million files, rm /location/of/many/files/*jpg* will probably fail with Argument list too long error.
Use find:
find /location/of/many/files/ -maxdepth 1 -type f -name '*jpg*' -delete
or if -delete is not available:
find /location/of/many/files/ -maxdepth 1 -type f -name '*jpg*' -exec rm {} +
Best Answer
You can ask transmission-remote for a list of the files it knows about. There are two options for asking for files,
--filesand--info-files/-if; which you need probably depends on the version you're running:Unfortunately, it's intended for display, not parsing, and there doesn't seem to be an option to make scripting-friendly output. If you're a programmer, you could grab the source and fix that or alternatively hack together your own implementation in Perl/Python/Ruby/JavaScript/etc. to get the file names. Transmission uses a documented, fairly simple JSON-over-HTTP protocol.
You could also try
--moveto ask Transmission to move everything it knows about to a new directory.