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

what's the .xopp~ file extension? #1498

Closed
andrewchenshx opened this issue Sep 25, 2019 · 10 comments
Closed

what's the .xopp~ file extension? #1498

andrewchenshx opened this issue Sep 25, 2019 · 10 comments

Comments

@andrewchenshx
Copy link

(Please complete the following information, and then delete this line)

Affects versions :

  • OS: Windows
  • Version of Xournal++ 1.0.12

Describe the bug
double click a .xopp file to open it with xournalpp, then a file with the extension .xopp~ is created in the same folder. even when the xournalpp is closed, the .xopp~ is still there.

@Technius Technius added the os::windows Operating System Microsoft Windows label Sep 25, 2019
@ysooqe
Copy link

ysooqe commented Sep 26, 2019

same thing happens for me on Arch Linux (with the latest xournalpp from the Community repo)

@Technius Technius removed the os::windows Operating System Microsoft Windows label Sep 27, 2019
@Technius
Copy link
Member

I cannot reproduce this when only opening files, but I see the file appearing when saving files. Are you certain this occurs when opening files?

The .xopp~ file is backup file that is generated before saving an open journal (in case there is an issue when saving, so the file does not become corrupted). The fact that the backup file is not deleted after a successful save is a bug, though. The fix is to delete the backup file after the save in src/control/jobs/SaveJob.cpp.

@Simon04090
Copy link

This is still an issue.

@Technius Technius added this to the v1.1.0 milestone Dec 1, 2020
@Technius Technius modified the milestones: v1.1.0, Future major version Jan 22, 2021
@ngoonee
Copy link

ngoonee commented Mar 25, 2021

This #2885 is supposed to fix this issue? Doesn't seem to for me though.

@BachoSeven
Copy link

@ngoonee I don't think it is supposed to, it seems to be about the timing of backup creation with certain file types.

@BachoSeven
Copy link

Following master, the issue where every succesful saving would not delete the .xopp~ seems to have disappeared. I looked around in the commits, but did not find anything related ¯_(ツ)_/¯

@ngoonee
Copy link

ngoonee commented Mar 27, 2021

@BachoSeven odd, I just built latest master (from AUR it gives me 1.0.15.r721.g28971748-1 for version) and am still having that behaviour when opening .xopp files and then saving them, a .xopp~ file will be left.

@BachoSeven
Copy link

Uhm I tried again and it is indeed still present...
It kind of happens only in certain situtations, i.e. not always reproducible

For instance, if you create a file and save it for the first time, the bug is not present
If you then open the file and save again, the bug is present;
but if you close it, open again, delete the .xopp~ and then save, it does not recreate the ~ file

@qstommyshu
Copy link

Yep, this is still an issue for me on Ubuntu as well.

Luca0208 added a commit to Luca0208/xournalpp that referenced this issue Oct 9, 2021
Fixes xournalpp#3399 Fixes xournalpp#1498
Also fixes that no backup file was created anymore after the first save
of a file
Luca0208 added a commit to Luca0208/xournalpp that referenced this issue Oct 11, 2021
Fixes xournalpp#3399 Fixes xournalpp#1498
Also fixes that no backup file was created anymore after the first save
of a file
Luca0208 added a commit to Luca0208/xournalpp that referenced this issue Oct 11, 2021
Fixes xournalpp#3399 Fixes xournalpp#1498
Also fixes that no backup file was created anymore after the first save
of a file
@Technius Technius modified the milestones: Future major version, v1.1.1 Feb 6, 2022
Technius pushed a commit that referenced this issue Feb 6, 2022
This is a combination of 4 commits.

* Fixes #3399 Fixes #1498
  Also fixes that no backup file was created anymore after the first save
  of a file
* Cleanup
* Create a backup file on any save where a file already exists
* Update comment
@Technius Technius linked a pull request Feb 6, 2022 that will close this issue
@Technius
Copy link
Member

Technius commented Feb 6, 2022

Fixed in #3445. Will appear in 1.1.1 release.

@Technius Technius closed this as completed Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants