IT Consultant – Java, J2EE, IBM WebSphere Portal, Lotus Notes/Domino
RSS icon Home icon
  • [Solved] Windows 7 “Safely Remove Hardware” pop-up menu horrendously slow

    (4 votes) 1 Star2 Stars3 Stars4 Stars5 Stars
    Posted on 14 May 2012 Sebastian Thomschke*/?> No comments

    Since I upgraded to Windows 7 an annoying problem regarding USB device ejection bugged me for quite some time. At least for my system configuration I now seem to have found a working solution.

    The symptom: When you try to eject an USB device using the “Safely Remove Hardware and Eject Media” tray icon it takes ages until the popup menu appears where you can eventually select the device to eject from.

    The problem #1: When Windows tries to build the list of ejectable devices it also seems to scan all configured printers – unfortunately this does not only include local printers connected via USB but also network printers. Since I am working from different locations not all network printers are reachable all the time. But Windows still tries to determine the printers’ connection state and for offline printers this takes until a network time out occurs.
    The solution #1: The real solution for this would be if Microsoft would provide a patch that network printers are not taken in account when building the list of ejectable devices (which makes no sense anyway). As a workaround I disabled the “SNMP Status Enabled” option of the TCP/IP printer ports. You can do this as follows:

    1. Open the “Devices and Printers” control panel
    2. Click the “Printer server properties” button or via the menu File->Printer server properties
    3. Click the “Ports” tab
    4. For each port where the description says “Standard TCP/IP Port”, click “Configure Port…” and disable the option “SNMP Status Enabled”
    5. Voil√°¬°, the “Safely Remove Hardware” pop-up menu appears in a snap again!

    The only disadvantage of disabling SNMP status checking is that the printer control panel does not indicate the connection state of the network printers anymore. But for me this is the smaller issue.

    The problem #2: Unfortunately the described solution did not work on all of my machines (especially Lenovo ThinkPads).

    The solution #2: After a long search I eventually I came acros this post where it says:

    Windows 7 Lenovo preload
    It will take longer time to show a list for removal device candidates than previous OS, when clicking “Show hidden icons” from task tray then clicking “Safely Remove Hardware and Eject Media”.

    Cause of the issue:
    Windows 7 will start to scan some files in folders when click “Safely Remove Hardware and Eject Media”. Due to this scanning process, it takes times to prepare a list of devices.

    How to solve this problem:
    Eliminating number of unused files will shorten the scanning process.
    There are lots of files for national language support of the Windows in %programdata%\Microsoft\Windows\DeviceMetadataStore
    Usually in C:\ProgramData\Microsoft\Windows\MetadataStore. It carries various icon data and resource data for displaying in some managing process such as defining printers.

    There are “READ ONLY” folders like following:

    • cs-CZ for Czech
    • da-DK for Danish
    • de-DE for German
    • el-GR for Greek
    • en-US for English
    • es-ES for Spanish
    • fi-FI for Finnish
    • fr-FR for French
    • he-IL for Hebrew
    • hu-HU for Hungarian
    • it-IT for Italian
    • ja-JP for Japanese
    • ko-KR for Korean
    • nb-NO for Norwegian
    • nl-NL for Dutch
    • pl-PL for Polish
    • pt-BR for Portuguese (Brazil)
    • pt-PT for Portuguese (Portugal)
    • ru-RU for Russian
    • sl-SI for Slovenian
    • sv-SE for Swedish
    • tr-TR for Turkish
    • zh-CN for Chinese (Simplified, PRC)
    • zh-TW for Chinese (Traditional, Taiwan)

    Each folder carries 24 device metadata files except en-US carrying 26 files. Those file name will be “hexadecimal numbers”.devicemetadata-ms.

    Depends on your computing environment, there may be some language folders never used. Removing those folders and files will speed up scanning process remarkably.

    Note: en-US folder should not be removed. There are commonly used files in other language.

    Since those folders are read only, a following dialog will come up with attempting delete a folder. Click “Continue” button will delete a folder. If you need a administrator access to delete, please consult your system administrator.

  • [Solved] Blank Pages with WordPress 2.6.x

    1 Star2 Stars3 Stars4 Stars5 Stars
    Posted on 13 September 2008 Sebastian Thomschke*/?> 2 comments

    After upgrading to WordPress 2.6 it occasionally happend that an empty page was displayed in the browser when navigating through the blog or working in the admin area. Refreshing the browser using CTRL+F5 usually helped in that case. Today I upgraded to WordPress 2.6.2 and I was not able to access the plug-ins page of the admin area anymore. No matter how often I refreshed the page in the browser it stayed blank.
    First I searched the web for possible solutions. I found quite a number of discussions giving tips about this widely known problem but unfortunately none of these solutions helped in my case.
    So I again started debugging the WordPress code and finally found the lines of code causing the trouble. The problem are (object) casts in the wp-includes/taxonomy.php file that transform an array into an object:

    $wp_taxonomies['category'] = (object) array('name' => 'category', 'object_type' => 'post', 'hierarchical' => true, 'update_count_callback' => '_update_post_term_count');
    $wp_taxonomies['post_tag'] = (object) array('name' => 'post_tag', 'object_type' => 'post', 'hierarchical' => false, 'update_count_callback' => '_update_post_term_count');
    $wp_taxonomies['link_category'] = (object) array('name' => 'link_category', 'object_type' => 'link', 'hierarchical' => false);

    Since I don’t get any error messages neither on the screen nor in the log files I have no idea why these casts fail. The PHP version used to serve the site is the latest stable 5.x release from
    As a workaround I introduced a function that does also transforms an array into an object but does not rely on the casting mechanism.

    function arr2obj($arr) {
    	foreach ($arr as $k => $v) $obj -> {$k} = $v;
    	return $obj;
    $wp_taxonomies['category'] = arr2obj(array('name' => 'category', 'object_type' => 'post', 'hierarchical' => true, 'update_count_callback' => '_update_post_term_count'));
    $wp_taxonomies['post_tag'] = arr2obj(array('name' => 'post_tag', 'object_type' => 'post', 'hierarchical' => false, 'update_count_callback' => '_update_post_term_count'));
    $wp_taxonomies['link_category'] = arr2obj(array('name' => 'link_category', 'object_type' => 'link', 'hierarchical' => false));
  • Sun JDK5/6 compilers broken when linking overloaded methods with variable arguments

    (5 votes) 1 Star2 Stars3 Stars4 Stars5 Stars
    Posted on 16 May 2008 Sebastian Thomschke*/?> 1 comment

    We are currently switching the build system of OVal from custom Ant scripts to Maven 2. During that process we accidentally compiled the project using the Java compiler of the Sun JDK 5 instead of the AspectJ compiler. Surprisingly javac did not complain about the missing aspect class files. Instead it already aborted while compiling an ordinary Java class which only referenced other non-AspectJ related classes. This is the original error message:

    [INFO] [compiler:compile]
    [INFO] Compiling 180 source files to C:\projects\oval\src\trunk\target\classes
    [INFO] ------------------------------------------------------------------------
    [INFO] ------------------------------------------------------------------------
    [INFO] Compilation failure
    has private access in net.sf.oval.internal.ClassChecks 

    There exist multiple methods named addMethodParameterChecks in the class ClassChecks with different signatures. The problem is that javac tries to link against the wrong method when compiling the class calling one of the methods.

    Read the rest of this entry »

  • [Solved] WordPress 2.5 One-Click Plug-in Upgrades – Could not create directory

    (6 votes) 1 Star2 Stars3 Stars4 Stars5 Stars
    Posted on 25 April 2008 Sebastian Thomschke*/?> 42 comments

    Some days ago I upgraded my WordPress installation to the new 2.5 release. Being a lazy guy I of course wanted to use the new one-click plug-in upgrade feature to update several plug-ins. Trying to one-click update some of the out-dated plug-ins only resulted in the rather meaningless error message “Could not create directory”. So I started searching the web for possible solutions. I quickly found some posts explaining this issue to be a directory permission problem. Manually creating the /wp-content/upgrade directory and chmoding it as well as the plug-in directories to 777 should solve the problem. Unfortunately not for me. Therefore I rolled up my sleeves and started to debug WordPress…

    To cut a long story short, eventually I came across this PHP bug report #42739 mkdir doesn’t like a trailing slash when safe_mode is enabled and it turned out that this was the issue I was facing with on my hosting account too. The safe_mode option is enabled and WordPress tries to create directories that end with a slash (e.g. /htdocs/wp-content/upgrade/the-plugin/).

    After knowing the reason I could develop a workaround and finally got the one-click updater running. If you are facing the same issue you can try to use my patch too.

    1. Locate and open the file <wp_root>/wp_admin/includes/class-wp-filesystem-direct.php in an editor
    2. Search for “function mkdir
    3. Add the following statements to this method
      function mkdir($path,$chmod=false,$chown=false,$chgrp=false){
      	if( ! $chmod)
      		$chmod = $this->permission;
      	// workaround for starts here
      	if(ini_get('safe_mode') && substr($path, -1) == '/')
      		$path = substr($path, 0, -1);
      	// workaround for ends here
      	if( !@mkdir($path,$chmod) )
      		return false;
      	if( $chown )
      	if( $chgrp )
      	return true;
    4. Start one-click updating!

    Update 1:

    1. The patch also works for WordPress 2.5.1
    2. If applying this patch does not lead to success the problem may have a second cause. Therefore also check the permissions on the /wp-content/upgrade/ folder and it’s sub folders, e.g. chmod them to 777. If the upgrade directory does not exist at all it may be sufficient to create it manually.

    Update 2:

    1. In case the patch does not work check if you have the AskApache Password Protect plug-in installed.
    2. If so, try to deactivate this plug-in before you try to upgrade any other plug-in.

  • MyPad v1.1.6 – a PHP Editor

    (2 votes) 1 Star2 Stars3 Stars4 Stars5 Stars
    Posted on 26 July 2004 Sebastian Thomschke*/?> 3 comments

    MyPad is a very compact PHP Editor. I developed this editor because I could not find a suitable PHP Editor with a Single Document Interface.
    The Editor I was searching for should look and behave like Notepad, but should be able to colorize PHP source code.
    Such a small Editor can be perfectly used in conjunction with a norton commander like filemanager.

    Read the rest of this entry »