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).
// Oliver
PS: Feel free to comment on this post.
Please add support to not show duplicate hardlinks. On Vista+ systems, the space displayed is primarily doubled due to hardlinks against the “actual” file contents under %windir%\winsxs. A toggle to show/hide these types of duplicate files would be great. Thanks.
Well, which one should be shown and which not? That’s the trouble with hardlinks: there is no only legit “base”-link.
For the most part tho, the file under \winsxs is the “real” file on Vista. Toggling to hide hardlinks then would hide hardlinks not under that path.
So you suggest hiding everything outside that place? What about MKLINK and other tools which I like to use to create hardlinks (e.g. DFHL)? Those hardlinks will be hidden as well.
I think you certainly have a point here, but they shouldn’t be hidden either way. Instead WDS should handle this properly. So I’ll work on this. There is another problem on 64bit, btw, which prevents it from seeing the “redirected” files (such as those under system32), causing wrong results on any Win64.
You could do a fileid lookup, those that are under winsxs with a linkcount > 1 could have other links hidden.
If only they’d hardlinked the “real” copy and junctioned the others it would be a bit easier. AV/backup apps would’ve hit issues tho…
Great app – glad to see you’re continuing to refine it. Thx much.
I don’t see the point of a x64 release, there are api’s to allow 32bit apps to see an unvirtulised view of the filesystem.
A 64bit build seems an unnecessary complication for both you and the potential downloader.
Oh and awesome app btw!
Looking forward to see how you deal with the hardlink problem.
Good point, it might be additional hassle indeed. But I’ll decide after actually checking the performance differences. I can imagine that particular operations would be faster natively.
Oh if it’s faster, I’m all for it!
(need an excuse to load a 64-bit on this box anyway… :P)
It would also be great to be able to save out reports. Right now I end up taking a screen cap of as much of the window as I can.
Is anyone still reading this ?
64 bit is worthwhile. New machines are being sold and supported exclusively on 64 bit Vista (e.g. Dell Studio XPS with Core i7). There are issues with 32 bit apps accessing low level information – besides, performance is impared with 32 bit applications…
Yes, someone is still reading it 😉
The point is, though, that currently we have 2 different “editions”. One with full Unicode capabilities and one with ANSI only. ANSI is also always slower, because all the ANSI APIs on Windows NT and later convert the string to Unicode anyway (well, as much as a mapping is possible). 64bit and ANSI is pointless. But should we drop ANSI ultimately (not necessarily the option to get back to it, but cease to develop that branch, so to speak – or should we continue ANSI + Unicode 32bit + Unicode 64bit.
BTW: The performance impact on WOW64 programs is minimal. Has to do with how the stuff is passed to the kernel. And depending on what you consider low-level, I cannot really see what information is hidden from WDS that would be interesting for this kind of application 😉
Yes please.
This would be nice to have support for x64 Vista and the new Win 7.
Thanks.
WDS runs on Windows 7 and on Vista as well as on x64 Windows versions. It just doesn’t support some obscure new features and in case of x64 Windows it runs in WOW64 mode (whose performance is nearly the same as for native x64 applications).
But the plan now is to drop 9x versions (i.e. ANSI versions) and concentrate on Unicode and NT versions with x86 or x64 processor. Itanium is not planned (specifically because I have no way of checking it!).
It would be great to have a 64bit version of WinDirStat.
We occasionally would like to run it against a very very large file system and the current 32bit one crashes (guessing it runs out of memory)…
i’m not sure if it does or doesn’t. but reading directory directly from lower level api would be faster if it doesn’t do it this way already.
like dfrg.msc (and mydefrag), and any other defragger.
like everything.exe that read directly instead of scanning through using api. i’m not sure how “low” level they use, but i do think reading data in disk-layout order would be faster than in directory order which might make the disk seek like crazy
wonderful!
64 and 32 bit versions!
i like much to have win2000 –> win7 compatibility for 32 versions.
some features i wish:
– a “save” feature for reading pre-retrieved data and a “compare” function to see what is happening and where! (differences before/after)
– a commandline version! i know well this is a GUI util, but if i can launch unattended tasks all over the network, or perform scheduled tasks of unattended WDSC (windirstat_commandline!) and then collect results, read them when i can … this would be good! 🙂
commandline functions would be as powerful as you can imagine some useful features. Naturally the GUI program have to be used for “seeing” results.
if you can create a “.WDS” format … You can see something like this (LIKE!) in “OverDisk” program: let’s see! 🙂
THANKS FOR THIS GREAT UTILITY 😮
Command line version won’t happen. Using the GUI version in some unattended mode may become possible, but no guarantees.
The file format would likely be an SQLite database.
well … something like “windirstat [/q]” … this could be scheduled, also in quiet (no gui) mode…
it’s only an idea 😉
THanks! 😮
Libraries are a great feature of Win7. Although I run Win7-64 Ultimate, I would vote for support for the “obscure features” ahead of 64-bit support (I know it’s already done, but this is my opinion).
People who don’t know how Win7 Libraries are implemented may just want to point WinDirStat at the Libraries they have created, to know how much stuff is there (of course, it is mainly elsewhere).
When they do that, an interim measure might be to pop up a message with a simple explanation.
What do you reckon?
love the program, have used it for years, thanks++
Feature wanted: snapshot/cache
At home, running WDS on my home PC, /indexing/ my NAS can take quite some time. Some sort of offline or caching mechanism to reflect the state of the NAS that might be loaded up on startup from the previous session (and perhaps updated in the background?) would be useful.
Is it possible to search for a filename? I have a need to search for files in NAS drives. Perhaps searching via windirstat would be much faster if it is possible!
I have a 64 bit desktop and 1.1.2.80 Unicode works fine for me.
The only REALLY cool thing I’d like to see is a way to delete more than one file at a time. I have dozens of empty folders hanging out at the bottom of WinDirStat and having to peck around deleting ’em one by one is a pain. Thanks for all your work. You’ve improved my online experience greatly!
😀
Yes, but that is also somewhat dangerous. Work on this is underway, though.
Check out this one: http://sourceforge.net/projects/rem-empty-dir/
I just add this comment to express my amazement to how useful this tool is. Congratulations to the creators, and I am rather suprised no big company has bought this product to implement it into others.
Best regards.
Glad to hear you’ve resumed development on WinDirStat!
As for the hard-link issue, you’re going to have to keep track of the NTFS object identifier on NTFS. Links aren’t supported on exFAT or earlier FAT-based filesystems (per this SuperUser question)), though, so there the unique ID can still be the full path.