If a file has 0 allocated blocks but has a logical size which is greater than 0, the file will not be detected as "sparse"; instead, their logical size will be used as actual size.

To create such a file, run eg. dd if=/dev/zero of=test.bin bs=1M seek=1000 count=0; this creates a sparse file which uses 0 blocks of space but has a logical size of 1000 MB. Qdirstat displays a misleading size of 1000 MB for this file.
If you run dd if=/dev/zero of=test.bin bs=1M seek=1000 count=1 instead, the file uses 2048 blocks and has a logical size of 1001 MB. For this file, qdirstat correctly shows a size of "1001 MB (allocated: 1.0 MB)".

This was observed on an ext4 file system, with latest qdirstat (f33cba3).
The issue does not occur with k4dirstat 2.7.8-4-ge61717f.

During make, encountered a linker error related to 64-bit arch:

clang++ -headerpad_max_install_names -stdlib=libc++ -mmacosx-version-min=10.7 -arch x86_64 -o .app/Contents/MacOS/ -F/usr/local/Cellar/qt/4.8.6/lib -L/usr/local/Cellar/qt/4.8.6/lib -framework QtGui -L/opt/X11/lib -L/usr/local/Cellar/qt/4.8.6/lib -F/usr/local/Cellar/qt/4.8.6/lib -framework QtCore
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [.app/Contents/MacOS] Error 1
make: *** [sub-scripts-make_default-ordered] Error 2

this is minor:

when clicking around in the treemap the listview on top sometimes does not scroll to correct position to make the selected item visible. i'm not sure what exactly it depends on. i can mostly get back to the right item by selecting a different rectangle and then selecting the intended rectangle again. selecting something on the very bottom right and then coming back towards top-left improves the chances of the intended selection getting visible in the list view.

version: 1.3
system: Ubuntu zesty
package: 1.3-1~zesty (amd64)

$ ls -lR
.:
razem 112
-rw-rw-r-- 1 slodki slodki 51200 maj 31 19:51 file3_ą
-rw-rw-r-- 1 slodki slodki 51200 maj 31 19:51 file4
drwxrwxr-x 2 slodki slodki  4096 maj 31 19:51 krowa
drwxrwxr-x 2 slodki slodki  4096 maj 31 19:51 żółw

./krowa:
razem 52
-rw-rw-r-- 1 slodki slodki 51200 maj 31 19:51 file1

./żółw:
razem 52
-rw-rw-r-- 1 slodki slodki 51200 maj 31 19:51 file2
$ locale
LANG=pl_PL.UTF-8
LANGUAGE=
LC_CTYPE="pl_PL.UTF-8"
LC_NUMERIC="pl_PL.UTF-8"
LC_TIME="pl_PL.UTF-8"
LC_COLLATE="pl_PL.UTF-8"
LC_MONETARY="pl_PL.UTF-8"
LC_MESSAGES="pl_PL.UTF-8"
LC_PAPER="pl_PL.UTF-8"
LC_NAME="pl_PL.UTF-8"
LC_ADDRESS="pl_PL.UTF-8"
LC_TELEPHONE="pl_PL.UTF-8"
LC_MEASUREMENT="pl_PL.UTF-8"
LC_IDENTIFICATION="pl_PL.UTF-8"
LC_ALL=

All files and directories with polish (or Cyrillic) characters are skipped/ignored in QDirStat:

Works without problems in all other KDE/QT/CLI apps:

sshing into my headless server with X window forwarding not set up, I get a crash and core dump because there's no display to attach to. This is stupid and PEBKAC, but maybe this case can be cleaned up to not crash.

➜  qdirstat git:(master) ./src/qdirstat
Logging to /tmp/qdirstat-1000.log
[1]    26606 abort (core dumped)  ./src/qdirstat
➜  qdirstat git:(master) cat /tmp/qdirstat-1000.log
2016-12-06 17:53:40.631 [26606] <Info>    Logger.cpp:75 Logger():  -- Log Start --
2016-12-06 17:53:40.638 [26606] <ERROR>   :0 ():  QXcbConnection: Could not connect to display

This is very useful when cleaning up a folder and wanting to refresh that file/folder only instead of the whole tree, as this can be very slow on HDDs.

WinDirStat has this feature and I'd love to see it in QDirStat too!

When opening a cache file generated with the qdirstat-cache-writer script, qdirstat starts displaying the directory tree and then terminates with a NullPointerException. Backtrace:

#0  0x00007ffff54ad107 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007ffff54ae4e8 in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x00007ffff5d98b3d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#3  0x00007ffff5d96bb6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#4  0x00007ffff5d96c01 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#5  0x00007ffff5d96e19 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#6  0x0000000000418e8a in _throw_helper<NullPointerException> (exception=..., logger=0x0, srcFile=..., srcLine=486, 
    srcFunction=...) at Exception.h:288
No locals.
#7  0x0000000000446682 in QDirStat::DirTreeModel::index (this=0x7edc90, row=23, column=0, parentIndex=...)
    at DirTreeModel.cpp:486
        parent = 0xd31270
        __FUNCTION__ = "index"
        child = 0x0
#8  0x00007ffff77394c1 in QTreeViewPrivate::layout(int, bool, bool) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#9  0x00007ffff7739db6 in QTreeView::expandToDepth(int) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
No symbol table info available.
#10 0x0000000000455ad3 in MainWindow::expandTreeToLevel (this=0x7fffffffe100, level=1) at MainWindow.cpp:516
No locals.
#11 0x0000000000454d2d in MainWindow::idleDisplay (this=0x7fffffffe100) at MainWindow.cpp:394
        sortCol = 32767
#12 0x0000000000454e25 in MainWindow::readingFinished (this=0x7fffffffe100) at MainWindow.cpp:412
        __FUNCTION__ = "readingFinished"
(More stack frames follow...)

The cache file is from a separate machine, so the actual directory structure is not accessible for qdirstat. The same cache file works fine when opened in k4dirstat after changing the header to [kdirstat 4.0 cache file]. Unfortunately, I can't share this particular cache file and haven't yet managed to reproduce this error on another file.
It might also be interesting that according to the logfile, the last child is <Files>:

2016-01-17 15:09:56.268 [1264] <ERROR>   DirTreeModel.cpp:180 findChild():  Child #23 is out of range: 0..22 children for /hom
e/freak/
2016-01-17 15:09:56.268 [1264] <Debug>   DebugHelpers.cpp:55 dumpChildrenList():  Children of /home/freak/
...
2016-01-17 15:09:56.269 [1264] <Debug>   DebugHelpers.cpp:59 dumpChildrenList():      #22: /home/freak//<Files>
2016-01-17 15:09:56.269 [1264] <WARNING> DirTreeModel.cpp:486 index():  THROW Exception: Null pointer

If I can do something more to help investigate this, please let me know.

Actually there are 2 problems with the log file... I will start with the security one...

Problem 1: Being written in /tmp , the log file is readable by anyone since in this folder when creating files their permissions usually are set to 644... A small change in src/Logger.cpp constructor is needed... Adding some QFile::setPermissions would help great to limit the reading at least to user and group, so no user sensitive info from the log leaks...

Problem 2: The log file location is hardcoded to /tmp... This better be coded using either QStandardPaths::TempLocation or some of the env variables like TMPDIR on Linux, or TEMP on Windows....

How I imagine this to look/be positioned - http://i.imgur.com/e77oD7R.png

I think this would be a great default option with the ability to resize all 3 windows and be able to pop them out so they act like they currently do for people who'd like to use them as such

With the way it currently is it feels cluttery on a lower than FHD res screen, and I'd like this even on my FHD screen(currently using lower res TV).

• Being tracked here too #52

Also when the directory listing pops out it ignores the last position it was at, it'd be great if it opened at the last position.

• Fixed! Thanks!

And as a small side note - it is great to open the file stats menu by F3, would be even better if it worked as toggle and F3 also closed it if it is open.

• Implemented, thanks!

And Thank You so much for implementing the file stats feature and making it even better by adding file listings, it makes it so much more useable for me and the listing of files by directories makes it even better than WinDirStat, especially the synergy between all 3 windows is very cool!.

To reproduce:

1. Scan a large folder
2. While scanning, click the arrow icon to show the subtree of a folder
3. The shown subtree sometimes actually belongs to a different directory

Example: Here the contents of /etc are shown as the contents of /usr

In my opinion Qdirstat should support displaying IEC binary prefixes/units for file sizes: KiB/MiB/GiB/TiB (powers of 1024) instead of (or in addition to) KB/MB/GB/TB (power of 1000). What do you think?

1. select a file in treemap
2. right-click on the file in treemap
3. delete (no way to undelete)
4. yes
5. now parent directory of the file is selected.
6. in treemap select a different file in a different directory.
7. right-click on the file in treemap
8. delete (no way to undelete)

the parent directory of the previously deleted file is in the list of files to be deleted

this made me delete a directory i actually didn't intend to delete, so i consider this to be a grave bug.

When I run qdirstat on a local X server, it finishes almost immediately, but when I use ssh -X it is very slow. If I attach strace, it's doing a lot of polling on file descriptors 5 (a socket, presumably the X server) and 7 (an eventfd). [Incidentally, it's also statting /etc/localtime dozens of times, but this doesn't seem to be where it's blocking].

Is there a way to limit the amount that it tries to update the window? It seems to be counting down "read jobs" one at a time, and taking about a quarter of a second for each update.

It would be nice to see the file name and size if you hover above a file in the colored view.

I expect QDirStat to open files with the default application (using xdg-open) when I double click them in the tree view.

One of the files is 7.7G which seems to be enough for the overflow to happen

qdirstat /   

-> 7.8 GB total

Menu "File" -> "Write to Cache File" -> save as file "root-internal.cache.gz"

qdirstat -c root-internal.cache.gz   

-> 457 MB total

qdirstat-cache-writer / root-script.cache.gz

qdirstat -c root-script.cache.gz

-> 7.8 GB total

I cant figure out how to download someone tell me pls

The Treemap doesn't use all space avaible for each folder but leaves grey areas in each zone :

At maximum zoom there's no problem the area is filled with tiles :

Wide side of sorting arrow should depict bigger values and vice versa.
Currently (V1.0 2016-08-12):

Hello,
Nice to found this useful tool.

I have a problem. If a sub folder contains non-English characters, it cannot scanned. Also, the chars shown weird.

For example in Turkish,
"İnanç Esasları" shown as "Ä°nanç Esasları"

Thank you.

Enclosing the field code in double quotes means that if QDirStat is run without parameters, it assumes the current directory is to be opened. Expected behaviour would surely be to prompt for the directory to open, if there is no directory parameter specified?

Also, perhaps it would be helpful to add mount point mime-type to MimeType key value.

Suggested changes:
Exec=qdirstat %u
MimeType=inode/directory;inode/mount-point;

Create a cleanup action that "Works For... Files" with "Refresh Policy: Refresh This Item". Select more than one file and run the action. The action is performed, and qdirstat crashes afterwards.

Does not happen with directories, single files, or "Refresh This Item's Parent".

Valgrind output:

==28354== Invalid read of size 8
==28354== at 0x44761D: QDirStat::DirTree::refresh(QDirStat::FileInfoSet const&) (DirTree.cpp:144)
==28354== by 0x499E89: QDirStat::Refresher::refresh() (Refresher.cpp:35)
==28354== by 0x4B16E6: QDirStat::Refresher::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_Refresher.cpp:69)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x4B13C0: OutputWindow::lastProcessFinished(int) (moc_OutputWindow.cpp:209)
==28354== by 0x4931E6: OutputWindow::processFinished(int, QProcess::ExitStatus) (OutputWindow.cpp:232)
==28354== by 0x4B1128: OutputWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_OutputWindow.cpp:149)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5DDCA6E: QProcess::finished(int, QProcess::ExitStatus) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5DE52AB: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5DE5448: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== Address 0x1b75e5f0 is 0 bytes inside a block of size 104 free'd
==28354== at 0x4C2F24B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28354== by 0x45D90D: QDirStat::FileInfo::~FileInfo() (FileInfo.cpp:158)
==28354== by 0x43B8D3: QDirStat::DirInfo::clear() (DirInfo.cpp:119)
==28354== by 0x4478DB: QDirStat::DirTree::refresh(QDirStat::DirInfo*) (DirTree.cpp:183)
==28354== by 0x447689: QDirStat::DirTree::refresh(QDirStat::FileInfoSet const&) (DirTree.cpp:147)
==28354== by 0x499E89: QDirStat::Refresher::refresh() (Refresher.cpp:35)
==28354== by 0x4B16E6: QDirStat::Refresher::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_Refresher.cpp:69)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x4B13C0: OutputWindow::lastProcessFinished(int) (moc_OutputWindow.cpp:209)
==28354== by 0x4931E6: OutputWindow::processFinished(int, QProcess::ExitStatus) (OutputWindow.cpp:232)
==28354== by 0x4B1128: OutputWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_OutputWindow.cpp:149)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== Block was alloc'd at
==28354== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28354== by 0x4430AD: QDirStat::LocalDirReadJob::startReading() (DirReadJob.cpp:272)
==28354== by 0x441D11: QDirStat::DirReadJob::read() (DirReadJob.cpp:58)
==28354== by 0x444CAE: QDirStat::DirReadJobQueue::timeSlicedRead() (DirReadJob.cpp:545)
==28354== by 0x4AE41B: QDirStat::DirReadJobQueue::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_DirReadJob.cpp:253)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5EEA5C7: QTimer::timerEvent(QTimerEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5EDEBB2: QObject::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x51AF05B: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1)
==28354== by 0x51B4515: QApplication::notify(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1)
==28354== by 0x5EAF38A: QCoreApplication::notifyInternal(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5F045EC: QTimerInfoList::activateTimers() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354==
==28354== Invalid read of size 8
==28354== at 0x423EC6: QDirStat::FileInfo::parent() const (FileInfo.h:342)
==28354== by 0x447661: QDirStat::DirTree::refresh(QDirStat::FileInfoSet const&) (DirTree.cpp:146)
==28354== by 0x499E89: QDirStat::Refresher::refresh() (Refresher.cpp:35)
==28354== by 0x4B16E6: QDirStat::Refresher::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_Refresher.cpp:69)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x4B13C0: OutputWindow::lastProcessFinished(int) (moc_OutputWindow.cpp:209)
==28354== by 0x4931E6: OutputWindow::processFinished(int, QProcess::ExitStatus) (OutputWindow.cpp:232)
==28354== by 0x4B1128: OutputWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_OutputWindow.cpp:149)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5DDCA6E: QProcess::finished(int, QProcess::ExitStatus) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5DE52AB: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5DE5448: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== Address 0x1b75e640 is 80 bytes inside a block of size 104 free'd
==28354== at 0x4C2F24B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28354== by 0x45D90D: QDirStat::FileInfo::~FileInfo() (FileInfo.cpp:158)
==28354== by 0x43B8D3: QDirStat::DirInfo::clear() (DirInfo.cpp:119)
==28354== by 0x4478DB: QDirStat::DirTree::refresh(QDirStat::DirInfo*) (DirTree.cpp:183)
==28354== by 0x447689: QDirStat::DirTree::refresh(QDirStat::FileInfoSet const&) (DirTree.cpp:147)
==28354== by 0x499E89: QDirStat::Refresher::refresh() (Refresher.cpp:35)
==28354== by 0x4B16E6: QDirStat::Refresher::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_Refresher.cpp:69)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x4B13C0: OutputWindow::lastProcessFinished(int) (moc_OutputWindow.cpp:209)
==28354== by 0x4931E6: OutputWindow::processFinished(int, QProcess::ExitStatus) (OutputWindow.cpp:232)
==28354== by 0x4B1128: OutputWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_OutputWindow.cpp:149)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== Block was alloc'd at
==28354== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28354== by 0x4430AD: QDirStat::LocalDirReadJob::startReading() (DirReadJob.cpp:272)
==28354== by 0x441D11: QDirStat::DirReadJob::read() (DirReadJob.cpp:58)
==28354== by 0x444CAE: QDirStat::DirReadJobQueue::timeSlicedRead() (DirReadJob.cpp:545)
==28354== by 0x4AE41B: QDirStat::DirReadJobQueue::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_DirReadJob.cpp:253)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5EEA5C7: QTimer::timerEvent(QTimerEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5EDEBB2: QObject::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x51AF05B: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1)
==28354== by 0x51B4515: QApplication::notify(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1)
==28354== by 0x5EAF38A: QCoreApplication::notifyInternal(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5F045EC: QTimerInfoList::activateTimers() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354==
==28354== Invalid read of size 8
==28354== at 0x423EC6: QDirStat::FileInfo::parent() const (FileInfo.h:342)
==28354== by 0x447677: QDirStat::DirTree::refresh(QDirStat::FileInfoSet const&) (DirTree.cpp:147)
==28354== by 0x499E89: QDirStat::Refresher::refresh() (Refresher.cpp:35)
==28354== by 0x4B16E6: QDirStat::Refresher::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_Refresher.cpp:69)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x4B13C0: OutputWindow::lastProcessFinished(int) (moc_OutputWindow.cpp:209)
==28354== by 0x4931E6: OutputWindow::processFinished(int, QProcess::ExitStatus) (OutputWindow.cpp:232)
==28354== by 0x4B1128: OutputWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_OutputWindow.cpp:149)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5DDCA6E: QProcess::finished(int, QProcess::ExitStatus) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5DE52AB: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5DE5448: ??? (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== Address 0x1b75e640 is 80 bytes inside a block of size 104 free'd
==28354== at 0x4C2F24B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28354== by 0x45D90D: QDirStat::FileInfo::~FileInfo() (FileInfo.cpp:158)
==28354== by 0x43B8D3: QDirStat::DirInfo::clear() (DirInfo.cpp:119)
==28354== by 0x4478DB: QDirStat::DirTree::refresh(QDirStat::DirInfo*) (DirTree.cpp:183)
==28354== by 0x447689: QDirStat::DirTree::refresh(QDirStat::FileInfoSet const&) (DirTree.cpp:147)
==28354== by 0x499E89: QDirStat::Refresher::refresh() (Refresher.cpp:35)
==28354== by 0x4B16E6: QDirStat::Refresher::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_Refresher.cpp:69)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x4B13C0: OutputWindow::lastProcessFinished(int) (moc_OutputWindow.cpp:209)
==28354== by 0x4931E6: OutputWindow::processFinished(int, QProcess::ExitStatus) (OutputWindow.cpp:232)
==28354== by 0x4B1128: OutputWindow::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_OutputWindow.cpp:149)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== Block was alloc'd at
==28354== at 0x4C2E0EF: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28354== by 0x4430AD: QDirStat::LocalDirReadJob::startReading() (DirReadJob.cpp:272)
==28354== by 0x441D11: QDirStat::DirReadJob::read() (DirReadJob.cpp:58)
==28354== by 0x444CAE: QDirStat::DirReadJobQueue::timeSlicedRead() (DirReadJob.cpp:545)
==28354== by 0x4AE41B: QDirStat::DirReadJobQueue::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) (moc_DirReadJob.cpp:253)
==28354== by 0x5EDDD29: QMetaObject::activate(QObject*, int, int, void**) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5EEA5C7: QTimer::timerEvent(QTimerEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5EDEBB2: QObject::event(QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x51AF05B: QApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1)
==28354== by 0x51B4515: QApplication::notify(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1)
==28354== by 0x5EAF38A: QCoreApplication::notifyInternal(QObject*, QEvent*) (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354== by 0x5F045EC: QTimerInfoList::activateTimers() (in /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.5.1)
==28354==

If qdirstat-cache-writer encounters a directory which lacks the "executable" flag, it will create a broken cache file that cannot be completely read by qdirstat (only entries up to the broken line will be displayed in qdirstat).

The broken lines lack a size value, ie. there are two tab characters without a number inbetween.

Here's an example file: .qdirstat.cache.gz. It should list subdir1, subdir2 and subdir3, but since subdir2 is unreadable, subdir3 is not even listed anymore in qdirstat. Also, qdirstat has a total size of 2 MB for the entire tree, while du shows a size of 3 MB (and actually there are 4 MB of data, but the size of subdir2 cannot be detected obviously).

This is output of ls -lRa for that test directory:

br2wsl61:/tmp/test2(83)> ls -laR
.:
total 1620
drwxrwxr-x   5 og   og      4096 Feb  2 12:31 .
drwxrwxrwt. 74 root root  585728 Feb  2 12:31 ..
-rw-rw-r--   1 og   og       255 Feb  2 12:31 .qdirstat.cache.gz
drwxrwxr-x   2 og   og      4096 Feb  2 12:30 subdir1
drw-rw-r--   2 og   og      4096 Feb  2 12:28 subdir2
drwxrwxr-x   2 og   og      4096 Feb  2 12:30 subdir3
-rw-rw-r--   1 og   og   1048576 Feb  2 12:27 testfile0.bin

./subdir1:
total 1032
drwxrwxr-x 2 og og    4096 Feb  2 12:30 .
drwxrwxr-x 5 og og    4096 Feb  2 12:31 ..
-rw-rw-r-- 1 og og 1048576 Feb  2 12:30 testfile1.bin

./subdir2:
ls: cannot access ./subdir2/.: Permission denied
ls: cannot access ./subdir2/..: Permission denied
ls: cannot access ./subdir2/testfile2.bin: Permission denied
total 0
d????????? ? ? ? ?            ? .
d????????? ? ? ? ?            ? ..
-????????? ? ? ? ?            ? testfile2.bin

./subdir3:
total 1032
drwxrwxr-x 2 og og    4096 Feb  2 12:30 .
drwxrwxr-x 5 og og    4096 Feb  2 12:31 ..
-rw-rw-r-- 1 og og 1048576 Feb  2 12:30 testfile3.bin

When I ran qdirstat-cache-writer on the test directory, these Perl warnings were printed:

Use of uninitialized value $_[0] in bitwise and (&) at /usr/lib64/perl5/Fcntl.pm line 221.
Use of uninitialized value $_[0] in bitwise and (&) at /usr/lib64/perl5/Fcntl.pm line 223.
Use of uninitialized value $_[0] in bitwise and (&) at /usr/lib64/perl5/Fcntl.pm line 225.
Use of uninitialized value $_[0] in bitwise and (&) at /usr/lib64/perl5/Fcntl.pm line 226.
Use of uninitialized value $_[0] in bitwise and (&) at /usr/lib64/perl5/Fcntl.pm line 227.
Use of uninitialized value $_[0] in bitwise and (&) at /usr/lib64/perl5/Fcntl.pm line 224.
Use of uninitialized value $size in concatenation (.) or string at censored/qdirstat/scripts/qdirstat-cache-writer line 375.
Use of uninitialized value $mtime in printf at censored/qdirstat/scripts/qdirstat-cache-writer line 376.
Use of uninitialized value $blocks in numeric gt (>) at censored/qdirstat/scripts/qdirstat-cache-writer line 378.
Use of uninitialized value $links in numeric gt (>) at censored/qdirstat/scripts/qdirstat-cache-writer line 379.

This happens with the latest qdirstat version (f33cba3), and it also happened with kdirstat-cache-writer.pl and k4dirstat 2.7.8-4-ge61717f.

https://github.com/ZeltaDred/qZedStat

Mail to [email protected] on 2017-02-28:

Douglas,

In August 2016, you forked QDirStat to your own GitHub account to use it as a base for a new project you call qZedStat.

After doing some minor changes like disabling things related to QDirStat's cleanup actions, you saw fit to change my copyright notices - you replaced them with YOUR name and YOUR e-mail address.

That happened less than two hours (!) after doing some minor changes. The most urgent thing to you was to claim credit for all that code.

What makes you think you own any copyright of my code?

What major accomplishments do you see in the small changes you made that would warrant anything like that?

By being most generous and putting QDirStat under the GPL V2, I granted everybody (including you) the right to view, copy and modify that code to tailor it to your specific needs. But that does NOT mean that you own the code - merely that you are granted some rights that closed-source software denies you.

Frankly, I feel insulted by this behaviour. Your contribution to the overall software is miniscule, yet the first thing you do is to make great claims about it. And even more insulting (and completely illegal!) is to remove my copyright notice from it all.

Now, since I believe that you are a student at Dixie U and you still have a lot to learn, I will not let the great big hammer come down on you. Not immediately, that is.

What I expect from you:

• Immediate confirmation that you received this notice.

• You bring my copyright back in all the places in the sources where you removed it (including the toplevel README.md). Something like "parts (c) Douglas Osborn" is okay, but it must be clear that most of this is NOT your work.

• A formal apology, both via e-mail and in the toplevel README.md of your project.

If you do that, I will call this issue settled, and that will be it. Otherwise, I will have to take legal action. And it would be a good idea not to test my patience too much.

Kind regards

Stefan Hundhammer
QDirStat Author

Krelingstr. 4 * 90408 Nürnberg * Germany

Idea

The new File Type Statistics window presents files by type: Category (Images, Videos, Documents, ...) in the top level, individual suffixes (filename extensions) in the next level.

It would be useful to be able to locate files with a chosen suffix from there:

• Click on one of the suffixes in the File Type Statistics window; say, *.bak

• Open another (non-modal) window for the search results; probably one entry per directory that contains any files with that suffix.

• When clicking on one of those search results, open that directory branch in the main window (similar to clicking on a treemap tile) while closing all other branches

• Select (highlight) all matching files in that directory (they will automatically be highlighted in the treemap,too)

• The user can now start cleanup actions for those files in the main window.

Limitations / Unsolved Problems

That will work well with a handful of files; It is still unclear how to do this efficiently with things like my photo collection: It's 29,000+ JPG files scattered over 850+ directories. That's a bit much to navigate in. Would I want only my /work/photos directory to appear there? That's a bit limiting.

This is subject for further investigation and discussion.

Opening a directory in a terminal doesn't work for me. There is a message "Cleanup action finished with 1 errors" in the status bar and the log shows this:

2016-01-12 00:31:52.508 [9571] <Debug>   OutputWindow.cpp:40 OutputWindow():  Creating
2016-01-12 00:31:52.508 [9571] <Debug>   Cleanup.cpp:224 chooseShell():  No custom shell configured - using /bin/bash
2016-01-12 00:31:52.509 [9571] <Debug>   OutputWindow.cpp:432 startNextProcess():  Starting x-terminal-emulator --workdir '/home/cs/devel/cool-old-term.orig/app'
2016-01-12 00:31:52.518 [9571] <Debug>   OutputWindow.cpp:197 processFinished():  Process finished normally.
2016-01-12 00:31:52.519 [9571] <Debug>   OutputWindow.cpp:229 processFinished():  Emitting lastProcessFinished() err: 1
2016-01-12 00:31:52.519 [9571] <Debug>   MainWindow.cpp:546 cleanupFinished():  Error count: 1
2016-01-12 00:31:52.519 [9571] <Debug>   OutputWindow.cpp:306 closeIfDone():  No more processes to watch. Auto-closing.
2016-01-12 00:31:52.519 [9571] <Debug>   OutputWindow.cpp:56 ~OutputWindow():  Destructor

I have a file name:
Swedish House Mafia - Don't You Worry Child ft. John Martin.mp4

I have configured a custom cleanup action, named "Open file in default application". The command for this is:
xdg-open %p

When I click this cleanup action from the context menu on the file, I get a new window with the cleanup output:

cd /data/Google Drive/Media/Divers
xdg-open '/data/Google Drive/Media/Divers/Swedish House Mafia - Don't You Worry Child ft. John Martin.mp4'
/bin/bash: -c: line 0: unexpected EOF while looking for matching `''
/bin/bash: -c: line 1: syntax error: unexpected end of file
Process finished.

This window does not show if the cleanup action runs succesfully. The cleanup action works with files that do not contain single quotes in their filename.

I'm using MATE and this is detected by QDirStat, which falls back to the default terminal emulator xterm.

QMainWindow offers the option to create "dock widgets". Maybe that might be a better solution to the window arrangement problems that arise when using the "File Type Statistics" and "Locate Files" windows?

Maybe that might even be an option for a more flexible arrangement of the main window's tree view vs. the treemap? (side by side vs. currently above and below)

This is not a bug, but a collecting point for discussions about the new File Size Statistics.

Please read the documentation first; I spent a lot of time writing it:

https://github.com/shundhammer/qdirstat/tree/master/doc/stats

Please stay on topic. If you have any other bug report, problem, question or whatever about QDirStat, please open a separate issue so it can be properly tracked.

The official PPA hasn't been updated in 5 months but there have been many new updates since then. Can it get some TLC?

Thanks 👍

EDIT: Nevermind, I just noticed the updates weren't version updates. Still at 1.0 stable. Github doesn't let me delete this.

Program fails to read/load complete cache file..

Environment is Ubuntu 16.04 VM ( virtualbox ) with QT 5.7 ( opensource )
Cache file attached..
qdirstat.cache.gz

File generated by pointing at root (/) mount point while running as non-root user.
Treemap builds and displays, Cache file save seems to write "correct" information.

When attempting to read the cache file, the first (/) directory and the 2 file links are the only things processed / displayed..

Log file is full of the "cannot find parent" messages referenced in the other cache file issue reported

qdirstat-1000.log.tar.gz

WinDirStat has this extension table that lets you see files by their extension.

I'd love to see this feature in QDirStat, as I think it'd be helpful to many people. Personally right now I'd like to see how much data I have in image files, but I cannot use QDirStat to find out.

It would be nice to see the file name and size in the status bar if you hover above a file in the colored view, just like WinDirStat does. #28 was the wrong feature request in fact :)

I ran qmake and then make on OS X, and it seemed to be going fine until it got to Logger.cpp. Here's the output:

clang++ -c -pipe -stdlib=libc++ -mmacosx-version-min=10.7 -g -arch x86_64 -Wall -W -DQ_DECL_OVERRIDE="" -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/Cellar/qt/4.8.6/mkspecs/unsupported/macx-clang-libc++ -I. -I/usr/local/Cellar/qt/4.8.6/lib/QtCore.framework/Versions/4/Headers -I/usr/local/Cellar/qt/4.8.6/lib/QtCore.framework/Versions/4/Headers -I/usr/local/Cellar/qt/4.8.6/lib/QtGui.framework/Versions/4/Headers -I/usr/local/Cellar/qt/4.8.6/lib/QtGui.framework/Versions/4/Headers -I/usr/local/Cellar/qt/4.8.6/include -I.moc -I. -F/usr/local/Cellar/qt/4.8.6/lib -o .obj/Logger.o Logger.cpp
Logger.cpp:260:2: error: use of undeclared identifier 'abort'
abort();
^
1 error generated.
make[1]: *** [.obj/Logger.o] Error 1
make: *** [sub-src-make_default-ordered] Error 2

You can find it in https://build.opensuse.org/package/show/home:dmacvicar/qdirstat

Some notes:

• Because lack of tarballs and tags, I used a OBS _service file to generate the tarball and update the version in the spec. So the package sources will be re-fetched from git every time the package is rebuilt.
• You can automate that github commits trigger a _service rebuild of the sources (tarball and spec version update). It is described here.
• The version format is 0.8+git.1452544836.ea0d400 where the first number is a timestamp and then the git hash. The 0.8 is for now hardcoded in_service` and taken from an internal constant.
• Ideally 0.8 should be replaced with @PARENT_TAG@ in _service, then OBS would look for the parent tag (eg. 0.9) in git of the branch we are building (by default, master) and then automatically generate 0.9+git.$s.$rev.
• As a first step I would recommend just start tagging releases with plain version numbers (eg. no v), and keep building from master. Later you can switch _service to build from stable branches if needed.
• If you dislike the server side magic to generate the tarball and update the spec, there is an alternative method where you can update the tarball to the latest git revision manually in your checkout:
  • Add an attribute mode="disabled" to the service elements in _service.
  • Run osc service disabledrun to update the tarball and .spec file version
  • You will need in this case, to checkin the generated tarball, as it will not longer be autogenerated.
• Feel free to osc copypac this package to somewhere else.

I have configured a custom cleanup action, named "Open file in default application". The command for this is:
xdg-open %p

If I start a scan and during this scan, I execute the custom cleanup action on a file, qdirstat crashes and exits with an segmentation fault. I am able to reproduce this over and over again.

I am curious about how qdirstat handles hard links (if at all). The lack of support for hard links in filelight, for example (https://bugs.kde.org/show_bug.cgi?id=144948), is highly annoying...

Hi. I would like to ask/propose, whether would it be possible to use QStorageInfo to get the underlying device of a path, and thus know when you crossed a file system boundary. QStorageInfo was new in 5.4, so that would kill Qt4 support, unfortunately, but I don't know if that's really a goal of the project.

That's one of the things mentioned in the README (maybe the only one?) that requires non cross-platform code. I would like to know your opinion, since I'm collecting some notes on possible limitations/shortcomings of the Qt API for file systems. Maybe adding QFileInfo::device() (instead of having to construct the QStorageInfo from the path) would be also more convenient.

The light effect on the chart looks really bad, so it would be great to turn it off optionally.
Also an option to adding outlines to boxes would be good.

The Icons that are used look pretty out of place when a different icon theme is used.

QIcon has some nice features that allow using theme icons with backup icons should they not be available.

I haven't looked too much into the source code, but it could also be possible to let Qt determine the mime type of files to use mime icons from the desktop theme.

I have already made some progress and replaced some of the simpler Icons that are used in the UI.

Some progress, icons are from the arc icon theme:

I got the following warning when compiling QDirStat:

FileInfo.cpp:310:27: warning: comparison of constant ‘0’ with boolean expression is always false [-Wbool-compare]
       url.contains( "/" ) < 0 )    // No (more) "/" in this URL
       ~~~~~~~~~~~~~~~~~~~~^~~

I'm wondering if this could lead to some problems.

Hi,

Nice tool.

I've encountered a compilation error on Fedora 25 for QDirStat v1.2 with qt-devel-4.8.7-18.fc23.x86_64

File Logger.cpp, Line 287 should b aware of Qt version

#if (QT_VERSION < QT_VERSION_CHECK( 5, 0, 0 ))
if ( !strstr(msg, "Could not connect to display" ) )
#else
if ( msg.contains( "Could not connect to display" ) )
#endif

And then it works fine,

KR, Olivier

k4dirstat is ported to Qt5 / KF5 and no longer use any Qt3 nor Qt4 backward compatibility stuff. So the README is about an old version of k4dirstat.

Hi;

many thanks for QDirStat :-) !

as shown in attached screenshot, using special characters, as "À" for example, is not accepted :-/ .

Thanks again!

--
Luc

qdirstat's treemap doesn't provide much information unless you hover on entries.

Perhaps we could have a treemap similar to Space Sniffer which has File / Folder name & size on the tiles themselves.

Another feature of those tiles is that you can browse the structure by double-clicking on them etc.

As a workaround for #27, add a command line switch like --slow-updates to QDirStat indicating that it should slow down display updates from the normal 333 millisec to something like 2 or 3 sec.

The slow update interval should be customizable in the config file with a separate parameter like SlowUpdateTimerMillisec that is used when that command line switch is specified.

When using the "Open in File Manager" action on a file, it can have a somehow confusing effect. Usually no file manager is opened, but an editor, or some other application. Sometimes also nothing happens.

Maybe this could be more like an "Open with..." action with xdg-open as default or something like that.

If you use QDirStat to scan a Btrfs partition, any subvolumes of that partition are not scanned: Btrfs subvolumes are treated just like ordinary mount points (which, to all intents and purposes, they are). So you might wonder why the df command shows your 40 GB root filesystem as 97% full, yet QDirStat shows only about 7 GB. The rest might be hidden in subvolumes.

QDirStat stops reading at mount points - which only makes sense because normally you want to know what eats up the disk space on that one partition that is filling up, not on any others like /home that are mounted there. Unfortunately, a Btrfs subvolume is also just another mount point, and QDirStat will start reading there, too - at /var/log, at /var/spool, at /var/lib/libvirt etc.; a typical Btrfs root filesystem has about a dozen subvolumes, and all files in them are currently disregarded by QDirStat.

You can of course click on "Continue reading at mount point" individually in
QDirStat's directory tree for each one of them, but that's tedious.

WinDirStat has this feature, and I really like it.