Hi Again Paval,
yeah i did mention the larger file ..thats why i found it little confusing that it opened one but not the other, shift-f3 still gave me that same error, but its good to know about that option. Because i do data recovery and forensic stuff, i tend to deal with big files alot so i'll do a little more testing in the morning and let you know how i go. thanks again Adam <paste> I have one file thats 3.7Gb: -rw-rw-rw- 1 root root 3721035776 Feb 7 15:46 tapedata_1.dat When i go to view this file, mc bombs and gives me the following error: GLib-ERROR **: could not allocate -573931520 bytes At first i though this was an error with Glib and lfs, however i have another file even larger: -rw-rw-rw- 1 root root 4789108736 Feb 11 11:42 tapedata.001 I can view this file with no problems in both ascii and hex and search throught the binary with no problems. </paste> On Wed, 20 Feb 2002, Pavel Roskin wrote: > Hi, Adam! > > > I did use the large file option when I compiled mc, i could see the 4gb > > file with no problems. > > Your original message didn't mention 4gb files. It mentioned a file > slightly below 4gb that mc could not view and a file slightly above 4gb > that mc could view (but we don't know if mc just shows the file's size > minus 4gb). > > > I suspects its a problem with the contents of the file (its a dgdump file > > that was ment to be cpio). > > It should be easy to determine. Shift-F3 calls the viewer without > checking the contents of the file. On the other hand, you could try to > open another file 3.7gb long. You can use a sparse file to avoid filling > your hard drive with zeroes: > > dd if=/dev/null of=bigfile bs=1M seek=3700 > > Actually, I tried to view the resulting file with the CVS version of MC > and got the same error, so your assumption about the file contents is > probably wrong, but you can check anyway - finding another bug won't hurt. > _______________________________________________ Mc mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc
