The new (temporary) home for the repositories and historical downloads is over on OSDN for now.
I’m planning on hosting the authoritative repositories myself in the future and I am contemplating mirrors (albeit without the ability to accept pull requests) on the usual Git hosting platforms1. I need to automate more and get some things in order for this to happen, the whole sunsetting of Mercurial support on Bitbucket has indeed drained a lot of resources on my part already.
Basically I want all of these other platforms to be more or less satellites to the stuff in the upstream project. And automate populating them. So from where I stand now, interaction with users and other developers will likely not happen on those platforms, but may happen on OSDN or SF.net.
Once that’s done I’ll see to it that I get a first 64-bit enabled beta or release build out of the door, ASAP.
// Oliver
- GitHub, GitLab, SF.net and possibly including Bitbucket also [↩]
Hey, your software is amazing!!
Really!! WinDirStat and Anti-Twin are a unbeatable duo to save space and organizing files in Windows… and the two are free, the two are lightweight and non-invasive.
But today, first time, I realized that Dropbox SmartSync feature confuses WinDirStat.
I have a pretty big directory structure in dropbox, where most of the folders and files are not downloaded to my hard-drive, but dropbox makes “something” to make windows show all the “icons”, so you can right-click and select to make it “local”.
So, as I’m running out of space, today I ran WinDirStat to decide which folder I could make “just cloud” to free-up space.
When WinDirStat come up with the results I realize it did’nt get it right…
For example: a directory dropbox-setted to “just cloud” windows shows as “14,9GB” but only “4,95MB IN DISK”…
WinDirStat shows that it is taking 12,8GB.
So, I’m not complaining, because I know WinDirStat is a great piece of software, is free, is lightweigh and worked very well to me for years…
But I just feel that I could report this issue, so maybe it could be addressed!
Thank you!
Ps. I’m not a native english speaker, so sorry any language mistakes.
Peace!
Hello,
Does the Issues/Features tracker has been set up somewhere else?
I would have like make a proposition.
Thanks !
@Gentils: Just activated the ticket tracker over on OSDN.
Thx for keeping WinDirStat alive.. its a great help when trying to find out whats hogging
HDD/SSD space…
The contact link on the Windirstat website is broken. I developed a library to read the file structure of NTFS drives within a few seconds. Much faster than using stat() et al. For a hard drive with about 900.000 files and directories, it requires 10 seconds to read the whole directory tree, compared to 5 minutes, when using the standard Windows API. I am willing to provide a free license to this project, just contact me.
Hi Thorsten, thanks but not interested.
First there are free-of-charge and liberally licensed libraries around which parse the MFT just fine (even in various programming languages, if need be), but the biggest issue is that this “feature” is only a feature as long as the software runs as admin (or elevated, for that matter). That’s a prerequisite I am not ready to demand of users across the board. WDS is going to lack some minor features for unprivileged users, but it should be usable for them.
And even then a lot of extra book-keeping is required as well as precautions to prevent people from touching the wrong files. And it solves nothing for FAT, FAT32, exFAT or ReFS drives either. Also it will make it impossible to get the hydration state of cloud files (which gets synthesized by the FS driver when you traverse directories, but isn’t resident in the MFT to the best of my knowledge). So while I am in the process of abstracting the respective parts in order to plug in ways to supply data to create treemaps from, … and so plugging new methods to enumerate files and their properties would be an option …
… your proposal has one additional blocker issue: it would introduce proprietary software into what’s otherwise completely libre software. So that’s not going to happen.
Last but not least the closed-source nature of such a library would make it impossible to verify that you handle fragmented MFTs correctly and some other subtle stuff which eluded some of the authors of aforementioned publicly available libraries which I reviewed recently and longer ago.
I have also been tinkering with using directory handles to traverse down the directory hierarchy as this will avoid name lookups while traversing, and with IOCPs in that scenario. Results are promising, but probably not quite on-par with MFT parsing. Still these improvements will benefit all users on all Windows versions with all available file systems, while MFT parsing just helps those with MFT.
So thanks for the offer anyway.
PS: Actually the interface for plugging on own mechanisms will be under a more lenient license than WDS itself (some people would consider the GPL v2 too strict) and so you should hopefully be able to accommodate your own library this way. Since this will likely lead to a number of third-party extensions, I’ll be happy to feature yours when the time comes.
Where to acquire the latest stable version safely? And what are its hashes?
SourceForge dates the latest update as 07/15/2021
OSDN similarly dates the latest update as 07/14/2021, but currently has no downloads available
FossHub dates the latest update as 06/29/2018
Triple IT dates the latest update as 07/02/2007, even though your blog post about them is from 12/01/2013
And BitBucket of course no longer hosts WinDirStat
I understand the importance of having mirrors, but when they all are dated differently, and this website mentions different hosts as being the primary one in different places, while also including a myriad of dead links, it becomes very confusing for idiots like me.
*Erratum
SourceForge dates the latest update as 09/15/2021
OSDN similarly dates the latest update as 09/14/2021, but currently has no downloads available
FossHub dates the latest update as 06/29/2018
Triple IT dates the latest update as 07/02/2007, even though your blog post about them is from 12/01/2013
And BitBucket of course no longer hosts WinDirStat
@ID-107: the website should have all relevant hashes. What’s missing? Yes, I have no influence on the timestamps everywhere, but I made sure that the binary artifacts were available everywhere and I will make a new code-signed prerelease version available before year’s end (at least that’s the plan).
Could you point out which hashes you found missing? I’ll try to amend the lists and I can obviously offer to sign the respective hash lists via my PGP keys.
Regarding my fast NTFS processing tool, I did not recognize you are answering here. I rather had thought you reply by e-mail. Just for clarification: WDS would not require administrative permissions, because my tool runs as a service and communicates with the DLL; which in turn provides a simple API equal to FindFirstFile() / FindNextFile(). The discussion about closed source is in this case somewhat strange, because you also call FindFirstFile() / FindNextFile() in kernel32.dll, which is closed source.
Regarding your concerns about correct parsing of the MFT, my test software compares the results against FindFirstFile() / FindNextFile() and does not show any discrepancies.
You had written here, why should I change the medium? There’s a checkbox to receive email notifications and to the best of my knowledge this feature is active and working (if you check the box).
As a service it runs as part of the TCB (highest privileges in UM). This makes it even worse from the perspective of being a proprietary and closed source component.
It’s a system interface. The difference is that you propose to bundle your proprietary components — evidently there’s a service plus a DLL, as you can see from my response I was assuming solely a DLL (although a service explains how you manage to read the MFT, since this would require privileges) — with a GPL’d software. If you’re unaware of the implications of that, let me briefly state: bad idea.
Feel free to fork WDS for your purpose to include your library, but be prepared that people may start asking for the source of your DLL (and possibly the service).
I find it odd that your library finds no discrepancies, though, since I have tinkered myself with aforementioned liberally licensed libraries to evaluate inclusion of MFT parsing (even came up with the idea of a service, albeit for a slightly different related scenario) and found quite a few. It’s one of the more intriguing properties of MFT parsing that one gets to see items that you don’t otherwise get to see.
>> I find it odd that your library finds no discrepancies, though, since I have tinkered myself with aforementioned liberally licensed libraries to evaluate inclusion of MFT parsing (even came up with the idea of a service, albeit for a slightly different related scenario) and found quite a few. It’s one of the more intriguing properties of MFT parsing that one gets to see items that you don’t otherwise get to see. <<
Yes, well, I put some efforts into it, to solve those problems. 🙂
AFAIK shipping a closed source DLL does not violate the GPL, as long as the user can rebuild the open source application and it continues to work? The only reason which speaks in this case against closed source is, that the service or DLL might do something evil, like carrying a trojan or something. But since I put the name of my company into the version info, it would be a legal and financial desaster for me, if it contained malware.
There is one major reason, I wish to see it incorporated into WDS: I have done it, it is there and ready to use, I use WDS and like it a lot. It would make WDS several magnitudes faster, and last but not least the community could profit from it. (BTW, who is not using NTFS on Windows? I even use it for USB-sticks and external USB harddrives).
PS: If you like, I can e-mail you an installer for a demo, which creates a text file of a whole directory tree for a selected drive. The installer is primarily there to install the service without any hassle. It also prints the required time and memory usage.
Hello there! Here is another happy user that has been around from the early days of WinDirStat, signing in from Jokkmokk, just north of the Arctic Circle in Sweden. I have saved many hours of work by using WinDirStat, and I want to give something back.
I’d be happy to make a Swedish translation of WinDirStat if you don’t have someone else working on it aöreadu. Just let me know how to do it, and I’ll send you a translation back (including the help file, of course) in a couple of days.
I incorporated my library into WinDirStat, by inherting a new class from CFileFind, which went quite smooth. This way I could also implement GetCompressedLength(), because my lib provides this information. The result is quite good, but while building the treeview, the hard disk LED is flickering and it is not as fast as it should be. Somewhere WDS is still accessing the hard disk, but I could not find the place in the code. Can you give me a hint? Is it possible to communicate via e-mail?
Hello,
I like this software but it seems every time I use it I have to wait a very long time to see the results.
I was wondering if there could be a way that the index would be always ready to go as a background process. So that when I need to investigate my disk space, it would already be ready ?
And I realize that I already have such an index of all my files and their sizes which is being continuously update as a system service.
This index is the software Voidtool’s Everything, an extremely fast, efficient and effective search engine.
Are there ways to create plugins for Windirstat, or somehow connect the Everything files database ( Everything SDK here https://www.voidtools.com/support/everything/sdk/ ) to the Windirstat front end ?