Details:

$ strace -e trace=file file-roller имя.zip 2>&1 | fgrep .zip   
execve("/usr/bin/file-roller", ["file-roller", "\350\354\377.zip"], [/* 63 vars */]) = 0
lstat64("/home/mama/tech-problems/zip-Russian/\320\270\320\274\321\217.zip", 0xbff35130) = -1 ENOENT (No such file or directory)
$

+1 workaround: use xarchiver-0.5.2-alt1.

So neither archive manager with GUI (file-roller or xarchiver) is working well with Russian filenames: cf. https://bugzilla.altlinux.org/show_bug.cgi?id=22463 -- either the problem is with a Russian name of an included file, or with a Russian name of the archive file. :(

(In reply to comment #3)
> So neither archive manager with GUI (file-roller or xarchiver) is working well
> with Russian filenames: cf. https://bugzilla.altlinux.org/show_bug.cgi?id=22463
> -- either the problem is with a Russian name of an included file, or with a
> Russian name of the archive file. :(

Workaround: /usr/lib/kde4/bin/ark from kde4utils-ark-4.3.3-alt0.M51.1 works fine in this situation.

I'm afraid gtk/gnome folks just can't imagine 8-bit locales...  I've patched file-roller a few years ago (before unzip was patched to cope with charsets), but please clarify: is it feasible for you to follow the masses and migrate to UTF-8 (which I started for new systems but didn't do for existing ones yet myself), *or* should I try and dig it up, update and apply to the package?

[moving to Sisyphus as that's where the bug might be fixed before copying/backporting the package]

BTW I've partially fixed this a while ago for a customer, patches were posted.

*** This bug has been marked as a duplicate of bug 10851 ***