This is a good question. I ran into a few issues with gvfs mount points myself. I am not sure what Gnome does, but something about these mount points is off.
But I barely use a DE, thus I haven't looked into it. Maybe JackGruber has an idea.
Hi Tessus
I assume the Google Drive folder is fully integrating to Gnome, at list this seems checking the file configuration
and this is the file manager screen showing Google account as a folder.
But unfortunately I am not an Ubuntu 20.04 expert.
May be JackGruber can help me. Thanks.
Sorry, I can't help with this problem. Because I don't use Google Drive.
But I think /run/user/... is not the correct path, when I'm correct thant this is the folder for running processe.
@JackGruber Thanks for the advice, but I tried removing /run/user/ and other similar alternatives but no one worked. In the Gnome file manager app showing Google Drive as an integrated folder but does not work in Joplin to allocate the backup file, at least in the way I set up it.
Thanks @shbach for your suggestion, I will manually copy the biweekly backup file jex in Google Drive as a workaround, meanwhile exploring Rclone or ODrive as permanent solution. Thanks both.
Create a file gdrivepath.txt
in you gdrive folder.
Then enter the following command in a shell find / -iname "gdrivepath.txt"
The command should show where the file was found. I hope this can then be used as a path for the backup plugin.
Hi JackGruber
I have followed your suggest and I got this result:
eduardo$: sudo find / -iname "gdrivepath.txt"
[sudo] password for eduardo:
find: ‘/run/user/1000/doc’: Permission denied
find: ‘/run/user/1000/gvfs’: Permission denied
find: ‘/tmp/.mount_ThundeXszkfn’: Permission denied
find: ‘/tmp/.mount_JoplinG5OtKp’: Permission denied
Is there an issue relate to GDrive access permission? Is it possible to resolve it?
Thanks again.
No it's fine, the gvfs are realy special ...
You can try /gdrive:john.doe@gmail.com:/path/to/folder
, if this does not help, I can not help at the moment.
Thanks
@JackGruber, someone mentioned today that they've lost a few files after using the Backup plugin.
As I understand they've setup the plugin to backup to their desktop (eg ~/desktop
), and the plugin deleted unrelated files that were there. Do you think that's possible?
Here's part of the message:
I set the back to place a back up on my desktop. When opening Joplin an error message kept popping up that a task manager program I use [Task Manager Deluxe] need to be "unlinked". I thought this was odd, but I shut down TMD and Joplin and restarted Joplin. the back up placed the back up files on my desktop [these are also encrypted and zip by the backup process] However all kinds of files that were on my desktop are missing. Images, .mp4 video, document files etc. all gone.
@laurent Yes this is possible through the backup housekeeping.
It is mentioned in the documentation, but I will include a first time usage warning in the plugin for the backup path, the settings and update the documentation to make this clearer.
Thanks for clarifying. I wonder if it could be dangerous to clear a user-specified directory? Is it not possible to delete only the files that have been created by the plugin? Or perhaps to create a directory within that specified directory, and only clear that?
I do not want to say no
The problem is that the fIles and folders can have user definded prefixes
Yes, it's possible, but I decided against it. If I select /backups/Joplin
as backup path, all data will end up in /backups/Joplin/JoplinBackup
Of course, I could introduce another option. Path
and BackupFolder
Name ... I'll give it some thought.
@laurent Is it planned to introduce a File and Folder selector for Plugin options? So that these do not have to be text fields, which has already led to problems several times.
It's common for backup programs to do so actually. For example for Time Machine you specify a drive but they create a folder within it and only write to this.
Not planned but it could be added. In the settings it's already supported using type: SettingItemType.String, subType: 'file_path_and_args'
. Is that not working from plugins?
I've added support for the subType property, and ended up adding a directory selector too: https://github.com/laurent22/joplin/commit/fc095986b0e5d4690be32218d4723272c95d7c87 It will be in the next version.
@JackGruber Apologies if this has been asked before.
Both Joplin synch and your backup plugin can start at any time.
- what happens if a synch starts while a backup is in progress?
- what happens if a backup starts when a synch is in progress?
@RogerL This is no problem when both tasks running at the same time
It could just be that old data are still in the backup
The backup has exported the note and the sync delete/modify the note
Or newer data from sync not yet
The backup has exported the note and then the sync change the note or the note is created after the backup has exported the notebook
v1.1.0 (2022-07-11)
- Improved: The default setting for
Single JEX
is nowtrue
(Create only one JEX backup file) to prevent the loss of internal notelinks during a restore. Joplin Discourse: Lost all connections of my notes - Improved: Create a sub folder
JoplinBackup
in the configuredBackup path
(Only for new installations). - Improved: Use new Joplin DirectoryPath selector for path selection. Not supported in Joplin >= v2.9.1, non-compatible Joplin versions still use a text input field.
- Add: Backup all installed Joplin plugins (Only the jpl files, no plugin settings!)
Hello! Could anyone provide clarity on exactly what "Deactivate only if there is no other data in the 'Backup path'!" means?
This warning is shown under advanced settings:
I've been using the Backup plugin with this setting unchecked and it doesn't seem to negatively affect the backups, so I'm a bit perplexed what it is supposed to indicate.
Thanks in advance!
If the setting is enabled a folder JoplinBackup is created in the backup path. When you disable this setting and point backup path for example to your documents folder, it is posible that all data in the document folder would be deleted.