Nasty MC bugs still not fixed
Pavel Machek
pavel at ucw.cz
Tue Sep 11 19:17:44 UTC 2001
Hi!
> > > > > > 3) while copying large amount of files (>4GB), the size progress
> > > > > > bar everytimes == 0%
> > >
> > > I could not reproduce it on RedHat Linux 7.1 (i386) with the CVS version
> > > of MC.
> > >
> > > Note that --enable-largefile is default in CVS, but not in 4.5.55. You
> > > shouldn't expect MC compiled without large (64-bit) file support to work
> > > correctly with large files.
> >
> > Try disabling largefile and _then_ copying eight 1Gig files. That
> > is what he is talking about. [Not that I tried to reproduce this bug
> > -- I do not have 4GB of diskspace
>
> I see. Actually, MC uses "double" in some places where the file sizes are
> added together, e.g. in the status bar, when files are selected.
>
> However, I think that using "off_t" would be more appropriate than
> "double":
>
> 1) Large file support will be default soon. The only reason why it wasn't
n> default in 4.5.55 is because VFS uses field names such as "stat", and
> Solaris uses "#define stat stat64" somewhere in the headers if the large
> file support is enabled. I'm going to fix this problem before 4.6.
>
> 2) 64-bit integer arithmetics is faster than floating point on 32-bit
> machines (please correct me if I'm wrong).
*) We probably don't care about speed at such places.
*) double is probably faster [its coprocessor, that's fast because
games need it fast].
> Finally, let me repeat - you don't need 4G of free space to create a 4G
> long file. Use "seek" option in "dd":
>
> dd if=/dev/null of=bigfile bs=1M seek=4096
Okay, so I'm lazy ;-).
Pavel
--
I'm pavel at ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss at linmodems.org
More information about the mc
mailing list