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.

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


  2. Gentils says:

    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.

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.