Nasty MC bugs still not fixed

[Pavel Machek]

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