[Kde-pim] Moving pim data to new kde install

[Kevin Krammer]

On Friday, 2011-11-04, ianseeks wrote:
> On Thursday 03 Nov 2011 20:32:22 Ingo Klöcker wrote:
> > On Thursday 03 November 2011, ianseeks wrote:
> > > Wouldn't it be nice to have a "kontact" link directory that you could
> > > just copy and it pulled in all the various parts of the PIM together
> > > instead of having to search out all the disparate parts of it.
> > 
> > There is such a directory. It's called $HOME. I will not get tired of
> > preaching that the only sensible way of migration to a new system is a
> > full copy of the entire $HOME directory. I have been doing this
> > successfully about 7 times or so for the last 15 years and I have never
> > lost a single bit of data.
> 
> I've never lost any data either but if i was going to back up all the data
> for one app, it would be simplier and more sensible to have one directory
> to copy. I've always found the system performs better when i start with
> new config files, i'm never sure if old, no longer used config data (or
> files) is deleted when they upgrade an app.

The use case of copying or creating a backup of $HOME is to preserve a user's 
data, independent of the type of data (documents, photos, contacts, and so 
on).

Where those files are exactly within $HOME is usually each user's choice, e.g. 
some might store all their documents in $HOME/docs, some might have 
subdirectories depending on context (e.g. $HOME/work, $HOME/private).

Users who only want to copy specific types of data, e.g. spreadsheets, will 
usually adjust their directory structure accordingly and configure applications 
to point to the respective "root".

By default most applications use only one storage location so all their data 
remains in a narrow locality.
Data that is not specific to an application, e.g photos, contacts, and so on, 
is usually located in type specific default locations.

However, locations can usually be reconfigured, e.g. in order to procude an on-
disk layout more suitable for a certain use case.
For example a user who wants to have contacts, calendars and emails close to 
each other would most likely reconfigure these three data type specific 
locations in such a way that they would be close to each other, e.g. sharing a 
common root directory.

> > If some people think they need to use a more complicated method then
> > that's their problem.
> 
> To my mind, having the data for Konact spread all over the file structure
> is more complicated. We're not all developers and highly technical but
> making things simpler would be more reassuring.  I realise there is a huge
> legacy of changes to Kontact and its parts and it maybe a huge undertaking
> to do it.

Traditionally the default root has been $HOME, which has the additional benefit 
of also including configuration.
In the last years this has become somewhat more fine grained with the 
introduction of $HOME/.local/share as the root for application data and 
several document centric roots ("My Music").

On new setups applications are often using those per default, on exisiting it 
usually depends on the application whether it moves data or prefers to 
preserve the user's configuration of locations instead.

Since all new default locations and even most user chosen locations are inside 
the traditional root of $HOME, using that for a starting point of backups is 
something that almost always works without requiring any special knowlegde.

Users which more specific requirements, e.g. having certain types of data co-
located somewhere, will usually reconfigure storage locations to suite their 
needs.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20111104/a6547482/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/