New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bibletime 2.11.1 not starting on windows 10 #119

Closed
antskarner opened this Issue Oct 3, 2017 · 11 comments

Comments

Projects
None yet
3 participants
@antskarner

antskarner commented Oct 3, 2017

I was happy to hear that new version of Bibletime is available, and I installed it immediately. But it is not starting. Wiht --debug option I got this: (BibleTime 2.11.1) WARNING: Cannot find ALLUSERSPROFILE\Application Data (BibleTime 2.11.1) FATAL: Error initializing directory cache! Please report this bug at https://github.com/bibletime/bibletime/issues Windows is 32 - bit version. Installed Bibletime as usual.

@gholmlund

This comment has been minimized.

Contributor

gholmlund commented Oct 3, 2017

I need some more information about your computer.

  1. Windows version

  2. In a command prompt window, type this and report the output:
    echo %ALLUSERSPROFILE%
    You should get "C:\ProgramData".

  3. In a command prompt window, type these commands.
    cd \ProgramData
    cd Application Data
    cd Sword
    Does this work without error?
    NOTE that "Application Data" and "Sword" are hidden directories. You won't see them, but you should be able to "cd" to them.

@antskarner

This comment has been minimized.

antskarner commented Oct 3, 2017

First command gives indeed "C:\ProgramData". But C:>cd ProgramData

C:\ProgramData>cd Application Data
The system cannot find the path specified.

`` What should I do now?

@antskarner

This comment has been minimized.

antskarner commented Oct 3, 2017

I forgot about my windows version. It is: Windows 10 Home version 10.0.15063 (the Creators update)

@gholmlund

This comment has been minimized.

Contributor

gholmlund commented Oct 3, 2017

The "Application Data" directory should have already been there. BibleTime will make the "Sword" dir, but not the "Application Data" dir. Just make that dir.
mkdir "Application Data"

@antskarner

This comment has been minimized.

antskarner commented Oct 4, 2017

Thank you for help. I created that directory, and now Bibletime works!

@antskarner antskarner closed this Oct 4, 2017

@jaakristioja

This comment has been minimized.

Member

jaakristioja commented Oct 4, 2017

@antskarner This is a workaround, but not a fix for the underlying problem.

This sound like this issue might cause problems for users as well. It were unreasonable to assume that most users are able to discover and apply such workarounds.

@gholmlund Maybe we could instead use QStandardPaths for path detection (on all platforms)?

@jaakristioja jaakristioja reopened this Oct 4, 2017

@gholmlund

This comment has been minimized.

Contributor

gholmlund commented Oct 4, 2017

On Windows, the environment variable ALLUSERSPROFILE has the directory that is to be used for programs to store data that is common to all users. On Windows XP this was "C:\Users\All Users". On all more recent versions this is "C\ProgramData". In both cases the application was expected to add "\Application Data" to that path and use this directory to store data common to all users. We put the Sword directory there. Numerous programs on my computer use that directory. Having it missing is somewhat like having /etc on linux missing. It is not something for a application program to fix. It also is not a normal directory. "Application Data" is a Windows "juncture" directory which is like a linux symbolic link. It actually points back to "C:\ProgramData" which is where the common data is actually stored.

I looked at QStandardPaths and none of its paths go to C:\ProgramData or C:\ProgramData\Application Data.

I don't believe there is anything more that we can do for this bug.

@antskarner

This comment has been minimized.

antskarner commented Oct 20, 2017

I recently made a fresh install on Windows 10 due the Fall Creators update. And when the os is booted up first time, I checked and found that the directory Application Data is missing on C:/ProgramData. So I made it again. Is it possible, if Bibletime starts first time after install, that it first cheks if that directory is present. If not, then makes it automatically? And should that direstory (C:/ProgramData/Application Data be on windows by default? Sorry if this sounds stupid because I have no coding skills, I just want to help to make this software better.

@jaakristioja

This comment has been minimized.

Member

jaakristioja commented Nov 2, 2017

@gholmlund Maybe we should use "AppData/Roaming" instead of "Application Data"? Searching the web, I found that "Application Data" in recent versions of Windows is just a junction point for "AppData/Roaming". Perhaps its just that junction point which was removed in newer versions of Windows, whereas the "AppData/Roaming" is still there?

@gholmlund

This comment has been minimized.

Contributor

gholmlund commented Nov 4, 2017

For a common sword directory we have been using the path %ALLUSERSPROFILE%\Application Data. This usage dates back to when we supported Windows XP. For windows versions newer than XP, the recommendation is to use the path %ALLUSERSPROFILE% without anything more. All windows versions newer than XP are supposed to have a hidden junction point called "Application Data" which points to C:\ProgramData, which is what %ALLUSERSPROFILE% contains. This is for backward compatibility if applications are still looking for the "Application Data". If this junction point is not there, the Windows installation has been damaged in some way.
Summary

  1. This is a Windows only issue
  2. It should be working for all users unless their system is damaged.
  3. Since we don't support XP any longer, we could eliminate the "Application Data" part of the path.
@jaakristioja

This comment has been minimized.

Member

jaakristioja commented Jan 17, 2018

@gholmlund I think it no longer makes any sense to support Windows Vista, XP and earlier. If this would help us clean up the code, we should do that. Otherwise, this should be probably resolved as WONTFIX or resolved: INVALID. I will trust your judgement on this, because I think I don't fully understand this issue.

PS: Would a proper workaround be to create that missing junction point, e.g. by using MKLINK or similar?

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