General IT News, Tech Information and Analysis

What happens to Emails, Twitter & Facebook when you die?

Remember the time you poured your heart out in an email to your friend or that sexy message from an old lover that made you blush at work? Well, if you die, your family and others could end up reading them !!

Web email services owned by internet giants Google and Microsoft have a policy of keeping your data after you die and letting your next of kin or the executor of your estate access it.

Accounts with Google’s Gmail can hold up to 7GB – or roughly 70,000 emails with a small to medium picture attached to each. And they archive the messages you’ve written as well as received. When it comes to deleting the data, Microsoft’s Hotmail will remove an account if it is inactive for 270 days, while Gmail leaves the responsibility to the next of kin.

Of the top three providers, only Yahoo! refuses to supply emails to anyone after a user has died. The user’s next of kin can ask for the account to be closed, but cannot gain access to it. A Yahoo! spokesperson said the only exception to this rule would be if the user specified otherwise in their will.

Few days back, I had a Crazy question which popped up in mind –

” Can we give a privilege to someone, who can update our Facebook / Twitter when we die? – Just one tweet/update that – this guy is no more! “

I wrote to the Privacy team of Twitter on the same. Here is the the response I got – “If a twitter user passes, we will remove the account or leave as is on request of the family. We will not send out any tweets on their behalf or give access to the account to anyone else.”

Facebook has recently publicised a feature called memorialisation that lets the family of deceased users keep their profile page online as a virtual tribute. Turning a profile into a memorial will remove sensitive information from the page and restrict access to the deceased’s friends. The family will not be allowed to log in to the account or access private messages, but can request that it be taken down.

Click here to read the policies of popular email and social networking sites » (source –

FAQ Microsoft Windows Installer, Application Compatibility and Deployments

Windows Installer FAQ – Part 4

instAs you guys are aware, I am writing a series of posts which covers some key discussions, topics and FAQs in the stream of MSI Windows Installer and application packaging. In this fourth part, we will look at some questions on MSI properties and key scenarios which can easily achieved by using the properties appropriately.

Q16. What are the types of properties and when do you use a Private property?

Properties are global variables that Windows Installer uses during an installation. As MSI is a database type structure, all the properties are saved in a table called PROPERTY table.  There are three types of properties.

PUBLIC: These properties can be changed by the Application packager in a transform / a system administrator can change it through the command line.  These are always in Capital Letters.  These properties are set during installation and it can be overridden in command line. Ex: INSTALLLEVEL, ALLUSERS, INSTALLDIR.

Properties that are set during the User interface dialogs should be public.

PRIVATE: These properties are used internally by the installer and their values must be entered into the database by the author of the installation package or set by the installer during the installation to values determined by the environment. For example, if the installation is run on a Windows platform, the installer sets the WindowsFolder property to the value specified in the Property table. These properties cannot be changed by the System administrator in command line and its always in lower cases. EX: WindowsFolder, SourceDir

RESTRICTED PUBLIC: There are certain conditions where SystemAdmin can exert control over the PUBLIC properties so that a user with an elevated privileges can’t modify or access them so as to maintain secure systems these properties are know as Restricted PUBLIC PROPERTIES. These properties has a limited set of values. For eg: ALLUSERS,REBOOT

The best practice is to set the ALLUSER property  =1 because if the application is to be installed to per machine and a user without admin access try to install that it will prompt an error but in the other cases it will be a peruser installation without any prompts.

Q17. What would you do, when you (do not) want your installer to restart the machine after installation?

The REBOOT property takes care of this.  The REBOOT property can have any of the below values.

REBOOT = Force – Always prompt for a computer restart at the end of the installation. The UI prompts the user to restart at the end. If there is no user interface, the system restarts at the end of the installation

REBOOT=Suppress – Suppress restart prompts at the end of the installation. During installation, Windows Installer prompts the user to restart whenever it encounters ForceReboot set by the application vendor

REBOOT=ReallySuppress – This will suppress all restart prompts that ForceReboot initiates during the installation and also suppress all restart prompts at the end of the installation.

Setting the REBOOTPROMPT property to Suppress (or S) allows Installer to perform a computer restart, if necessary, without prompting the user.

Q18. How can you disable/Hide an application from Add/Remove Programs?

Setting the ARPSYSTEMCOMPONENT property to 1 will hide the application from appearing. Also, ARPNOREMOVE property to 1, will just disable the remove button from Add/remove Programs.

Q19. When would you use REINSTALL property and what is its significance?

REINSTALL is an important property which is used while Application patching and Upgrades.  If you set the REINSTALL property, you must also set the REINSTALLMODE property, to indicate the type of reinstall you want.

When the REINSTALLMODE property is not set, all files currently installed are reinstalled, but only if the file on the computer is an earlier version or is not present. By default, no registry entries are rewritten if REINSTALL is set to ALL, only features already installed are reinstalled Thus, if REINSTALL is set for a product that is yet to be installed, no installation takes place.

 By default the REINSTALLMODE is “omus”.

For eg: Msiexec /p AdbeRdrUpd913_all_incr.msp REINSTALL=ALL REINSTALLMODE=omus

 p – Reinstalls a product only when a file is missing

  •  o – or an older version of a file is installed
  •  e – or an equal or older version of a file is installed
  •  d – or a different version of a file is installed
  •  c – or the stored checksum value doesn’t match the calculated value
  •  a – Forces all files to be reinstalled
  •  u – Rewrites all required user-specific registry entries
  •  m – Rewrites all required computer-specific registry entries
  •  s – Overwrites all existing shortcuts
  • v – This switch forces the installation to ignore the cached MSI package on the machine and recache the new package being run. This should only be used in an upgrade and not with a first-time installation.

Q20.  Which are the Properties that are mandatory for an MSI installation to work?

ProductCode; ProductLanguage; ProductVersion; ProductName;Manufacturer

For Information on ADDLOCAL property, check this article –

I would recommend, You read the other parts too – Part 1 , Part 2 , Part 3 , Part 4, Part 5 (Coming Soon)