strange problem with Midnight Commander

SUSE Linux Enterprise Server SLES Configure-Administer
1

Hello

since SLES11 SP2 I have a problem with the Midnight Commander during copy a subdirectory to a other name (in the same superordinate directory).

I can reproduce this when I try to copy a directory (F5) in the same directory, but with other name.
For example

  • First make a test directory in the home directory:

  • Then I copy the complete directory /etc/apparmor to ~/test
    (Now I have ~/test/apparmor with subdirectores and files)

  • Now I use the mc, go on ~/test/apparmor and use F5 to make a copy

  • I the destination (to:) field, I type apparmor345

No I get two new directories
~/test/appaomor345
~/test/apparr345

A cp -R ~/test/apparmor ~/test/apparmor345 works!

I tried to do this with putty, ssh from cygwin, and on the console (VMWare)!

If I use SLES11SP1 all works without Problems!

Can other out there confirm this strange behaviour?

Thanks Meike

2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Another bug recently came up that is not the same, but seems to be
similar in some odd way. Care to give Bug# 752980 a review, perhaps by
testing a newer version to see if the problem persists?

https://bugzilla.novell.com/show_bug.cgi?id=752980

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPcbmVAAoJEF+XTK08PnB5VfgP/jTK96ruRfZUSClQW8Br1h1+
w9fwI5xpiQZh2PKMg0bWmorN1RhB27Y/i5wj7Xd16rMJuTkNBNsrYPV6m7TFDleX
mZENNDLLIMD4iNXdvCtsJL3/sivz082DaQ3+2uSLxeOpjUN4piLKSwrGQ7JfuwmO
ds5JD/i+G/bqrs55JTzbI4beHwd+1F9hiucBmHJNlZPUzpDK83qWqUbFCfvzHKZj
ZVCC7Oi2uxq37jbtvJ5Hg5BBdkHTlNV9Rf/LKn8HkfztH+lugSDY431i/6Gqlc/Q
uE5WC/2BYwR9Y1XcUEbC9mSmabuxme9LlyljTf/CaCs6GVike8rMhQR3gUzomJvi
Tm2OhFBPPCqJAdunOpcPSh8EwoCsln2tzmR/clF6/znKkMWS2Y9x16g/FTUMOq+N
MUFdzmgRjveD2H1L+Me1Pp/aJLgCaH3P0THj5YZf/AnuFU+eRO+NoLkK2EDzQQ/5
qyxPBgpy3Yhw4Jox/PO9MJLkt2OA/wC9jJvpNLPN5XycLPPiSMpDMhzZO9ars/P6
DChz8H8p7cifIhyTH0rO2e5+V7rDDATSkIbvM5u9yLUeGjIAgnIzyCdotTGt7maL
BF1VpySqvgrptJaSpjQ/j4taMHdLXB38crMOVrw5nt1tkL45BaLdABdROWKRRpGs
j9ICe/XBBVCMy+ToLZYA
=jO+o
-----END PGP SIGNATURE-----

3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bah… you won’t be able to see the contents of the bug, so here is the
description:

SLES 11 SP2 SLED 11 SP2 midnight commander (mc) 4.6.2-pre1 [url]http://forums.suse.com/showthread.php?t=793[/url]

A customer has reported, and I plus another individual have confirmed,
that mc incorrectly renames files with three-character names. For
example if I try to rename a file (with any name of any length) to ‘ert’
the file name completes (if another file does not exist in the way) to
‘trt’; the last character of the three-character name is put in place of
the first character. If I then try to rename ‘trt’ to ‘ert’ again mc
returns an error which reads, “’/path/to/trt’ and ‘./ert’ are the same
file” (notice the two different names used, the one I put in and the one
it will actually use as the target of the rename). If I now try to
rename some OTHER file to ‘ert’ (and ‘trt’ already exists) then mc
throws a different error warning me that I am about to overwrite ‘trt’.
Renaming files to names of other lengths yields no similar problems.

I cannot duplicate this on my OpenSUSE 12.1 system with mc 4.7.5.3.

Reproducible: Always

Expected Results: Rename files according to the user’s input, not some
broken version of that input.

Actual Results: For three-character files the last character is
duplicated to the first character which is useful only for creating
palindromes in file names.

It was later noticed that this problem happens with seven-character file
names too.

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPcbojAAoJEF+XTK08PnB5QHoQAKyA9PclysHcDI/O6+beP31U
UoarH4ZRUANIM+NqeZNwccePSg/DRcyS+NVbkOJZCFHQYbmKBfZzPZXmAAWTQhsx
8CLnlzXu6xx1/cX4+O2laqHu7+INZnit8Gnwyelp22WHuH7EuU20xJekh983LiF5
trYixjdofY1BWviMqrnO5zOdxOSF/ZdEq+5ooFU6dyp0DefsxNwtWv+fFz/K0u2V
+6DGhmXfbswUU7tbwAT0bcu0Rfhxv//DNh3Tti9tT/U6S7VGpHJrSxl9c4B2N9/V
wihaZww+l92w+EB5XwUyvXsPiWuuHG/wtkqHuT+2ntfumlM5EsUksHKWKw800SVw
ETXoUNrtZAZt25yUc2pZhBXPcbfU5lIJTraGVilUqurQVxh4tZis0vpfBl3upnEX
yGPKu/5/Tkx2Y4G/7pPxLoY6GdhneT1II/kvOQ1DpHoiqx5nP1Lr8EwT2X8ECLk9
APths1xi+Fs23lFcM4VG12sdQ1DWAV/BMmmHTL3QdNhfgVI6ZLtSth8ww0olVYfz
Od5OKMxl2kwl4KhjVJv979OtdEaT8SJheKFeMN/ctxbjkLXQCMH+FHh9gYjNmzdx
z8OIUbAdYIkdJuVu891B6ZObumQVS/RPBuYH/kbuIeTuLgoodyIpG4Iw0JlRwTe/
+py8oFHnxTpNyzaeS7DV
=17gl
-----END PGP SIGNATURE-----

4

[QUOTE=ab;3633]-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Another bug recently came up that is not the same, but seems to be
similar in some odd way. Care to give Bug# 752980 a review, perhaps by
testing a newer version to see if the problem persists?

https://bugzilla.novell.com/show_bug.cgi?id=752980
[/QUOTE]

Can’t read the bug “You are not authorized to access bug #752980.” :frowning:

Thanks Meike