Loss of folder hierarchy in connections

Got a problem with Viscosity or need help? Ask here!

Root

User avatar
Posts: 13
Joined: Sun Oct 18, 2009 11:59 am

Post by Root » Fri Jul 22, 2011 4:13 pm
Using Viscosity 1.3.3 with OS X 10.6.8 (Snow Leopard) I observed the folder hierarchy is sometimes lost and not preserved (between machine restarts); for example, if I have one folder and two connections within that folder, I would [later] notice the two connections would be relocated out of the folder and appear at the same hierarchical level as the folder in which they were previously contained. I usually only notice this after my workstation has been power cycled and Viscosity manually started when its needed again, but I have not been able to reliably reproduce the symptoms. Each time I noticed the issue I would reorganize each VPN connection to ensure it was placed back into its respective folder.

More recently, after upgrading to Mac OS X 10.7 (Lion) GM I noticed the aforementioned folder appears to have disappeared or vanished, or at least it is no longer visible and the two connections it contained are now at the highest hierarchical level.

I'm looking to find out if anyone else has observed similar difficulty, or if anyone may know of a solution. I appreciate any help offered; thank you! :)

P.S., If any hardware or related system-specific details are needed, please let me know as I am more than happy to provide all necessary information that may further a more accurate diagnosis.

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Sat Jul 23, 2011 3:29 pm
Hi Root,

Viscosity stores the connection hierarchy and ordering information in its Preferences file (rather than using the file system itself). Do you have any software that could be interfering with this file? Is MobileMe preference syncing turned on, or anything like that? Anything in the Console log related to Viscosity (besides connection attempts)?

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

Root

User avatar
Posts: 13
Joined: Sun Oct 18, 2009 11:59 am

Post by Root » Sun Jul 24, 2011 8:37 am
James wrote:
Viscosity stores the connection hierarchy and ordering information in its Preferences file (rather than using the file system itself). Do you have any software that could be interfering with this file? Is MobileMe preference syncing turned on, or anything like that? Anything in the Console log related to Viscosity (besides connection attempts)?
I do have MobileMe synchronization enabled. I will monitor and search the console log to see if I can locate any additional details that may help. Thank you for your help. :)

Root

User avatar
Posts: 13
Joined: Sun Oct 18, 2009 11:59 am

Post by Root » Sun Jul 24, 2011 8:44 am
Root wrote:
I do have MobileMe synchronization enabled. I will monitor and search the console log to see if I can locate any additional details that may help. Thank you for your help. :)
I don't know how related this is, but I observed the following when starting Viscosity, letting it idle without connecting, and then quitting Viscosity; the last line appears interesting:
Code: Select all
2011-07-23 5:29:43.256 p.m. Viscosity: Loading Viscosity's Tap driver
2011-07-23 5:29:43.663 p.m. Viscosity: Loading Viscosity's Tun driver
2011-07-23 5:29:44.000 p.m. kernel: tap kernel extension version  <[email protected]>
2011-07-23 5:29:44.000 p.m. kernel: tun kernel extension version  <[email protected]>
2011-07-23 5:29:44.436 p.m. [0x0-0xe00e0].com.viscosityvpn.Viscosity: /Users/$username/Applications/Viscosity.app/Contents/Resources/Utilities.py:924: UninitializedDeallocWarning: leaking an uninitialized object of type NSPlaceholderString

Root

User avatar
Posts: 13
Joined: Sun Oct 18, 2009 11:59 am

Post by Root » Sun Jul 24, 2011 9:23 am
After further testing, the issue appears to be reproducible on-demand using the following steps:
  1. Start Viscosity, then access Preferences >> Connections
  2. Observe folder not present
  3. Create new folder, then rename it.
  4. Drag-and-drop two connections into the new folder
  5. Close Preferences window, then Quick Viscosity.
  6. Repeat steps 1 and 2.
While performing the above steps I did not observe any other log messages specific to Viscosity or OpenVPN.

Root

User avatar
Posts: 13
Joined: Sun Oct 18, 2009 11:59 am

Post by Root » Sun Jul 24, 2011 10:06 am
While examining the contents of ~/Library/Preferences/ I observed numerous lock files (like "*.plist.lockfile") -- most of which have a timestamp from the date of upgrading to Mac OS X Lion (10.7) -- with one of these lock files from Viscosity.

Here's a file size and timestamp snapshot while Viscosity is running:
Code: Select all
[$username@$host:~/Library/Preferences]$ ls -al@ | egrep -i viscosity
-rw-------   1 $username  staff             1147 Jul 23 18:14 com.viscosityvpn.Viscosity.plist
-rwxr-xr-x   1 $username  staff                0 Jul 21 16:57 com.viscosityvpn.Viscosity.plist.lockfile
Here's a subsequent snapshot after exporting connections, removing them and any folders, closing Preferences window, then quitting Viscosity:
Code: Select all
[$username@$host:~/Library/Preferences]$ ls -al@ | egrep -i viscosity
-rw-------   1 $username  staff             1062 Jul 23 18:23 com.viscosityvpn.Viscosity.plist
-rwxr-xr-x   1 $username  staff                0 Jul 21 16:57 com.viscosityvpn.Viscosity.plist.lockfile
I observed the lock file is not automatically removed. I proceeded by manually removing the lock file. When Viscosity is started again and its Preferences opened, a new lock file is created and "lsof" confirms Viscosity has it open, but after closing Preferences and quitting Viscosity, the lock file is still not automatically removed and "lsof" no longer shows the lock file as being open.

Root

User avatar
Posts: 13
Joined: Sun Oct 18, 2009 11:59 am

Post by Root » Sun Jul 24, 2011 10:12 am
O/S Version Detail:
Code: Select all
System Software Overview:
  System Version:	Mac OS X 10.7 (11A511)
  Kernel Version:	Darwin 11.0.0
  Secure Virtual Memory:	Enabled
  64-bit Kernel and Extensions:	Yes

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Tue Jul 26, 2011 5:24 pm
Hi Root,

Thanks for the detailed information - much appreciated. I can confirm we are seeing the same behaviour our end under 10.7 - leave it with me and I'll see if we can get a beta build up that resolves this.

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

James

User avatar
Posts: 2313
Joined: Thu Sep 04, 2008 9:27 pm

Post by James » Sat Jul 30, 2011 1:13 am
Just a heads up that we've got a beta version available that fixes this issue. Please see the following post to download it:
http://www.thesparklabs.com/forum/viewt ... p=134#p134

Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs

Root

User avatar
Posts: 13
Joined: Sun Oct 18, 2009 11:59 am

Post by Root » Sun Jul 31, 2011 8:51 am
James wrote:
Just a heads up that we've got a beta version available that fixes this issue. Please see the following post to download it:
http://www.thesparklabs.com/forum/viewt ... p=134#p134

Cheers,
James
I verified the new beta version, that of 1.3.4b1, has resolved the difficulty reported in this thread; after upgrading I am no longer able to reproduce the issue.

Thank you James! :D
10 posts Page 1 of 1