Hide Forgot
Description of problem: Version-Release number of selected component (if applicable): bash-4.2.47-3.fc20.x86_64 How reproducible: Steps to Reproduce: 1. Run ll 2. Run ls -sh 3. The sizes of core.2328 are 47 M and 6.5M. Actual results: [leo@thinkpad-leo DR]$ ll dr_replay/ -sh total 11M 0 drwxrwxr-x 3 leo leo 121 Aug 6 08:30 build 4.0K -rwxrwxr-x 1 leo leo 159 Aug 4 12:13 build.sh 6.5M -rw------- 1 leo leo 47M Aug 6 09:48 core.2328 3.2M -rw------- 1 leo leo 44M Aug 6 12:11 core.6597 4.0K -rw-rw-r-- 1 leo leo 68 Aug 4 12:19 env.sh 400K -rwxr-xr-x 1 leo leo 397K Aug 4 11:09 memcached 16K -rw-rw-r-- 1 leo leo 15K Aug 4 12:12 out 4.0K -rwxrwxr-x 1 leo leo 117 Aug 6 08:07 run1.sh 4.0K -rwxrwxr-x 1 leo leo 33 Aug 5 16:10 run2.sh 0 drwxrwxr-x 2 leo leo 44 Aug 6 08:35 sym 12K -rwxrwxr-x 1 leo leo 8.5K Aug 5 15:43 test_main 4.0K -rw-rw-r-- 1 leo leo 108 Aug 4 12:12 test_main.c [leo@thinkpad-leo DR]$ ls build_replay.sh commons dr_replay DynamoRIO_replay_build memcached-1.4.20 [leo@thinkpad-leo DR]$ ls -sh dr_replay/ total 11M 0 build 6.5M core.2328 4.0K env.sh 16K out 4.0K run2.sh 12K test_main 4.0K build.sh 3.2M core.6597 400K memcached 4.0K run1.sh 0 sym 4.0K test_main.c Additional info: If I copy dr_replay folder to other places, the problem does not occur again. I am using XFS.
While this is confusing, there is no inconsistency here. Notice the first column is 6.5M in the `ll -sh` case, which corresponds to the `ls -sh` reported disk usage for the sparse core file. Once you copy the file you're probably removing the sparseness (though that may be another issue as cp should maintain the sparseness if possigle).
I see. Thank you.