-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use off_t for free space calculation (free space on filesystems >2TB not properly displayed) #2338
Comments
This is needed to show correct free space information for todays large filesystems on 32bit systems. |
Thanks!
Do we really have use signed off_t instead of unsigned uintmax_t?
Generally, we have 3 different types for FS description: my_statfs (mountlist.h:26), fs_usage (fsusage.h:36) and again fs_usage (mountlist.c:139). I think all that structures should be merged into single one. |
Replying to andrew_b:
I've taken off_t, because when showing these values in src/info.c, we pass them through size_trunc_len(), which takes an off_t. In the end any integer that is 64bit on 32bit systems is fine, but we should be consistent. |
since i run into this bug daily, i was wondering if there has been any progress on the issue?
in the current version(4.7.5.3) i see this, when browsing my 6TB RAID 5:
mc: 793G/1493G (53%) |
|
Branch: 2338_free_space_calculation (parent: master). |
|
because i'm unable to build the git-tree(some stuff missing on osx apparently, as autogen.sh fails), i applied the patch from git to 4.7.5.3. patch worked, however now i'm seeing:
mc: 2024G/1493G (135%) on my 5.5tb disc. |
Replying to mak:
Would you show exact that values in bytes? |
|
Free space: 1982G/1493G (132%)
Capacity : 6 TB (6,000,699,228,160 Bytes)
5860057840 1634336016 4225721824 28%
…hope this helps. |
Thanks! Would you attach your config.h here? |
Hmm, the _FILE_OFFSET_BITS macro is not defined in your config.h. It should be
which is provided by AC_SYS_LARGEFILE macro. If you run configure without --disable-largefile option, _FILE_OFFSET_BITS should be defined.
BTW, what system do you use? |
hmm. looks like another perk of running os x(10.6.8 and 10.7.1).
getting this while building with --enable-largefile
checking for special C compiler options needed for large files... no |
I also hit the same problem on a x86_64 FreeBSD system, mc 4.7.5.4.
df output:
Midnight shows: 1778G/16Z
Applied the above git patch and recompiled.
Now Midnight shows: 5874G/7442G |
Please test 2338_free_space_calculation branch. If you cannot get this branch from our repo, you can get the following snapshot: http://repo.or.cz/w/midnight-commander.git/snapshot/947be78a1b4070a35461b23ffc7c8bad32740afb.tar.gz |
sadly i'm not able to build the snapshot. |
Replying to mak:
I've created tarball for you. |
thx for the tarball.
when building i get this error:
make[5]: * No rule to make target changesetfs', needed by all-am'. Stop.
i also attached the config.h file. |
|
Ah, sorry. This bug was fixed in master after created branch. I think, build with --disable-vfs-extfs option as a quick workaround can help you. |
build worked, but after starting it crashed instantly:
mc(61865,0x7fff70040cc0) malloc: * error for object 0x10201d048: pointer being freed was not allocated |
Replying to mak:
Would you get a backtrace using following instructions? |
del |
There is no debug info here. If you use gcc, run
|
sorry 'bout that:
bt
bt full
|
Thanks! Please test this tarball. |
thx again.
build worked and i'm seeing the correct values in the bottom bar.
mc:
os: |
Initial changeset: [b9f03c63d80445c4b74dd0c52c2a9a07ee547f36] |
|
|
Merged to master.
|
|
Important
This issue was migrated from Trac:
swegener
(sven.wegener@….net)mc.trac@….org
The free space calculation currently uses ints, which are just 32bit on plain x86 systems and result in free space on filesystems >2TB not being properly displayed. See attached patch.
Note
Original attachments:
swegener
(sven.wegener@….net) onSep 1, 2010 at 9:33 UTC
mak
(mc.trac@….org) onSep 14, 2011 at 15:02 UTC
mak
(mc.trac@….org) onSep 28, 2011 at 17:20 UTC
The text was updated successfully, but these errors were encountered: