Can't Remove Drive on Vista SP1

Link. February 24, 2008. Comments [0]. Posted in: Vista

I haven't noticed many issues with Vista SP1, despite some stuff I've read around; though overall haven't really noticed any significant performance difference besides file operations using Windows Explorer.

That said, I've noticed one nasty issue: I use an external USB drive that has a bunch of virtual machines, my music and other stuff. I'm usually very careful and always use the "Safely Remove Hardware" icon in the system tray to remove the drive before disconnecting it from the computer or turning it off.

However, ever since installing SP1, this operation fails about 50% of the time, saying the volume is in use and cannot be removed, even though there are no applications open that could be using the drive at all.

The past few times it's happened, I've fired up Process Explorer to try and locate what is holding on to the drive, only to find that the only process that has file handles opened in the drive is the "System" pseudo-process:

EjectDrive

No idea which driver is holding on to the handles, but based on the file names, I might guess it has something to do with the Kernel transaction manager and NTFS transactions. Why those handles are being kept there, I have no idea; but once this happens, those don't get released, meaning I have to shut down the drive improperly. Not good.

Simple Is Beautiful

Link. February 21, 2008. Comments [3]. Posted in: Vista
WinServer2k8

Am I the only one that thinks the Windows Server 2008 logon screen, with it's very simple blue background, is so much better looking that Vista's ugly and distracting "aurora" background?

There's just something highly appealing to me about keeping things simple and elegant...

WinSxS

Link. February 15, 2008. Comments [0]. Posted in: Vista

Size of %WINDIR%\winsxs:

  • Clean Windows Server 2008 Enterprise installation: 2.6GB
  • Used Windows Vista SP1 installation: 6.52GB

I know that Side by Side installation is important for compatibility and serviceability, but this might just be going a bit overboard....

Vista SP1 Installed

Link. February 15, 2008. Comments [0]. Posted in: Vista

Service Pack 1 for Vista is now available for download from MSDN (I guess the Windows Update rollout will still wait to march or something). For some reason, though, it is a 434MB, 5-language pack.

I downloaded it last night and installed it this morning without too much fuss, except for Windows Live Messenger now keeps triggering Windows Installer on startup and failing (but it works after that, funky).

Haven't really noticed many improvements yet, though moving/copying stuff around in explorer seems quite bit faster (that alone might be worth it).

User Home Folders

Link. January 9, 2008. Comments [1]. Posted in: Development | Vista

Jeff Atwood has an interesting piece about applications polluting the user space, forcing their own folder and file structures and other crap into the user's home folder. He's right, but I think he stops too early.

Jeff's right that the classical Unix practice is a bit better than what Windows has always provided (even on Vista). In a lot of ways, Unix is in a better position because of things that are not directly related, but that do end up helping the issue in the end, like a better (simpler!) overall file system layout, and not having to deal with drive letters (or the stupid registry, for that matter).

However, even Unix suffers from user space pollution quite a bit, though in a different way than Windows user suffer. On Unix, the issue is mostly applications storing temporary and configuration data all over the user's home folder in hidden directories.

Different Kinds of Data

There are several problems that affect how Windows and Windows Applications handle the users directory. For me, however, the lack of good, clear guidelines and the way that application developers abuse the user's home folder are secondary issues.

The real problem to me is that very few developers (or the OS providers, for that matter) realize that there's different kinds of user-specific data, each one with different requirements and storage needs.

I see at least three different kinds of data you might want to store in some user-specific location:

  1. The user's own data (documents, videos, music, projects, etc.). Applications will produce and manipulate this data but they should not dictate where and how it has to be stored; that's the user's problem.

    I hate it when applications insist on forcing a specific folder structure on me or on creating their own folders in my documents folder. Exactly because of this is that I've completely given up on using the "My Documents" folder on windows; and consider it pretty much a storage for temporary or throw-away data I don't care about (too many applications putting their crap there).

    I should point out that this category, for me, is, for the most part, about data the user is explicitly aware he is creating, not about other crap the application might be producing as a side effect. In other words, if you're thinking about saving a new file without asking me for a location, don't even dream about storing it here.

    Everything in this location is stuff I want to backup easily, without having to go around excluding folders created by tyrant applications.

  2. Application configuration data: This is basically your typical application user-specific settings. To me, data belonging here should be, unless something extraordinary is required, machine independent. This is the settings I simply want to take with me when I switch machines, or that I want to keep synchronized between machines to keep my applications working the same everywhere. Again, this is stuff I want to be able to backup easily without carrying extra loads of crap, but at the same time I don't want to have to deal with it (like navigate through it) unless I explicitly want to modify something here.

    I very much prefer applications store their settings in the Unix-fashion: using simple text files (whatever the format). Even though windows stores the user registry hive file inside the user's profile directory, backing it up is mostly an exercise in futility and it is non-portable for the most part.

  3. Other stuff: This will be mostly temporary or cache data used by applications, that I should never have to backup or care about. If it's gone, the application should be able to recreate it as needed or simply work without it. Classical example: a browser's cache and history files.

    Some Unix applications, for example, intermingle this data with their applications settings, which is a big no-no. You don't want to have to worry about backing up your browser settings and ending up with 200MB of its cache in it.

There are probably other kinds of data I'm missing, but the key point is that they are different and should be stored separately. I really wish more application and OS developers started using something like the above discrimination. It would make our lives oh, so much simpler.

Syndicate

About

Tomas Restrepo is a software developer located in Colombia, South America. His interests include .NET, Connected Systems, PowerShell and lately dynamic programming languages. More...

tomasrestrepo @ twitter My Flickr photostream My saved links on delicious My Technorati Profile

email: tomas@winterdom.com
msn: tomasr@passport.com

View my profile on LinkedIn

MVP logo

Ads


Links

Categories

Statistics

Total Posts: 1032
This Year: 102
This Month: 1
This Week: 1
Comments: 801

Blogroll

Archive

Other

Copyright © 2002-2008, Tomas Restrepo.

Powered by: newtelligence dasBlog 2.1.8139.823

Sign In