Hi Folks,
TLDR; This post is important for you, IF your PC is always on, your browser is never restarted, your TW tabs are always open _and_ you use file-backups plugin V0.3.5 or earlier.
If _all_ of this is true for you, I highly recommend to go on reading if you don't want to loose some data!
-marioMore detailsFireFox has switched to a 4 week release cycle starting with FF 71. That means I have to test file-backups compatibility even more frequently than it was needed with the 6 week release cycle.I do test file-backups V0.3.5 and (V0.3.10 beta) with FF-stable, FF-developer edition, FF-nightly and Cliqz browser as soon as a new "stable" release will be activated.ANDMost of the time, some days prior to a new stable release. ... Just to be sure it still works.We need to update file-backups V0.3.5 plugin to V0.4.0 because it will contain a much better update behaviour.
At the moment, it's possible to loose data, if the AddOn is updated in the background, because of some oversights in early days V0.3.5.
I went to https://addons.mozilla.org/en-US/firefox/addon/file-backups/ but I don't actually see a download button there. What do I have to do on that page?
Oh! Now I see. Because I have it installed, the page shows a remove button with a garbage can icon.I think I am safe from the MARIOVID-4.0 virus because I always close my browser after using it. Is that correct?
Hi,Is version 4 available now?
Thanks for your work on this, mario.
Hi Folks,---- edit ----Version 0.4.0 is active at: https://addons.mozilla.org/en-US/firefox/addon/file-backups/---- /edit ----TLDR; This post is important for you, IF your PC is always on, your browser is never restarted, your TW tabs are always open _and_ you use file-backups plugin V0.3.5 or earlier.
If _all_ of this is true for you, I highly recommend to go on reading if you don't want to loose some data!
-marioMore detailsFireFox has switched to a 4 week release cycle starting with FF 71. That means I have to test file-backups compatibility even more frequently than it was needed with the 6 week release cycle.I do test file-backups V0.3.5 and (V0.3.10 beta) with FF-stable, FF-developer edition, FF-nightly and Cliqz browser as soon as a new "stable" release will be activated.ANDMost of the time, some days prior to a new stable release. ... Just to be sure it still works.We need to update file-backups V0.3.5 plugin to V0.4.0 because it will contain a much better update behaviour.
At the moment, it's possible to loose data, if the AddOn is updated in the background, because of some oversights in early days V0.3.5.
I could be wrong, but it appears to have lost the ability to set a root directory (e.g. C:, D:) as the download site.
It's unclear. Did you test saving using a different root ?
I was having trouble with one specific file. file-backups wanted to revert to a "save-as" dialog.
I finally got it to save by opening from file explorer. This gave the fb warning that there were two versions open. Then I could use the 2nd version and save. I'm thinking there was some background conflict with backups, but dunno. There is some issue, sometimes, which I know is incredibly vague.
On another issue, what path can you give fb to tell it to save in an absolute location?
Every path I try gives me the red outline.
There are many reasons a person might not want to save in the same directory as the original file.
For one thing, it means the "real" backup to a separate drive will be longer.
The working drive may have less capacity than the backup drive.
There is more overhead when running dropbox or syncthing.
On Tuesday, March 24, 2020 at 6:55:45 PM UTC+1, Mark S. wrote:I was having trouble with one specific file. file-backups wanted to revert to a "save-as" dialog.
Please check your browser option: "Always ask you where to save files" .. It should be _not_ checked.
After the save, a green banner opens, that tells you, you need to open the "newly" saved TW from the browser downloads folder.This is the location where file-backups can save to.
On another issue, what path can you give fb to tell it to save in an absolute location?That's not possible (because of browser security concerns) and it's not needed.
Every path I try gives me the red outline.The "red" dialogue is opened, if a TW file from the same location and name, is opened in 2 or more browser tabs.If 2 tabs edit the same file, this can lead to data loss. That's why there is the red banner.
There are many reasons a person might not want to save in the same directory as the original file.If you want to get a download dialogue everytime you save the wiki, you shouldn't use addOns at all. They are all designed to overwrite the existing file. That's the only reason, why we created them.
As far as I know, syncthing only syncs files (or even segments of files) that have been changed, which doesn't happen too often for the eg. D, E, F .. backups of file-backups. So only parts of the "original" and the backups actually go over the wire.
Hi Folks,---- edit ----Version 0.4.0 is active at: https://addons.mozilla.org/en-US/firefox/addon/file-backups/---- /edit ----TLDR; This post is important for you, IF your PC is always on, your browser is never restarted, your TW tabs are always open _and_ you use file-backups plugin V0.3.5 or earlier.
If _all_ of this is true for you, I highly recommend to go on reading if you don't want to loose some data!
-marioMore detailsFireFox has switched to a 4 week release cycle starting with FF 71. That means I have to test file-backups compatibility even more frequently than it was needed with the 6 week release cycle.I do test file-backups V0.3.5 and (V0.3.10 beta) with FF-stable, FF-developer edition, FF-nightly and Cliqz browser as soon as a new "stable" release will be activated.ANDMost of the time, some days prior to a new stable release. ... Just to be sure it still works.We need to update file-backups V0.3.5 plugin to V0.4.0 because it will contain a much better update behaviour.
At the moment, it's possible to loose data, if the AddOn is updated in the background, because of some oversights in early days V0.3.5.
On another issue, what path can you give fb to tell it to save in an absolute location?
That's not possible (because of browser security concerns) and it's not needed.Ok, I just realized that I can use ../.. to back out of the current directory. So that works. I don't need to send the backups to a different physical drive. Just one single point where they're not part of the weekly backup plan.
If I set the download directory to C:\, then I can set the backup directory to /users/mark/temp/twbackups ... the file is saved and the backup works!But if I set the download directory to D:\, and I set the backup directory to /temp/twbackups ... the file is saved, but the backup appears in a sub-directory of the target file, ignoring the specified backup path. This may be related to D: being a network drive, EXCEPT for the next weird thing.
If I set the download directory to D:\, and I set the backup directory to ../../temp/twbackups ... the file is saved, AND the backup appears in the designated directory.
So, if it was a permissions thing, I wouldn't expect that to work at all. The problem is, giving a path like ../../twbackups will save to the wrong place as soon as I go down one more directory level.
My thought was that it would be possible to have one window set up to save using the C: directory, and another windows (FF profile) set up to work with the D: directory. But the backup for the D: directory is uncooperative.
Thanks!
No, I'm not talking about the red dialogue. I'm talking about the download path directory. It gets outlined with red when you try to put an absolute directory in. But I see now that I can use ../.. to select some other directory, so I think it's going to work.
I wasn't talking about the original source file. I was talking about the files in twbackups. I want them to save somewhere else. I don't want them to save in the original files' directory or sub-directory because that will cause more maintenance headaches.
For instance, tiddlydesktop has a backup, and I just set it to send the backups to a directory on a drive that has lots of free space. I don't have to worry about remembering to delete the backup set before doing a physical backup.
On another issue, what path can you give fb to tell it to save in an absolute location? Every path I try gives me the red outline. There are many reasons a person might not want to save in the same directory as the original file. For one thing, it means the "real" backup to a separate drive will be longer. The working drive may have less capacity than the backup drive. There is more overhead when running dropbox or syncthing.
I'll have to test this. ... Is D:\ a windows network directory, or is it a "samba mount" to a unix-like system.
Yes, it is a network drive, or rather, a drive provided by Cryptomator (cryptomator creates a mount point for a collection of encrypted files). It's using Dokany, which I guess is similar to an enhanced webdav.After F12, there don't seem to be any errors related to saving. Just "Saving wiki with method autosave..." .I suppose they have some extra, extra safety that gets applied to network drives.
On Wednesday, March 25, 2020 at 4:27:22 AM UTC+1, Mark S. wrote:If I set the download directory to C:\, then I can set the backup directory to /users/mark/temp/twbackups ... the file is saved and the backup works!But if I set the download directory to D:\, and I set the backup directory to /temp/twbackups ... the file is saved, but the backup appears in a sub-directory of the target file, ignoring the specified backup path. This may be related to D: being a network drive, EXCEPT for the next weird thing.
As a rule, I try to keep my names unique ... in case I want to use (like at the moment) Polly, which needs distinct names.
The problem I had was that file-backup reverted to saving in a subdirectory of the current directory e.g. If the current directory was d:/data/wikis/notes and the backup path was /temp/twbackups, it would try to save to d:/data/wikis/notes/temp/twbackups
It worked fine with the C: drive. So assume there is something different about how the browser sees the D: drive.