Latest git HEAD fails to run under linux #1184

Closed
edgimar opened this Issue Feb 12, 2013 · 2 comments

Comments

Projects
None yet
2 participants
@edgimar

edgimar commented Feb 12, 2013

When trying to run "sparkleshare start" after building and installing git rev 7f6e53c, I get the following traceback:

SparkleShare version: 1.1.0
Operating system: Unix Unix 3.2.0.37
System.IO.IOException: Win32 IO returned ERROR_ALREADY_EXISTS. Path:
at System.IO.File.Move (System.String sourceFileName, System.String destFileName) [0x00000] in :0
at SparkleShare.SparkleControllerBase.Initialize () [0x00000] in :0
at SparkleShare.Program.Main (System.String[] args) [0x00000] in :0

@edgimar

This comment has been minimized.

Show comment Hide comment
@edgimar

edgimar Feb 12, 2013

More details: the problem actually has to do with when a user's ~/.config/sparkleshare directory is still present from a previous version of sparkleshare. So, probably some logic to tell what version of sparkleshare is associated with the current config-directory would make sense. For example, when the config directory is created or updated, there could be a file within it which tracks the current state of the directory and/or sparkleshare revision. This can be used by future versions of sparkleshare to perform upgrades, etc.

It would also be good to have a more helpful error message pointing to the problem so that a user can manually remove the directory as a workaround for the present time.

edgimar commented Feb 12, 2013

More details: the problem actually has to do with when a user's ~/.config/sparkleshare directory is still present from a previous version of sparkleshare. So, probably some logic to tell what version of sparkleshare is associated with the current config-directory would make sense. For example, when the config directory is created or updated, there could be a file within it which tracks the current state of the directory and/or sparkleshare revision. This can be used by future versions of sparkleshare to perform upgrades, etc.

It would also be good to have a more helpful error message pointing to the problem so that a user can manually remove the directory as a workaround for the present time.

@hbons hbons closed this in 825707f Feb 12, 2013

@hbons

This comment has been minimized.

Show comment Hide comment
@hbons

hbons Feb 12, 2013

Owner

that commit should fix the issue.

Owner

hbons commented Feb 12, 2013

that commit should fix the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment