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:
- alpha (may become a weekly or nightly build) is a very early version of a future release. Neither is it guaranteed to work properly, nor at all on your machine. Also, new features in such a version may be unstable. As an example, a saved scan may not be loadable in a “beta” or a stable release of this version.
- beta means that the version is reasonably stable. Features available in a beta may disappear in the stable release, or change considerably.
- release candidate (RC) is a version of the software that has the full set of features (“feature-frozen”) of the anticipated next stable release. One of the RCs will eventually become the actual stable release if no bugs/issues have been reported within a certain time frame.
- stable releases are what you already know from WinDirStat.
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 (
Since we have some subscribers, I thought I’d let you know that the work has been resumed very officially and that first steps towards a version 1.3 are in full progress.
What I plan to introduce are …
Source code level:
- Namespaces (new own namespaces and proper usage of existing ones)
- C++ typecasts where possible
- Moving #defines to real C++ constants where possible
- Update check that can be enabled by the user to receive notifications
- Better mouse navigation
- Save a scan and load it later
- Save report into file (perhaps different formats)
- Proper handling of WOW64 environments
- Explicit Windows Vista symlink handling
- Configuration from different sources (incl. .ini file)
- Native x64 version
- A brand new logo that has been created for and donated to the project (I will likely post a preview soon)
Features that will be removed:
- Support for Windows 9x/ME will be dropped in this upcoming release. Affected users can use the last 1.2 version …
- Support for Windows NT 4.0 may get dropped
- The feedback (bug report) dialog will be replaced by a link to our website where you will be able to enter descriptions of undesired behavior or simple praise
- The send report by mail feature will be removed, instead you will be able to save reports to at least one computer-readable and at least one human-readable file format
Just recently Bernhard received fan art, from a WinDirStat fan and forwarded it to me. We got the permission to put it up on the website by the author, so I am doing this now and here. The image (thumbnail below) shows the patterns of a cushion tree map, nicely shaded so it will work well as a wallpaper. And guess what, that’s what it’s meant for. It fits perfectly to a dual-monitor setup with a resolution of 1280×1024 on both screens. Seems like to appreciate its full beauty you’ll have to grab your copy
Go ahead, right-click and choose “Save target as”:
Thanks to Mathias for sharing it with us.
Good news first. Development on WinDirStat has officially resumed.
Now the question. I know as a matter of fact that there is demand for a 64bit version of WinDirStat. However, since 64bit implies Unicode, there is no need to handle this specifically as long as the compatibility requirements ar Windows 2000 and above. Nevertheless, as you know we actually do have an ANSI version. My proposal would be the following:
- I’ll try to keep compatibility as much as possible, even for Windows 9x/ME.
- Emphasis will be put on Windows 2000 and above – meaning it will be native Unicode.
- The versions offered will stretch 32bit (x86) and 64bit (x64) with Unicode. ANSI may be made available separately.
- New features will only be available in the Unicode versions, but bugs will be fixed in the old one and selected features may be migrated back.
I’ll add a poll soon at this place (possibly as a new post, so people who subscribe to the RSS feed get to see it).
PS: Feel free to comment on this post.
The company behind STOPzilla doesn’t seem to deem it necessary to react on a false positive report from someone who hasn’t bought their software. This means it could be that their software still detects WinDirStat and since I am not able and/or willing to check it on a regular basis, I can only recommend that none of our users use this software for their protection.
Should something get moving, I’ll keep you updated here on the blog.
STOPzilla, an antispyware is catching the most current WDS installation package as Zlob.YU. While one should never take this too light-hearted, the first reaction of the user who contacted me was of course rather in the direction of an accusation. Nothing wrong with that, if it would have turned out to be true. Not at last I am an AV researcher and developer. Although probably SF.net would be to blame if something like this happened, because all downloads run via them, this would be horrible for my reputation as well.
So, what now? First of all I want to reassure everyone, that the two download samples from different SF.net mirrors that I have taken are not infected, but still reported as Zlob.YU by STOPzilla. Since all mirrors are supposed to be in sync and I got the first report two days back, all mirrors should have the infected file version by now – if there ever was any threat. Instead the fact that only STOPzilla finds it, points to a false positive and I am going to contact the vendor about it.
Second, you need not trust me on that, instead I suggest to visit Jotti and VirusTotal, although these are also not 100% reliable in the end, the heuristics and signatures of different AV scanners are used to examine your file, which gives you a fairly good hint as to whether the file is infected or not.
I re-released version 1.1.2 with two additional languages earlier today.
Please note that I aim for a release with functional updates between around end of this year and beginning of the next year.
The short answer is: yes.
The long one is: there is no reason why WDS wouldn’t be Vista compatible. However, depending on how you start it (elevated or not) you will not be able to see certain parts of the file system (which is just the point with the elevation model). Naturally WDS, running under your credentials will have the very same problem, so you should expect to find a – potentially large – chunk called
in the root of the drive you are scanning.
Please search this blog for further information on the
I have to confess, I fell in love recently. Sounds weird? Right, it gets even more weird if I tell you that I fell in love with a file manager. The file manager is called Speed Commander (SC) and I am truly sorry to not have found it years ago. The respective project exists already for more than a decade.
So what’s so cool with it you ask? SC is shareware. This means you can try before you decide whether to buy it. Although I am developer of more than one OpenSource (and therefore also free – as in “free beer”) software, I usually try to balance between the effort required to write it myself and the time it would spare me to use such a program instead of the one I am using at the moment. The predecessor of SC on my machine was Turbo Navigator. Since it was written in Delphi or Borland C++ Builder, its Unicode support was non-existent. However, it was free (as in “free beer”) but not OpenSource. Neither is SC, in fact SC is commercial and ClosedSource. Nevertheless it rocks. This file manager is a joy to use. The only things that really distract me at the moment are the new program icons, the rest is better and some stuff I have to get used to.
Give it a try. In fact I think about porting the treemap code into an ActiveX and write a plugin for SC to show treemaps directly there. Of course such an ActiveX (COM) control would be accessible from any other application as well. The idea is to make WDS more modular and allow to share the code-base for the treemap between WDS and this ActiveX.
Several users had contacted us and claimed that WDS caused their systems to show the dreaded BSOD. As a driver developer I know that this is impossible since no user mode program can crash the system with BSOD unless some driver or other kernel mode component fails to check its parameters or whatever else.
Anyhow, one of the users sent me a minidump. This is the only way to find out who’s the culprit after a BSOD. In fact a full dump does as well, but a full dump has the size of the RAM on the user’s machine which is not usually practical (given sizes of 1 GiB and more).
The minidump showed that the fault had occured in a component of the Novell Client software. Although this justifies a strong suspicion, it is not a guarantee, since the respective bugcheck code occurs if some kernel mode component has corrupted the memory of the driver shown as faulty. My only recipe was to update the client software, if possible. There is no other way than this or uninstalling it completely (which usually isn’t an option at all ;)).
As before, the
item keeps us busy. Last week a user contacted us through the blog and later through email and chat as suggested.
As you know, the
item just shows the discrepancies between the used disk space reported by Windows and the size of the sizes of files and folders found by WinDirStat. The biggest problem is that WinDirStat has to have access to the files and that these files have to be enumerated. So if the files are hidden from normal Windows file functions, there is no way for WinDirStat to detect them. This and the way some backup software seems to function was the problem on the machine of the user who contacted me.
Thanks to the ever-increasing amount and frequency of spam-comments, I removed the option for comments for now. However, I’ll attempt to work out a fix (possibly similar to the fix I use in the UVNC forum) and then enable it again.
Sorry for the annoyance :-[