Skip to content
Thank you James!
Loss of folder hierarchy in connections
Got a problem with Viscosity or need help? Ask here!
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.
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.
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
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
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
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 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
After further testing, the issue appears to be reproducible on-demand using the following steps:
- Start Viscosity, then access Preferences >> Connections
- Observe folder not present
- Create new folder, then rename it.
- Drag-and-drop two connections into the new folder
- Close Preferences window, then Quick Viscosity.
- Repeat steps 1 and 2.
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:
Here's a file size and timestamp snapshot while Viscosity is running:
Code: Select all
Here's a subsequent snapshot after exporting connections, removing them and any folders, closing Preferences window, then quitting Viscosity:
[$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
Code: Select all
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.[$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
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
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
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
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
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
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
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: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.
http://www.thesparklabs.com/forum/viewt ... p=134#p134
Cheers,
James
Thank you James!
10 posts
Page 1 of 1