Recovery partition of size 2.71GiB was shown as completely empty. Panicked for a moment before checking that all the files were still there. Used space was correct after the partition was mounted to /mnt. Reproducible: Always Steps to Reproduce: 1. Have a partition that is not mounted and not empty 2. Check the used space in partitionmanager Actual Results: The used space of said partition is shown as zero. Expected Results: The used space should be shown correctly or there should be a text saying it can't be accessed. Thinking it's empty might lead someone to deleting it. It's the standard "Dell XPS 13 (2016) Developer Edition" recovery partition.
Is it true with any file system? Or some particular file system, if so then which one are you using. (In reply to sascha.zenglein from comment #0) > Recovery partition of size 2.71GiB was shown as completely empty. Panicked > for a moment before checking that all the files were still there. Used space > was correct after the partition was mounted to /mnt. > > Reproducible: Always > > Steps to Reproduce: > 1. Have a partition that is not mounted and not empty > 2. Check the used space in partitionmanager > > Actual Results: > The used space of said partition is shown as zero. > > Expected Results: > The used space should be shown correctly or there should be a text saying it > can't be accessed. Thinking it's empty might lead someone to deleting it. > > It's the standard "Dell XPS 13 (2016) Developer Edition" recovery partition.
(In reply to Andrius Štikonas from comment #1) > Is it true with any file system? Or some particular file system, if so then > which one are you using. > > (In reply to sascha.zenglein from comment #0) > > Recovery partition of size 2.71GiB was shown as completely empty. Panicked > > for a moment before checking that all the files were still there. Used space > > was correct after the partition was mounted to /mnt. > > > > Reproducible: Always > > > > Steps to Reproduce: > > 1. Have a partition that is not mounted and not empty > > 2. Check the used space in partitionmanager > > > > Actual Results: > > The used space of said partition is shown as zero. > > > > Expected Results: > > The used space should be shown correctly or there should be a text saying it > > can't be accessed. Thinking it's empty might lead someone to deleting it. > > > > It's the standard "Dell XPS 13 (2016) Developer Edition" recovery partition. Oh yeah, sorry. It happened with a Fat32 file system. Does not seem to happen with other file systems. Did not even consider this. Dumb me.
Strange, it seems to work for me. I've just looked at fat code in KPMcore, so used space is calculated by running fsck.msdos -n -v /dev/sdb2 and looking at cluster size in the output, e.g.: 4096 bytes per cluster as well as the number of used clusters, e.g /dev/sdb2: 2 files, 38401/1339843 clusters Can you check if you see these two lines if you run fsck.msdos manually Maybe something to do with fsck.msdos on your system, e.g. they changed something between versions... My version is fsck.fat 3.0.28 (2015-05-16)
I ran the commands and the size was correctly shown. However, the dirty bit was set. I tried to fix it with fsck.msdos and now the partition manager shows the correct size - even after restart. Should I change the bug report to something like "size not correct with dirty bit set" or is this intended behavior? I can't really explain why the dirty bit is set since the partition is still in its original state.
Well, we probably don't want to automatically run fsck that modifies file system. Maybe it would be nice to show some warning that file system is not clean. But without looking further into this I can't tell how easy is to add that. So I guess change the title and catetory to wishlist...
Done. fsck.msdos shows the correct size even with dirty bit set though. I think there has to be some condition that decides to not show info if the file system is corrupt, because if you just took the info of fsck.msdos then the size would be correct either way.
Yeah, I'll try to look into it. Now that we know this is caused by dirty bit...
(In reply to sascha.zenglein from comment #6) > Done. fsck.msdos shows the correct size even with dirty bit set though. I > think there has to be some condition that decides to not show info if the > file system is corrupt, because if you just took the info of fsck.msdos then > the size would be correct either way. fsck.msdos returns exit status 1 when dirty bit is set, that's why code to read usage was not run.
Git commit ea99bcc76fd92d85182445c5a80eac2590e7c53a by Andrius Štikonas. Committed on 02/08/2016 at 20:41. Pushed by stikonas into branch 'master'. Correctly report used space of FAT partitions whose dirty bit is set. M +1 -1 src/core/operationrunner.cpp M +1 -1 src/fs/fat16.cpp http://commits.kde.org/kpmcore/ea99bcc76fd92d85182445c5a80eac2590e7c53a