Bug 2847 - Make configuration OS-independent
Summary: Make configuration OS-independent
Status: RESOLVED LATER
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: UI/Compose Window (show other bugs)
Version: 3.9.0
Hardware: PC Windows XP
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2012-12-23 13:59 UTC by Bob Daniel
Modified: 2014-07-15 09:49 UTC (History)
1 user (show)

See Also:


Attachments

Description Bob Daniel 2012-12-23 13:59:21 UTC
This may be my ineptitude rather than a bug.

I want to use Claws on Windows and Debian, using the same configuration folder.

On Windows (XP and 7) I start claws with option
 --alternate-config-dir "z:\claws\config"
On Debian 
  --alternate-config-dir /mnt/Z/claws/config
where the two directories are the same.

But for the life of me I can't get the same signature filename, e.g. bobsig.txt, to work in both operating systems (using Preference/Compose.) If there is just the filename then the file's contents don't get inserted. And of course if I set up the full filename including full path then it only works with the corresponding operating system.
Comment 1 Ricardo Mones 2012-12-24 13:43:13 UTC
> This may be my ineptitude rather than a bug.

Neither the first nor the second ;)

> I want to use Claws on Windows and Debian, using the same configuration folder.

This feature, OS-independency of the configuration files, is not supported, so I'm turning this into an enhancement request.

There's ways to workaround this, for example turning your accountrc into a kind of accountrc.template where the signature path is set to some TOKEN, and a wrapper script (one per OS) takes care of filtering the template replacing the TOKEN and writing the result into the actual accountrc (a sed one-liner can do it), and then invokes claws-mail binary with the --alternate-config-dir option.
Comment 2 Bob Daniel 2012-12-25 14:22:28 UTC
Thank you.
Should the workaround work around (sorry!) if a second person starts Claws on a different OS?  Then accountrc would be changed, and I wouldn't expect the signature to work. But it does appear to work. So I am confused. I suppose accountrc is read just once?
Comment 3 Ricardo Mones 2012-12-26 15:05:22 UTC
If the workaround is set up as described it should work: _each_ OS has a script to write a correct accountrc from the template before invoking, so when claws-mail reads it it has the correct path on each OS.

The only drawback is when you alter the configuration of some account, you have to re-create your template from the real accountrc with the modifications, otherwise changes will be lost on next script invocation.

Or are you trying to do it with two instances of claws-mail, one per OS, simultaneously? This can work by luck, until you access same files from both instances. This is definitely neither supported, nor workaround-able.
Comment 4 Bob Daniel 2012-12-26 15:22:33 UTC
(In reply to comment #3)
> If the workaround is set up as described it should work: _each_ OS has a
> script to write a correct accountrc from the template before invoking, so
> when claws-mail reads it it has the correct path on each OS.
> 
> The only drawback is when you alter the configuration of some account, you
> have to re-create your template from the real accountrc with the
> modifications, otherwise changes will be lost on next script invocation.
> 
> Or are you trying to do it with two instances of claws-mail, one per OS,
> simultaneously? This can work by luck, until you access same files from both
> instances. This is definitely neither supported, nor workaround-able.

Just two instances! Where is your ambition (!). Potentially 4 as there are 4 in the family. The reason I moved from Awful Outlook was that one family member never closed Outlook, so we were all locked out due to its monolithic PST file.

But we never read each others' email so I suspect we shall be OK. We have been so far thanks to your suggested workaround.
Comment 5 Ricardo Mones 2012-12-26 16:03:08 UTC
There's no limit on the number of instances, as long as each have it's own configuration directory. But you are talking of same configuration files for all of them, there's no need to do that, and that's what's not supported.

Note You need to log in before you can comment on or make changes to this bug.