oauth2-auto plstore sometimes saves keys in non-plstore files

[telotortium]

I'm trying to use oauth2-auto for kidd/org-gcal.el#200, but I sometimes find that the plstore data is being stored not in the plstore file that oauth2-auto creates, but rather in my Org files.

[uwabami]

I am managing ~/.emacs with dotfiles, so ~/.emacs is a symlink to ~/.dotfiles/emacs.d. This is probably why writing to oauth2-auto.plist always fails in the version with fix #7 (the problem does not occur with oauth2-auto before the fix).

What should I do?

[agenbite]

I'm in the same boat:

deferred error : (error "BUG: Attempted to write ‘oauth2-auto’ keys to /home/jlaznarte/.spacemacs.d/oauth2-auto.plist, not ‘oauth2-auto-plstore’ (~/.spacemacs.d/oauth2-auto.plist).  Please report to https://github.com/rhaps0dy/emacs-oauth2-auto/issues/6.")

I also use dotfiles and my main spacemacs file is a link.

[telotortium]

@agenbite @uwabami I just merged #16 and backported to org-gcal (see kidd/org-gcal.el#216), so your issues should be fixed.

[agenbite]

Thanks, @telotortium!

Hm... now it connects allright but my appointments are not copied over to gmail. I'm seeing that it actually syncs the wrong file: for some reason, instead of syncing gcalendar.org, it is syncing gcalendar.org_archive. Why would that be?

It also asks for the creation of a password several times (one per calendar?), and then asks for that same password. Which it didn't before.

[telotortium]

Both of your issues are strictly-speaking https://github.com/kidd/org-gcal.el issues.

Hm... now it connects allright but my appointments are not copied over to gmail. I'm seeing that it actually syncs the wrong file: for some reason, instead of syncing gcalendar.org, it is syncing gcalendar.org_archive. Why would that be?

What does org-gcal-fetch-file-alist contain? Also, org-gcal-sync syncing existing events in the archive file is expected - it will attempt to track org-gcal events in any file that has ever contained an event, as well as all agenda files and their archives (see org-generic-id-update-id-locations). It should not be fetching new events to the archive file (unless the archived event is a repeating event and the newly fetched events are instances of that repeating event).

It also asks for the creation of a password several times (one per calendar?), and then asks for that same password. Which it didn't before.

Known issue. Right now it creates a separate plstore file for each Calendar ID, because that was the fastest way to change the existing code to use plstore. I'm tracking support for multiple accounts in kidd/org-gcal.el#199, after which you'll have a single password for each Google account.

As documented in the org-gcal.el README, you should set the following variable to minimize the number of password prompts:

(setq plstore-cache-passphrase-for-symmetric-encryption t)

[agenbite]

What does org-gcal-fetch-file-alist contain?

(("[email protected]" . "~/org/gcalendar.org")
 ("d1d7g1bg[REDACTED][email protected]" . "~/org/calendar2.org"))

Also, org-gcal-sync syncing existing events in the archive file is
expected - it will attempt to track org-gcal events in any file that has
ever contained an event, as well as all agenda files and their archives (see
org-generic-id-update-id-locations). It should not be fetching new events
to the archive file (unless the archived event is a repeating event and the
newly fetched events are instances of that repeating event).

Understood. Thanks for the clarification.

Known issue. Right now it creates a separate plstore file for each Calendar
ID, because that was the fastest way to change the existing code to use
plstore. I'm tracking support for multiple accounts in
kidd/org-gcal.el#199, after
which you'll have a single password for each Google account.

Good to know! Thanks!

(setq plstore-cache-passphrase-for-symmetric-encryption t)

It's set. And I still get two password creation prompts.

[zarthross]

For any other poor soul that ends up here still seeing this bug... I found that doing this BEFORE running org-gcal-fetch for the first time fixes the bug. I'm guessing that until the oauth2 file is saved for the first time it doesn't see the file and buffer as the same thing.

(unless (file-exists-p oauth2-auto-plstore)
      (write-region "" nil oauth2-auto-plstore))