Pyrethrin and Permethrin Repellent Clothing Treatments

I used up my bottle of clothing repellent treatment and started searching for something cheaper including repurposing lawn or animal treatments. Most all of them use pyrethrin (natural) or permethrin (synthetic) insecticides. The natural form can trigger allergies while the synthetic is more common but possibly less healthy depending on what studies you look at. They're often combined with synergists like piperonyl butoxide (PBO) which reduce insect resistance to them.

 

There are concerns over toxicity to humans but both (and PBO) are found in medical treatments for lice and scabies, typically with concentrations in the 0.5-4% range. Animal treatments (for most any mammal except cats whose livers can't neutralize it) are available in concentrations in up to 10%.  Lawn and garden spray concentrations vary widely.  Clothing treatments are typically 0.5% permethrin, which is probably a regulatory limit, and don't contain PBO (Ben's, Coleman, Repel, Sawyer).

 

The main problem isn't these chemicals - it's the unknown "inert" ingredients. Most everything I've found uses "petroleum distillates" which is a non-specific category of chemicals. On safety data sheets their names and/or quantities are usually redacted as trade secrets.  According to an article by Consumers Reports some clothing treatments have additives to enhance adhesiveness but I suspect that's only what the manufacturers told them without providing specific chemical data.  Most insecticides are formulated to have long surface adhesion duration regardless of application target.

 

While trying to find and compare water-based and petroleum-based mixes I discovered an excerpt from a 2013 research book titled Biotextiles as Medical Implants by D. Tessier. In the search summary the chapter Surface modification of biotextiles for medical applications discusses durability of permethrin treatment. According to Tessier water-based treatments last for two weeks or two washings, oil-based for six weeks or six washings. Treatments last much longer if kept in sealed light-proof bags. I haven't found any specific info on the durability of pyrethrin but permethrin is considered to be longer-lasting due to better water and sunlight resistance.

 

According to a fact sheet (PDF) from the National Pesticide Information Center at Oregon State University, PBO breaks down in 3-8 hours in sunlight which may explain why it's not found in clothing-specific treatments.

Factory-treated clothing reportedly has much longer-lasting effectiveness than spray treatments.  My guess is they are using higher concentrations and perhaps enhancing the treatment bonding using elevated temperatures and/or pressures.

It seems like the best treatment would be water-based permethrin solutions but I haven't found any without PBO which only provides a short-term benefit.  The closest to ideal is MGK Sector Misting Concentrate which is 10% permethrin, 10% PBO, and less than 10% petroleum distillates.  The permethrin/PBO ratio of 1:1 is unusual since most mixes are 1:5 or 1:10 but would still have to be diluted.  The presence of unknown petroleum distillates is annoying in a "water-based" product but it is much less than regular sprays. I could avoid it with other solutions but would have to accept a much larger amount of PBO.  The only other option would be to buy concentrated permethrin in bulk off Alibaba and mix it myself.

Not surprisingly it comes down to cost, labor, and safety.  I'll have to study this a bit more.

Windows Update vs. apt-get

Windows 8.1 on my nephew's HP 2000-2c29wm had another malware meltdown and I wasn't able to save it.  To get it back to the operational level it was when I last fixed it, I had to do a factory reset (from the recovery partition) to Windows 8, install the free Windows 8.1 upgrade from the Windows Store, then reinstall everything else.

I start by dumping all of his Minecraft mods, pictures, music, and other files to another system (I hate single-partition configurations).  The Windows factory reset completes without a problem (maybe 30 minutes).  Norton is removed without a fight.  Next comes the first round of updates.  I'm on an Exede satellite connection with 10Mbps bandwidth but high lag.  There's also a 10MB monthly cap but 12-5am EST is the "Late Night Free Zone" during which data usage is ignored.  I start Windows Update just after midnight.  There's 112 updates with over 1GB to download.  After WU stays at 0% for an hour I have to check the directory size of c:\windows\SoftwareDistribution\Download just to make sure it's doing something.  It finally finishes downloading around 2:30am and begins installing the updates.  At 3:30am I go to bed because I'm tired of waiting for it to finish (90+ out of 112 updates installed).  I estimate it finished around 4:30am.  When I check it in the morning it's ready to reboot.  It still needs to finish installing the updates during the reboot cycle (about another 25 minutes).
 
But it's not done yet.  Another round of WU checks indicates there's another 500MB of updates to install so I head to the local library to use their faster connection.  Another two hours to finish that round (and this excludes the 20+ "recommended updates").
 
Why did I go through this?  Because the free Win8.1 upgrade requires it.  The upgrade itself is another 3GB+ download.  The library WiFi is free but it has a EULA with a 2-hour timeout (noted they're using IPCop).  About an hour into the Win8.1 download it timed out and I had to re-accept the EULA with IE.  The Windows Store handled this temporary problem by restarting the download from the beginning.  An hour and a half later, just before the library closed, it has finished the download and install and prompted to restart the system.  I shut it down (not suspend) and head home to finish.

I power it up and it loads the desktop.  Strange, I was expecting the installation to finish during boot.  Thinking in terms of "brain-dead design" I correctly surmised that restarting the system would finish the update while shut-down and power-up would not.  Another 20 minutes waiting for that to finish.

From my past experience the Win8.1 upgrade required multiple attempts to install intermixed with fixes by the Windows Update Troubleshooter.  Every time it failed to upgrade it spent another 30 minutes reverting.  While those problems didn't occur this time, when it finally loaded the Win8.1 desktop I was greeted with a Windows Installer crash dialog.  Luckily everything seems to be working in spite of that.

Time for another round of updates.  Another 700MB+ for 30 or so updates, most of which were .NET Framework 4.5 "optional" security updates.  Another hour and a half to install those including a reboot.  Then install a few more updates that didn't show up previously followed by another reboot.

I'm going to make a backup image before I continue so I don't have to go through all of this again. I still have to install Firefox, Chrome, VLC, Steam, and anti-malware tools (not that they're reliable).

On this same system Xubuntu 14.04 took about two hours to install over satellite using the Ubuntu Minimal ISO + xubuntu-desktop, libreoffice, openclipart, wesnoth, and a few other games and multimedia tools.  A couple gigabytes to download and installed and it was completely up-to-date.  The only things I had to do afterwards was create user accounts and install fgrlx and CDEmu from the repos.

I don't have a clue as to why updating Windows was so slow.  There weren't any anti-malware tools operating.  I removed Norton and Windows Defender was disabled.  It's not using an encrypted file system.  System Restore probably adds some overhead but that doesn't seem likely to account for all of the problem.  The HP crapware load is relatively minor as compared to other systems I've seen - Cyberlink multimedia tools, some free games, and a bunch of links to various services.

There is one thing that surprised me about all of this, other than the Windows 8.1 upgrade not failing this time.  The factory reset warned that all files would be erased so I expected to lose the Xubuntu partition.  Instead, the reset only wiped the Windows partition.  It still lost the Xubuntu boot loader configuration but that's relatively minor to fix. Update: I was wrong about the boot loader.  It survived the reset also.

Update: A Reddit discussion about this article yielded a few ways to improve the Windows upgrade/update process.

A little-known Microsoft how-to article indicates that only KB 2871389 and KB 2917499 updates are required before the Win8.1 upgrade.  It's annoying that the upgrade doesn't handle this itself.

There's also a third-party tool, WSUS Offline Update, that can download and cache the updates locally.  While it's not much help with single system updates it could be useful if you have an unreliable Internet connection or multiple systems to update and don't want to do slipstreaming.

Steam client missing images on Linux

If your Steam client is missing images (broken image icon) in the store or other pages then try this fix.  First exit the Steam client.  Then delete the HTML cache directory at ~/.steam/config/htmlcache.  Then start the client and browse to the problem page again.  The missing images should be reloaded from the server and display correctly.

The tilde "~" is terminal shorthand for your home directory but you can use any file manager instead of a terminal.  A file or directory that starts with a period like ".steam" makes it a hidden directory so you'll have to configure your file manager to show them (Ctrl-H toggles the setting in most file managers).

Workarounds for some game bit-rot on [A-Z]*Ubuntu 14.04

After upgrading to Xubuntu 14.04 x86_64 several games failed to work including Torchlight (from Humble Indie Bundle 6), Doom3, Quake 4, and Aquaria.  I had expected this because bit-rot is a common problem with closed-source games when upgrading.

Aquaria and Doom3 segfaulted.  Quake 4 failed to load textures and its log reported r600_dri.so problems.  These all had the same cause - the libs they included were incompatible with the newer libs being loaded automatically from the OS.  They also had the same solution - rename the included libs. On Quake 4 that included libgcc_s.so.1, libSDL-1.2.id.so.0, and libstdc++.so.6.  To determine where a dynamic binary is getting libraries from use the ldd command but only change those necessary to get it working else other compatibility problems may occur.

Torchlight would load but the cursor had a black box around it and none of the menu buttons could be clicked.  The only way out of it was Alt-F4.  Past experience had taught me that libSDL is a common culprit.  It was using version 2, the same that Ubuntu 12.04/Linux Mint 13 supplied, but the game worked without problems on them.  I suspected that changes to the lib since (or its dependencies) then had created an incompatibility so I simply copied the lib from 12.04 to the 14.04 system and put it in /usr/local/games/Torchlight/lib64.  The game started without problems.

Using different library versions works if they haven't changed much.  The better solution is recompiling the game with newer libraries but getting developers to do that with old closed-source games is difficult.  While fixing library problems is not n00b-friendly, it's trivial compared to what is required for getting old Loki Software games working.

Wgetting to the correct file name

One of the annoyances of using wget in scripts is the problem of files from some web sites being named "index.html" instead of the actual file name.  This is due to the use of the content-disposition header field (part of MIME) to indicate the file name instead of the URL.  Support for this field by wget is incomplete and disabled by default.

There are a few ways around this.  The easiest is to tell wget to look for it with the --content-disposition option.

Another option is to use curl --remote-header-name or aria2 instead of wget.

To easily create commands for more complicated file retrieval (with cookies, etc.) the Firefox add-on cliget can provide a command line for curl, wget, and aria2 in the opening download window.  It only shows the curl command line by default.  You can enable the others in cliget preferences (available in the cliget entry in about:addons).

The Heartbleed Bug and You

TL;DR: Most web sites have been leaking passwords due to a bug for the past two years.  Immediately change your Internet passwords for Email and financial accounts, even if you changed your passwords April 7, 2014 or in the days preceding.  Don't use the same password for all sites because if one is compromised, they all are even if some sites were not affected by the bug.  Use a password manager such as KeePass/KeePassX or Password Safe to keep track of them.  Don't click on links in emails, especially any that seem to come from your bank asking to change your password.  Go to your bank's web site directly by entering the address in your web browser manually.

Verbose Version
You may have seen reports about the Heartbleed Internet bug in the news lately.  Note that the term "bug" doesn't mean malware or a virus, just an unintentional flaw.  This particular bug is a vulnerability in the encryption system used by about 2/3rds of the Internet web sites.  Ignoring the hype, on a scale of 1 (ignore) to 10 (critical) this is an 11.  Read this through entirely before panicking.

The bug allows an attacker to potentially obtain passwords from web sites or the credentials of the web site itself (possibly for creating a fake web site that validates as authentic).  Most web server operators can detect if they have the vulnerablity but not if someone exploited it.  While there are lists of affected sites and test services that can tell if a web site is affected, there are so many that it's best to assume most sites you have passwords on were exploited.  Microsoft's web sites were NOT affected since they have their own encryption system, nor were web sites operating with their software (not that they haven't had many other security problems).  But it's difficult for web users to determine what software a site is using now or what was used previously.  The software you are using on your computer, tablet, or phone doesn't matter since the vulnerability affects the servers you connect to.

What to do?  Immediately change your passwords.  You should change them periodically anyways, at least once a year depending on how complicated and long they are.  Log into your account there and look for a password change option.  Sometimes this option is on the account's "profile" or "preferences" page.

If you change your password on a site that is still affected the benefit will be temporary since an attacker can just obtain it again.  Many of the affected web sites have been fixed in the past two days but even those that were safe at the time the bug was found may have already been exploited if they were vulnerable any time in the past two years when the bug was introduced.

You can expect to start receiving notices from major companies about the need to change your passwords.  Don't wait for them to contact you.  Some web site operators may underestimate the risk or be reluctant to announce it due to liability concerns.

Because of the size of the problem you can also expect fake emails (phishing) prompting you to change your passwords.  These are attempts to get your current passwords.  To avoid being caught by these never click on a link in an email.  Always go to the web site directly by entering the web site address into the web browser's address bar or by searching for the company by name using Google.

I suggest prioritizing password changes as follows.  Some web sites and vendor names are listed as examples but not all of them had the Heartbleed vulnerability.

1. Email (Google/Gmail, Yahoo!).  Do these first since they can be used to reset passwords on most other web site accounts.  If your email provider has other services (Google+, Google Docs, Yahoo! Groups) then changing your email password usually changes it for everything else from them.
Google password change: https://www.google.com/settings/security
Yahoo! password change: https://edit.yahoo.com/config/change_pw

2. Financial (banks, credit unions, investments, IRAs, pensions, PayPal)
3. Government (healthcare.gov, passports, social security, taxes)
4. Password services (a.k.a. "Single Sign-On").  If you are using a service that controls access to multiple web sites (OpenID, Facebook, Google), then change that too since a breach with it can affect multiple sites.  Usually these aren't used for financial and government sites so the potential damage is less but they affect many other web sites.
5. Any site that stores your credit card or financial information (Amazon.com and accounting sites like Mint.com).
6. Vendors (insurance, medical) and utilities (power, phone, Internet) that have your Social Security number or you have set up for automatic bill payments.
7. Any site that makes payments to you (eBay, Etsy, Freelancer.com).
8. Computer remote backup services.  These usually don't have the encryption key for reading the contents of your backup data but someone with your password may be able to delete your backups.  If your encryption key was weak (short and simple), an attacker that obtains your backup data via your password may be able to break the encryption key by trying every possible key combination.
9. File hosting services (Dropbox, MediaFire, Google Drive).  An attacker can install malware within the hosted files and spread it to everyone that accesses them.
10. Social networking sites (Twitter, Linked-In, Reddit, dating) and picture hosting sites (Imgur, Panaramio, Photobucket) are less important but worth changing if you have information on them that you want to keep private.
11. Passwords for blogs and web sites you have made should be changed to prevent them from being used to host malware.

Vendors that don't keep your credit card info (i.e., you have to enter it every time you buy something) are less of a risk but you should consider changing those of vendors you depend on the most and keep an eye on your credit card statements.

Passwords used for starting your computer or unlocking your phone are probably not affected.

Some wireless Internet sharing boxes (routers) you may have in your home or business have built-in web servers for configring them and many are affected by the Heartbleed vulnerability.  Fortunately the configuration web site ususally can't be accessed by people on the Internet unless the device is intentionally configured to allow remote access.  Unfortunately manufacturers aren't likely to fix any that have the problem.

Some security systems and home automation systems also have web access and can be affected.  If you have a system that you can control from a web browser (on your computer or phone), then contact the manufacturer or installer to verify it and get it fixed if necessary.

You should not use the same password for multiple sites.  If one is compromised, then they all are regardless of which has the Heartbleed bug. Create unique passwords for each and use a password manager program to keep track of them.  With a password manager you create a single (preferably long and complicated) master password you can remember.  This is used to encrypt its password list.  You then use the manager to create complicated random passwords for each web site, preferably random letters and numbers at least 12 characters long.  Many web sites accept much longer passwords and typographical characters (@$%*&...) but not all do.  You don't have to remember these, just copy and paste them from the password manager as needed.

Many web browsers also have password managers built-in and prompt you to store passwords when you enter them.  But these password lists are often not well encrypted which makes it easier for an attacker (or other users of your computer) to obtain them.  In addition,  if you decide to change web browsers, these password lists can be difficult to transfer.  Standalone password managers avoid this problem and can also be used for other codes and non-Internet passwords.

Two popular free password managers for desktop and laptop computers are KeePass and Password Safe.   I use KeePassX on Linux and it's installed on every system I build (in the menu: Applications > Accessories > KeePassX).  It's compatible with KeePass on Windows.  It's available in the repositories of most Linux distributions (Ubuntu, Linux Mint, etc.)

Obviously the password manager will now be the center of your Internet life so it's important to make a backup of its password file, perhaps to a Flash "thumb" drive, and keep it in a safe place.  To limit loss in case your computer is burned up in a house fire, keep the backup in a different location like in the house of a relative, your car or a safe deposit box.  And don't forget its master password!

Changing many passwords is a pain but don't ignore this critical security problem.  The damage is already done and all you can do is prevent further damage to your Internet accounts.

You can panic now.

Cleaning up the Ubuntu and Linux Mint game menus

Most kids love games.  Thanks to F/OSS developers, Humble Bundle, Desura, Steam, and a variety of cross-platform Kickstarter and Indiegogo projects they now have many to choose from with more on the way.

But when I set up a system and start loading dozens of games the desktop menus become quite a mess.  Some games are not listed, or are listed in only in the main "Games" menu but not the correct sub-menus, or are listed in multiple sub-menus, or missing icons, or fail to function.

This is on top of the usual problems with broken packages, bitrot with old closed-source games (Loki titles in particular), conflicts with PulseAudio, and a lack of documentation combined with unusual keyboard key assignments.  The latter is really annoying when a game launches full screen and the user is unable to figure out how to exit it.

Obviously some problems are much more difficult to resolve than others but the desktop menus are fairly easy to fix.  I have fixed dozens and you can do the same.  The link to the archive with my changes is at the bottom of this post but before you get into that you need to understand how the menu system works.

Originally all window managers and desktop environments used their own menu configuration files.  One legacy menu structure is located in /usr/share/applnk.  Debian created a standard for their distro where a menu file was created once in /usr/share/menu and then exported dynamically as needed for each menu system.  Later, freedesktop.org (formerly named the X Desktop Group) developed a new standard that has been adopted by Gnome, KDE, Xfce, and others.

With the fdo/XDG standard the menu entries are created as INI files according to the Desktop Menu Specification (*.menu) and Desktop Entry Specification (*.desktop).  The latter standard also defines how to specify the names and icons of the menus themselves (*.directory).  Most desktop environments follow v1.0 of the standard but a v1.1 draft is in development.  The *.menu files are located in /etc/xdg/menus.  The *.desktop files are located in /usr/share/applications or /usr/local/share/applications.  The *.directory files are located in /usr/share/desktop-directories or /usr/local/share/desktop-directories.

A note about /usr, /usr/local, and /opt.  Their structure is defined by the Filesystem Hierarchy Standard. The first two follow the traditional *nix structure where binaries, libraries, documentation, and support files are organized into specific subdirectories by type and may be shared with other programs (especially libraries).  Files for programs in /opt are organized by provider and are generally contained entirely within their own subdirectory and not shared with other programs.  In practice, /usr is where files "managed" by a package manager (apt) are located.  Unmanaged files are in /usr/local and are usually not registered with the package manger.  Files in /opt may be managed or unmanaged depending on their source (an install script or a deb package).

Unfortunately some games don't follow the FHS properly.  Some managed packages put their files in /usr/local and some installers put their unmanaged files in  /usr.  Other installers add their files and then ask to "register" with the package management system for easier removal, resulting in a mix of managed and unmanaged files.  Managed files can be identified using dpkg-query:

dpkg-query -S /path/to/filename

If dpkg-query doesn't find the file then it's not managed.

Desktop entries are organized according to rules in the *.menu files.  While a *.desktop file can be specified directly, most are arranged by matching "Categories" values in the files.  According to the standard there are both "Main" and "Additional" categories.  A desktop entry file should have one Main category except as required (for example, "Audio" or "Video" mandates "AudioVideo") and an Additional category for more precise organizing.  Most of the Additional categories are reserved for specific Main categories.  Obviously sub-menus have have to be defined before they can be used else everything lands in the primary menus.  Linux Mint's Xfce menu configuration doesn't define the game secondary sub-menus by default (mint-artwork-xfce package) so the games menu gets very crowded.  My menu configuration defines sub-menus for all standard game categories.

Desktop entry files with multiple Main and Additional categories specified is an occasional problem.  While some programs can arguably fit into more than one category, doing this in the desktop entry file often causes duplicates in the menus.  Duplication can be suppressed with menu rules but it's much easier to avoid the problem in the first place.  Some desktop entry files don't specify an Additional category and as a result the menu entry lands in the primary sub-menu, not in the secondaries with similar programs.  Occasionally there will be a standards-compliant combination of Main and Additional categories that are not handled properly in the menu definition files which results in an entry erroneously stuck in the main menu or under an "Other" sub-menu.  But errors in the desktop entry files are the root cause most of the time.

Another problem is the categories themselves.  The video game genres are somewhat ambiguous and many games overlap multiple genres.  Even the main category "Game" can be a problem with some.  Emulators, for example, can be specific to a game console (PCSX) or general-purpose (QEMU).  The fdo/XDG standards only cover a few game genres, some of which are very narrow while others are overly broad.  These are my interpretations:

ActionGame: A catch-all for anything that requires reflexes that doesn't fit in a more specific category.

AdventureGame: Point-and-click adventures and interactive stories.  If it requires reflexes then it doesn't belong here.  Even so, there are some games which have a mixture of both so it becomes a judgment call as to developer intent (Full Throttle).

ArcadeGame: An ambiguous genre unless you restrict it to games that were found in coin-operated arcades at some point.  I included games with simplistic gameplay and a minimalistic storyline, if any.  If it has a point-based "high score" then it's probably an arcade game.

BoardGame: Board games and games that could reasonably be board games or were derived from one.

BlocksGame: Tile-matching and Tetris types, as per the Wikipedia article.

CardGame: Probably the easiest to figure out although gtali is a bit of an oddball.

KidsGame: Another non-genre genre.  I included any game with a theme that is heavily slanted towards young children.  However, some also fall into the Educational main category (GCompris).

LogicGame: Slightly odd name as it includes puzzles.  Again there are some platformers that combine this with action (EDGE, Stealth Bastard).

RolePlaying: If it doesn't have a character development system then it's not a role-playing game.  Having a fantasy theme is not good enough.  Waste's Edge is an example of a game that says it's a role-playing game when it obviously is an adventure game.  It's nothing more than a long dialog puzzle.  It's not a bad puzzle and has a good story, but it's not a role-playing game.

Simulation: Vehicle, economic, and environment simulations including cars, cities, and space.  Car racing games are often marketed as sports games but that never seems to include airplane racing games.  Some vehicle simulations have cinematic physics and may belong elsewhere (ArcadeGame, ActionGame).

SportsGame: Traditional sports not involving vehicles.  Includes "fantasy" sports management applications.  Real sports management applications probably belong elsewhere, perhaps Office/ProjectManagement.

StrategyGame: Some are obvious, some not.  The problematic ones are those that require tactics but not quite long-term strategic thinking (Atom Zombie Smasher).  I tend to follow the developer's opinion but not always.

Amusement: Snowing desktops (xsnow), eye-candy (xdesktopwaves), and the like.  Doesn't have a defined Main category but I set all the ones I found to Games since that is the most logical option.  Creating a new primary sub-menu didn't make sense.

Shooters: This is new in the v1.1 draft specification.  Again it is a bit too broad of category but because the ActionGame category is so crowded I decided to support it, just not by default.  I wrote the "set-shooter-categories" script which changes some of my desktop entries to this category (mostly first-person shooters) but the targets are all hard-coded.  It doesn't have a reversion option so keep a backup copy of the original *.desktop files.  I defined a Shooters sub-menu in my replacement menu definitions (applications.menu, xfce-applications.menu) and included an icon and the shooters.directory file.

Adding to the problems are programs that represent many games including the Steam client, Desurium, and gtkboard (which includes Tetris and Mastermind).  I normally just leave these in Games by not specifying an Additional category.

Some games in the repos have the old Debian menu files but not the newer fdo/XDG files.  There is an optional "Debian menu" that can be merged with the newer menu files to create a "Debian" sub-menu with all the old menu entries.  However it has a different structure and is mostly redundant with the main menus - overkill for just getting some games to show up.  I encountered the missing *.desktop file problem often enough that I wrote the "deb-menu-conv" script to export old Debian menu files as something that resembles the new fdo/XDG files.  While deb-menu-conv handles the basics, some things like categories (called "sections" in the Debian menus) do not translate directly.  It has some hard-coded conversions for games but most anything else will need manual editing.  Debian menu files also allowed multiple menu entries per file while the fdo/XDG standard does not.  All entries found in a menu file are exported by deb-menu-conv and have to be split manually into separate *.desktop files.  This script saved me a whole bunch of time but some packages were still a pain (xmpuzzles, xteddy, x11-apps) due to the number of entries their old menu files contained.  I excluded most terminal and text-mode entries.

Some of the programs in the Debian menus are obsolete but I included them as a test of deb-menu-conv.  Many of the amusement-type programs (xfireworks, xsnow, xpenguins) require direct access to the primary X window (root window) that is commonly controlled by a desktop manager in modern desktop environments (xfdesktop in Xfce).  They can be used on Xfce if xfdesktop is terminated first (Settings Manager > Session and Startup > Session > xfdesktop > Quit Program).  Log out and back in again or create a launcher in a desktop panel to restart xfdesktop afterwards.

I also fixed some other bugs via the desktop entry files.  Doom3 doesn't get along with PulseAudio so I added pasuspender to the Exec line in its file.  Some games have both 32-bit and 64-bit versions but their installer only adds one or the other and they have different names.  This meant that a single menu entry couldn't support both so I had to replace it with two different files.  For several of the games with undocumented keys and lack of built-in help I added additional menu entries that open man pages, Readme documents, and web sites with relevant information. 

One parameter that is very useful is "TryExec".  This is a test where the menu system looks for the target file and only shows the menu entry if it is found.  Since it is targeting executables it can be used to check for both file and directory targets.  All of my desktop entry files have this set so that if they are all installed they won't crowd the menus with entries for unavailable programs.  This is also handy for menu entries that target the 32-bit and 64-bit versions of a binary.  However, if a game normally installs both then only one entry is used and it points to a script that dynamically loads the correct binary based on the system architecture.  I wrote or modified several game loading scripts for this reason (and to fix other bugs).

Installing a modified menu or desktop entry file is easy if it is unmanaged - just overwrite the original.  However, managed files are more complicated.  If an update is installed by the package manager then the modified file may be overwritten.  The solution is to divert the original file to a different location with dpkg-divert.  When apt applies the update it will then redirect the diverted file to the new location, leaving the modified one intact.

The installation of the modified files is easy when only a few files are involved.  But I ended up with dozens which I realized would be error-prone and time-consuming to install.  So I wrote the "file-overrides" script to handle installation automatically, make backups of replaced files, and be able to revert changes.  It has built-in help but I will summarize the basics here.

Overrides are located in a subdirectory structure that mimics the actual targets.  The default directory is /usr/local/share/file-overrides.d which contains two subdirectories, managed and unmanaged.  The difference is that managed targets are diverted (and moved) by dpkg-divert while unmanged targets are moved directly.  These subdirectories must exist else the script will abort.

The diversions and backups are located in /usr/share/Diversions/file-overrides by default and this directory must also exist.  The script will create "managed" and "unmanaged" directories as needed and will remove their contents automatically during reversions.

The structures are relative so that a replacement for managed file:

/usr/share/appications/quake3.desktop

is located at:

/usr/share/Diversions/file-overrides/managed/usr/share/applications/quake3.desktop

During an override operation the original will be moved/diverted to:

/usr/share/Diversions/file-overrides/managed/usr/share/applications/quake3.desktop

prior to being replaced.  During a reversion the sequence is reversed, more or less.  While intended for fixing menu entries the script can be used to replace any file on the system.  It does have some special support for the *.desktop files.  Normally the script will only install an override file if the target already exists to keep the directories clean.  However, if the file is a desktop entry file with TryExec set, and the target executable exists, then the override will be applied even if the target *.desktop file does not exist.  The --force parameter applies all overrides regardless.

Another special case is with override files that are zero bytes in size.  This causes the target to be moved/diverted but not replaced, essentially causing a deletion.

See the readme.txt file for more info on included icons and such.

The archive contains everything.  Note that it has been developed and tested on Ubuntu 12.04 (Precise Pangolin)/Linus Mint 13 (maya) with Xfce 4.10.  It will probably work with newer releases (and Debian) and other desktop environments with the exception of the menu files which may need adjusting.  Compare them to the originals in /etc/xdg/menus.


file-overrides.d_v1.1.tar.bz2

md5sum: b15e343fe9c901f4556bed27fbce8cf8