Migration off of Bitbucket done

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

  1. GitHub, GitLab, SF.net and possibly including Bitbucket also []
This entry was posted in Announcement, Pre-release, Project news. Bookmark the permalink.

14 Responses to Migration off of Bitbucket done

  1. Renato Bosa says:

    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!

  2. Gentils says:

    Hello,
    Does the Issues/Features tracker has been set up somewhere else?
    I would have like make a proposition.

    Thanks !

  3. Oliver says:

    @Gentils: Just activated the ticket tracker over on OSDN.

  4. Melchior says:

    Thx for keeping WinDirStat alive.. its a great help when trying to find out whats hogging
    HDD/SSD space…

  5. Thorsten says:

    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.

  6. Oliver says:

    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.

  7. ID-107 says:

    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.

  8. ID-107 says:

    *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

  9. Oliver says:

    @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.

  10. Thorsten says:

    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.

  11. Oliver says:

    Regarding my fast NTFS processing tool, I did not recognize you are answering here. I rather had thought you reply by e-mail.

    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).

    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().

    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.

    The discussion about closed source is in this case somewhat strange, because you also call FindFirstFile() / FindNextFile() in kernel32.dll, which is closed source.

    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.

  12. Thorsten says:

    >> 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).

  13. Thorsten says:

    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.

  14. Thorsten says:

    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?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.