Re: [Fwd: [Pkg-mc-devel] midnight commander bug]

Hello Yuri,

I think the best way to test mc for this bug is to replicate the same setup I have:

I have a machine (Athlon xp3000 with 2 GB memory) with 4 disks: 3 scsi disks on an adaptec 29160N and 1 sata 160GB on a sil 3114 adapter. The scsi first disk contains debian amd 64 bit v. 5.0.6, ext2, with Grub v.0.96 boot loader. The second scsi disk slackware 64 bit v. 13.1, also ext2 because I have to be able to read and write from those disks with freebsd on the fourth sata disk. The third scsi disk contained a fresh windows 7 - 64 bit install. The fourth sata disk contains freebsd 64-bit v. 8.1. I wanted to make a backup of the windows 7 installation with slackware on the second scsi disk. While copying the "windows" map from the windows 7 install to the second "slackware" - scsi disk , mc simply stopped after copying about 45000 files of the 65000 files contained in the "windows" folder. So , mc gave no error message and it did not crash, it simply stopped. Then I tried copying this "windows" map on the first scsi disk with debian 5.0.6 and I had exactly the same problem: mc copied only about 45000 files of the 65000 files contained in the windows map. What I suggest is that you test mc by copying the "windows" map of a 64 bit windows 7 install, not some other files because it could be that mc has problems with certain file names. The reason I suppose this is because I already had the same problem in the past by copying mp3 files which had some weard characters and spaces in their file names. Unix or linux filesnames never contain spaces while windows filenames do. I guess that could be the problem. As already said earlier, copying the windows map to the ext2 formatted disks with the cp -r command gave no problems, all files were flawlessly copied. I hope you can find out what this bug is all about because I guess my only option for a decent filemanager is mc as I don't want to use the bulky, buggy and insecure windows managers like KDE, XFCE or GNOME. I only use blackbox because even fluxbox version 2.x gave me a headache on freebsd because for some reason it was terribly "slow", slower than gnome: I spent half a day tweaking the freebsd kernel-settings for speed without any result while after removing fluxbox and installing blackbox instead, all desktop operations went lightening fast in freebsd 8.1.

best regards,
Dirk Scheerlinck

On 15/12/2010 15:39, Yury V. Zaytsev wrote:
On Wed, 2010-12-15 at 15:37 +0100, Yury V. Zaytsev wrote:
On Wed, 2010-12-15 at 08:15 +0100, Yury V. Zaytsev wrote:

I can check on latest master if I can reproduce this issue.
I have to admit, that on latest master I don't have this issue!
But I do have the same problem as described while deleting files on
latest master.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]