Find it here. The link is also in the link list in the sidebar.
being users of WinDirStat and perhaps having contacted me through the contact form or other means, would you like to see a Wiki and or forum for WinDirStat instead of merely the trackers and the mailing list (which is virtually dead, except for the very frequent spammers, which you wouldn’t get to see because the whole list is moderated).
A forum may offer a more lively discussion among users and may be a little more exposed than the mailing list is. This way I’d also spend less time supporting users because you folks could – by merit – become “community” moderators and help newbies or in general help other users. Last but not least this might be one way to share cleanup (and soon other scripted) actions. For the latter a Wiki may be more suitable or even just in addition. The forum AFAIK isn’t tied to the SF.net accounts if we run it on SF.net, but the Wiki would, I think. I only remember faintly from Enchanted Keyfinder.
Whatcha think? Let me know in the comments. Thanks and get well into the year 2013.
I have started to sign the commits to the source repository using GnuPG and will expect the same from future contributors to the project (although OpenSSL with X509 certificates will also be accepted, of course).
It provides a level of trust and the possibility of additional integrity-checking for the source code. Starting with revision 300 on the master repository (on SF.net) this takes effect.
Additionally I am keeping a clone on Bitbucket, for “backup purposes”
The website is now also available via SSL. This also means that you will be able to use the contact page via SSL.
who of you uses the cleanup actions or even created their own? How complex are they? How difficult would it be for you if they got replaced? I suppose I would provide some rather trivial migration path, but I’m curious. Surprise me …
… you’ll have to have a 7.x SDK registered for any Visual Studio version before 2010. Currently I build with Visual Studio 2005, but solutions exist also for 2008 and 2010.
The reason for this new limitation is that I implemented the progress inside the Windows 7 taskbar buttons.
Side-note: preliminary elevation support exists and I will try to finish that up over the weekend. Thanks to Chris. Once that stands, the next step is to work on limiting the memory use.
More to follow soon,
PS: I used the 2D-icon set for now. It looks quite good also and since it’s not a release version it doesn’t matter too much. Oh, and the icon is partially responsible for why there were issues with VS 2005, too. If you have problems with the icon set in VS 2005, try copying the
rcdll.dll from the SDK
bin folder into
C:\Program Files\Microsoft Visual Studio 8\VC\bin (or wherever you installed your VS 2005).
tuqueque sent me the logo project just recently. So tonight I sat down to play a bit with what we got. Since I’m not quite so brilliant with graphics, I had to rely on a little help from IconWorkshop to get this done. The (3D) result, to me, looks pretty convincing for Vista/7 style … however, even the 2D version looks quite nice.
Which version(s) would you prefer? Should I go for another color instead (see previous post)? Do you think that the 3D-effect should not be shown at some of the resolutions where it now exists or be shown at resolutions that are now flat?
For those who want to test it on their desktop or in some folder, please download the 2D-version and/or the 3D-version by right-clicking the links in this sentence and then using the “Save As” functionality of your web browser. Yes, just opening it in the browser may not yield the desired result
Thanks for your input,
PS: Please note that I went for the gray one intentionally at 16 colors. It simply looks better than any dithered and scaled down version of the colored logo …
PPS: The stuff is all in the repository.
here is another logo proposal from Venezuela. Frankly, I find it more original than the logo suggested by Storm!. In a strange way it condenses the meaning of what WinDirStat does into a symbol. However, I found there were some demeaning comments about Storm! who also put his time and work into creating his logo. Perhaps you folks could consider that all of this is done in our spare time and in all these years there was only one patch sent to us from outside the team. So please: keep it real
Anyhow, here are the logos and icons as suggested by tuqueque (click for full resolution):
The logos scale neatly as they are in a vector-format.
Please comment. It seems it was put under Creative Commons Attribution, but since there exist variants of that license, I’m going to check back. Until then, for your consideration.
Logo design by Robin “tuqueque” Marín
PS: Given that the MFT parser I’ve been working on requires admin privileges, I was considering to use the different icon colors as indicator as to what mode it is running in (e.g. with admin privileges or not). I’ll have to test it in Vista and 7 to check the feasibility, though.
PPS: Yes, I heard you. I am working on an alpha release that will have some of the new functionality (and a x64 version) so people who have been yearning for updates will have something to check out and provide us with feedbacks. Sorry for the long silence.
Storm! has joined the team and provided us with a new logo and splash screen. Have a look. And please comment:
Please welcome our new project member Juan (aka neglox)
So far WDS has proven to be fairly stable, but there are people who claim to have seen mysterious crashes every now and then. Now my question: if I was to implement a method in WDS that allows me to get a crash dump (or call it “snapshot”) of WDS at the moment of the crash, would the users be willing to send that information or not?
Yes, there may be sensitive information included in that it might also contains file or folder names. Otherwise no sensitive data will be transmitted. Windows Error Reporting (WER), which is part of Windows at least since XP does the same in a semi-transparent way to Microsoft (and commercial third-party vendors through Microsoft’s WinQual).
I want your thoughts.
In order to implement this feature, there is a clear tradeoff: memory. The memory usage will, at least temporarily, spike more than it currently does. However, given that Microsoft surely has put a lot of thought into the structure of the MFT we can at least assume that the respective data is stored efficiently.
Just a few comments on my progress. As it appears there is no way to get access to a volume unless one has administrator rights (or – presumably – the volume ACL was changed?). That, of course, creates the problem that the speedup is only available to admins.
However, I think that WinDirStat is mostly used for administrative purposes anyway, thus it will be fine to limit the speedup to this part. Please note that this does not mean that running it as unprivileged user wouldn’t work anymore, but even now this yields biased results …
BTW: the speedup is quite astonishing in my experiments so far.
PS: Yes, I’m talking about read-only access to the volume …
Recently I got an email asking for a trimmed down English-only version of WinDirStat. To be honest I was quite flabbergasted and upset. After all both developers involved in WinDirStat are native Germans, so why not make it a light version that is German-only? I think everyone knows and accepts that English is the lingua franca of the modern world, but by the number of speakers you shouldn’t underestimate Mandarine either. The author of said mail had an English name so we can safely assume he was a native speaker of English. But why the assumption that a light version (he was referring to PortableApps as well) has to be English?
In fact besides the <Unknown> issue the translations were the next biggest issue for me. Why? Because the current system doesn’t allow users to translate themselves and maintain those translations independently from a developer who will have to link the resource DLL for that language. This is something that needs fixing, not the availability of those languages in the installations.
So, sorry. For the moment I’m not up for such an English-only light version. But after all it’s OpenSource … patches are welcome. But then there are these more pressing issues which really ask for patches …
After a user has provided feedback with a potential way of increasing the speed of a scan manifold, I’m currently exploring the USN journal as well as using the MFT (on NTFS drives only) in order to enumerate the contents of a drive or subfolders on it.
Although I’m not fully back to normal, I’ll start development again and hope to have a version ready around September.
I dislocated my right shoulder a few days ago and will therefore not reply to emails or work on WDS in the next three weeks – minimum.
I’ll undergo orthopedic surgery on 27th of April, which will most likely prolong the break.
When the project was still under Bernhard’s rule, he was always going to release only versions that had passed his test plan. I hope to break this tradition soon and release more often and release earlier. My goal is to put all of the code-base under a testing harness that will allow me to verify and validate much of the functionality without too much manual interaction required. This means you will see unstable versions tagged as “alpha”, “beta” or “RC” (release candidate) as well as stable releases. It is on you to decide whether you want to contribute to the development by testing any of the unstable versions, or whether you want to stick with the stable releases only.
Please note that I will follow these guidelines:
PS: Once I am done with the migration of the translations to XML (see previous post), I will release a first alpha version that has the multi-selection feature activated. It will also have an optional online update-check. Before a beta I want to include an improved mouse-navigation as well as a save/load feature to save time and not having to re-scan a directory structure every time. I personally also liked the proposed ignore feature.
just wanted to let everyone know that I am currently working out a format for what’s now the resource scripts in XML. You can find a first draft version in revision 174 in the Subversion repository. As you can see, you will have the translations “side-by-side”, which should also make the job of translators easier. Since the encoding of the XML files will be UTF-8, all languages should be just fine, as all natural languages and several artificial languages (such as Klingon) are covered by the Unicode standard of which UTF-8 is one incarnation.
If any of you has ideas for how to improve the current XML format (more additions will follow throughout the next few days), please let me know here in the comment section, via our contact form on the website or in a tracker or the discussion forum at SF.net.
Rationale: it has been increasingly difficult to manage the translations (be it new translations, edits of existing ones by native speakers or changes in the GUI by me). Therefore I was for a while now looking into moving to a more manageable solution that will not require the translator to contact the developer, let alone have the developer “compile” the translation. Of course even with the new system it will be necessary that I include a new language in a future release, but there will be more flexible means of updating languages via the internet and translators will be able to contribute in a very flexible fashion as well.
PS: The XML parser (TinyXML with TinyXPath) will also be used to save/load a scan.
The migration to Subversion apparently did have some cost attached to it. Just found out that for whatever reason the resource scripts have been garbled. Hmpf …
Actually the culprit must have been one of the editors used two/three years back, according to the history. It only affected those languages with real diacritic characters (e.g. Polish) and completely different alphabet (Cyrillic/Russian) that could not be fit into the 1252 ANSI code page (the default on my system). This website from Microsoft really helped to find the correct matched for each code page. Hoefully the UTF8 version of the resource scripts is now correct. Parsing the strings inside string tables was pretty straightforward, but the PITA will be the controls in dialogs (which also need to be extracted). Just to explain briefly what I am going to do: all the resource DLLs will be replaced by a text file (most likely XML, as the saving of reports is another good reason to use an XML library already). This will allow anyone with basic understanding of computers to contribute translations (or pieces thereof) without having to know the (slightly convoluted) syntax of resource scripts (