Skip to content
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

Do not try to create a Qiqqa.library DB when the directory already has an S3DB database file #144

Closed
GerHobbelt opened this issue Dec 22, 2019 · 2 comments
Labels
🐛bug Something isn't working 🦸‍♀️enhancement🦸‍♂️ New feature or request
Projects
Milestone

Comments

@GerHobbelt
Copy link
Collaborator

Happens while scanning through the directory set at startup. S3DB-containing directories are Internet/Intranet SYNC TARGET directories originally.

@GerHobbelt GerHobbelt added 🐛bug Something isn't working 🦸‍♀️enhancement🦸‍♂️ New feature or request labels Dec 22, 2019
@GerHobbelt GerHobbelt added this to the v82 milestone Dec 22, 2019
@GerHobbelt
Copy link
Collaborator Author

Related: #145

GerHobbelt added a commit to GerHobbelt/qiqqa-open-source that referenced this issue Dec 23, 2019
…truction for easier debugging/monitoring of Qiqqa behaviour.
GerHobbelt added a commit to GerHobbelt/qiqqa-open-source that referenced this issue Dec 23, 2019
…ext to an already existing S3DB file, delete it. We explicitly delete it to the RecycleBin so the user MAY recover the database file on the off-chance that this was the wrong choice.

- fix jimmejardine#144 :: Do not try to create a Qiqqa.library DB when the directory already has an S3DB database file
- some work done to find out how jimmejardine#142 came about.
- `WebLibraryDetails_WorkingWebLibraries_All`: make sure all 'Guest' libraries are added to the sync set: under very particular circumstances you CAN have multiple guest libraries, e.g. when manually recovering multiple Qiqqa libraries you extracted from your backups of previous qiqqa runs/releases.
- performance: speed up the sync metadata info collect action by NOT calculating the precise storage size of each library as that entails a HUGE I/O load as each library document's file system metadata would be queried for its filesize -- which is only used in the UI in an overview table and is deemed non-essential right now.
@GerHobbelt
Copy link
Collaborator Author

Fixed in referenced commit above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛bug Something isn't working 🦸‍♀️enhancement🦸‍♂️ New feature or request
Projects
v82release
  
Awaiting triage
Development

No branches or pull requests

1 participant