Appstore version 'forgetting' directory authorisations, after doing several file copy operations

[GoogleCodeExporter]

First of all, if you have any Haxies, InputManagers, SIMBL plugins or
similar operating system hacks installed, please remove them first, restart
the program, and make sure the bug is reproducible without them.

> No, none in place.

What steps will reproduce the problem?
1.  Browse a file in a directory "A" (mine had 3700 items in it)
2.  Check prev/next works; and you can browse the directory
3.  Drag another directory "B" onto the Xee dock icon (~4000 items in it for me)
4.  Browse images in directory B
5.  Using the shortcut key to previous 'copy destination' (Cmd-1 in my case) 
copy images from B -> A
6.  Copies work fine, but after a few attempts the windows showing the file 
from 'A' turns to 'static', and reports 'No images found' at the bottom
7.  Doing prev/next brings up file-open dialog (Xee does not have 
permission...); but after clicking 'open' it still reports 'no images found'

What is the expected output? What do you see instead?

- the 'A' directory image should never change (except for the count of how many 
files are in that directory)
- I have previously authorised directory 'A' -- so don't quite get why i need 
to reauth it in the first-place.

What version of the product are you using? On what operating system?

- 3.0.5 (22)  via App Store

Please provide any additional information below.

- the first 1-2 times this occurred; i _believe_ doing steps 7 worked - and 
after re-authorisation it resumed browsing the directory from the previous 
image.  However, i can't get that 'workaround' to function this time. 

- If i quit Xee; and re-browse the A & B directories it works (e.g. is auth'd) 
-- but this problem pops up again, reasonably consistently.

Original issue reported on code.google.com by mcac...@gmail.com on 4 Aug 2013 at 6:56

[GoogleCodeExporter]

After this occurred again, I tried using Xee 2.2 to browse folder 'A' ; 
... and Xee3 to browse folder B and copy selected files from B->A.

After several successful copies; i got an error '... couldn’t be copied 
because you don’t have permission to access ...'.

So it looks like it's not just related to browsing A; but simply losing access 
to the other directory authorisation completely.

As an experiment; i then tried removing directory 'A' from the "copy panel" 
(e.g. under 'select a destination' and then re-adding it.  I had expected it to 
reauthorise it; but it just silently failed. It didn't add the A directory back 
in, and didn't appear to copy either.

Original comment by mcac...@gmail.com on 4 Aug 2013 at 8:05

[GoogleCodeExporter]

A further side-effect of this issue i believe:

- I restarted Xee3 and added directory 'A' back into the copy destination; and 
then moved it up to slot 1 (so shortcut is Cmd-1)
- If i then quit Xee3; and reload it -- the copy destination has gone 
completely.

I also believe that the copy didn't actually proceed in this situation, but 
didn't return an error either (I didn't regression test this yet).

But, if:

- I open directory B in Xee3
- then open directory A in Xee3 (same instance)
- then copy from B->A; and drag the destination to top
- then quit Xee3 and reload.
- ... then the destination is retained

e.g. it appears necessary to authorise directory A by BROWSING; not just simply 
selecting it as a copy-destination.

Original comment by mcac...@gmail.com on 4 Aug 2013 at 8:17

[GoogleCodeExporter]

After re-adding directory A as a copy-destination (comment #2 above), it 
appears to successfully copy even if i don't re-browse directory A in Xee3.

(other parts of the bug-report still seem to keep happening -- but at least i 
managed to get the copy-destination back in the list)

Original comment by mcac...@gmail.com on 4 Aug 2013 at 8:36

[GoogleCodeExporter]

Thanks for all that information. I will try to reproduce it when I have some 
time.

(Unfortunately I just uploaded 3.1 to the App Store so any fix will probably 
not make it into that, unless it gets rejected again...)

Original comment by paracel...@gmail.com on 4 Aug 2013 at 8:39

[GoogleCodeExporter]

Hmm. I finally had a chance to look at this, but I can't reproduce it at all.

There is probably some further detail needed to trigger it. Are the folders on 
regular OS X HFS disks, or external or shared or something?

Also, you you try quitting Xee, then doing "defaults delete cx.c3.Xee3" (Note: 
This deletes all your settings and destination list entries!) and then trying 
to find the minimum number of steps needed to reproduce the problem from the 
first program start?

Original comment by paracel...@gmail.com on 19 Oct 2013 at 12:42