[ANNOUNCEMENT] file-backups plugin will be updated at: March 20th - Browser restart required!

[PMario]

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 lose some data!

-mario

More details

FireFox 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.

AND

Most 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 lose data, if the AddOn is updated in the background, because of some oversights in early days V0.3.5.

Users, that use file-backups V0.3.10 beta [1] shouldn't run into the edge-case described below. See point 1) at What's New below.

File-Backups plugin is only active for tabs with a file:/// URL

Data-loss is possible if:

 - Your PC is always on _and_

 - Your browser is never closed / restarted _and_

 - Your TiddlyWiki tabs are open all the time _and_

 - Browser AddOns are updated automatically

 - Browser update in the background _may_ cause problems, but I don't have evidence about this atm.

It's edge-cases, but I know that there are some users, that use TWs that way. ...

• The easiest way to be safe for those users is to restart the browser, once the AddOn is updated
  
• Reloading a TW tab will do the same thing.
  

The problem at the moment is, that there is no visible indication, that a new AddOn version has been installed and activated. (Sorry about that!)

What's New in V0.4.0

 1) The plugin, if downloaded in the background, will only be installed and activated at browser restart

 2) Memory leak fixed for frequently saved huge TWs

 3) File-Backups AddOn only uses 1 icon - The browser "diamond" icon

 4) The "diamond" icon gets an "orange" !-indicator

         - The drop-down will show eg: new version ;)

 5) An "out of order" backup is created if a TiddlyWiki is saved for the first time

         - Only different names are detected.

         - If the AddOn is uninstalled and installed again the first save will create an "out of order" backup per new name.

 6) Backups are activated by default if the AddOn is installed

 7) Default number of backups was increased from 6 to 7

 8) The plugin Options setting site was updated

 9) AddOn should work for "FireFox for Android"

         - At least it does for me ;)

have fun!

mario

PS - If you USE it: Support it :)

[1] https://github.com/pmario/file-backups/releases/tag/V0.3.10-beta

[PMario]

HI,

@Jeremy or @Eric

Can you please pin this thread? Thx.

-m

[PMario]

bump

[Eric Shulman]

This topic has been pinned.

Unless otherwise requested, it will be unpinned on March 31 (two weeks from now).

That should give enough time for all interested parties to see the notice.

-e

[David Gifford]

Hi Mario

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?

On Wednesday, March 11, 2020 at 3:35:58 AM UTC-6, PMario wrote:

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!

-mario

More details

FireFox 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.

AND

Most 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.

[PMario]

On Thursday, March 19, 2020 at 5:10:11 AM UTC+1, David Gifford wrote:

...

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?

Hi, There should be a "Add to FireFox" button on the page. ... No download. It will be installed immediately.

If an older version is installed and the new version will be activated, it should automatically update. ... This behaviour can cause problems, which are described in the OP.

-mario

[David Gifford]

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?

Blessings,

[PMario]

On Thursday, March 19, 2020 at 2:39:48 PM UTC+1, David Gifford wrote:

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?

Yes,

As I wrote. It's an edge case, but it's annoying if someone "magically" looses data, if I want to push a new version.

An update should be seamless.

-m

[Jon]

Hi,

Is version 4 available now?

If I go to addons, it shows I have version 0.3.5 installed but also that there are 'no updates found'.

Do  I need to install by a different route?

Regards

Jon

[PMario]

On Thursday, March 19, 2020 at 9:26:40 PM UTC+1, Jon wrote:

Hi,

Is version 4 available now?

Nope, I will upload V0.4.0 on late Friday evening. Where we have the biggest chance for less users.

So you will probably have the new version on Saturday.

-mario

[Jon]

Ah, ok.

Thanks

Jon

[PMario]

Hi folks,

I did finish my last tests with FireFox 74 on Windows 10, ubuntu 18.04 and Android 9 on LG V20.

Everything seems to work as expected. ...

So the signed Version V0.4.0 will be uploaded soon. There will be a "signing" delay.

I'll post again, when it is online.

have fun!

mario

[PMario]

Hi Folks,

file-backups V0.4.0 it's active now.

Feedback can be sent here or at GitHub [1]

Latest Info: https://pmario.github.io/file-backups/news/latest and the

Homepage: https://pmario.github.io/file-backups/ got a new theme. ... Will probably change again in the future.

Video about the "What's New" and the new "Update info" is in the making.

have fun!

mario

[1] https://github.com/pmario/file-backups/issues/34

[Jon]

Thanks for your work on this, mario.

Regards

Jon

[PMario]

On Saturday, March 21, 2020 at 7:36:18 AM UTC+1, Jon wrote:

Thanks for your work on this, mario.

You are welcome!

It should be easier now, to make new updates and let users know.

have fun!

mario

[FrD]

Hi PMario,

Works fine for me (windows 10, firefox 74.0)

Thanks a lot !

[Mark S.]

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.

On Wednesday, March 11, 2020 at 2:35:58 AM UTC-7, PMario wrote:

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!

-mario

More details

FireFox 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.

AND

Most 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.

[PMario]

On Monday, March 23, 2020 at 4:32:16 PM UTC+1, Mark S. wrote:

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.

I did just test it with Windows10 and used drive E:\ as the default download location in the browser options.

I did load a TW from E:\test.html  and it works fine. I moved it to E:\TWs\test.html  and it also worked as expected.

So if you set a drive root as the browser downloads folder, you can access TW from every subfolder in your eg: E:\ drive.

If E:\ is for TWs only your browser vendors don't have a problem with security concerns ;) (What a stupid decision!)

have fun!

mario

[Mark S.]

It's unclear. Did you test saving using a different root ?

[PMario]

On Monday, March 23, 2020 at 5:38:02 PM UTC+1, Mark S. wrote:

It's unclear. Did you test saving using a different root ?

file-backups doesn't have a "root" setting. If you open a file in a subdirectory it will be automatically saved back to this directory.

The only directory setting in file-backups is the backup directory. ... It is always relative to the open TW file.

So if you use E:\ in the browser setting as your downloads directory  ... and

open E:\myWikis\test.html

there will be a

 - E:\myWikis\twBackups\test.html\test(2020-03-23T15-41-22-312Z).html ... The "new" "out of order" save.

 - E:\myWikis\twBackups\test.html\test(A).html .. test(B).html ... and so on. ... existing behaviour

This makes it possible to have several different test.html + their backups. ... It isn't best practice to use the same name for different wikis, but the AddOn could handle it well.

have fun!

mario

[Mark S.]

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.

Thanks!

[PMario]

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.

 

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.

This should only happen, if you open a file from eg: C:\Documents and want to save it back to c:\Documents

Since web-extensions can only directly save to C:\Downloads folder _and_ subfolders, the dialogue saves it there.

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.

 - Open the OS file explorer and move your TW into the "downloads" folder or a subdirectory

 - Double click - to open it

 - The save will automatically save it back to the subdirectory, if it was opened from there.

 

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.

You can use the browser default save mechanism.

 - Open browser "options" settings

 - scroll down to "Always ask you where to save files"

   - activate it

And the browser will start to ask you, where you want to save the file, everytime you change something.

I personally think this is annoying if the TW "autosave" option is active.

 

For one thing, it means the "real" backup to a separate drive will be longer.

Please have a closer look at the file-backups homepage and see, how the "Tower of Hanoi" backup mechanism works.

There is a maximum number of backup files, which will be created + rarely created "out of order" backups, if a new file name is identified.

I personally think, it gives us a nice balance between the number of backup files and

the "time-span" those backups can cover.

Also see: https://en.wikipedia.org/wiki/Backup_rotation_scheme#Tower_of_Hanoi

The working drive may have less capacity than the backup drive.

That's true but most OS systems have a possibility to transparently "compress" subdirectories on the OS level. Which uses about 350kByte for empty.html and 1.9MByte for a tiddlywik.com like TW.

 

There is more overhead when running dropbox or syncthing.

That's true but you don't need to sync the backup directory for dropbox, since it brings its own versioning system for the "original" file. There is no need to backup the backups. This will unnecessarily increase the used disk-space which has to be paid.

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.

Again - Have a look how the Tower of Hanoi mechanism works.

have fun!

mario

 

[Mark S.]

Ok, keep in mind that I'm talking about setting the download directory to a root directory, like C:\.

On Tuesday, March 24, 2020 at 12:59:21 PM UTC-7, PMario wrote:

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.

Right -- in fact you can't set a download directory to C:\ without changing this. So it has never been set to "Always ask..." in any of the tests that I have mentioned.

 

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.

I've not seen the green banner. Maybe it flashes by?

 

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.

 

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.

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.

 

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.

 

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.

 

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.

I only know that syncthing takes a long time to run. I think it's because it has to evaluate all those files and compare them with the other file system. So the more files it has to compare, the longer the process takes.

Thanks for your time. I think the problem with saving had something to do with the backups, so if it happens again I'll just clean out the twbackups directory for that file.

Thanks!

 

[TonyM]

Mark,

Perhaps you understand the following but for clarity.

Marios solution is one of the available ones, and takes a reduced dependencies approach buy working with the permissions that the browser gives to a tiddlywiki file. Your desire to customise and change folders is understandable but by its nature incompatible with such customisations.

For example I do not use Marios worthy solution personally, because with my computer use, I must be able chose to where I download things.

If you want to discuss other want to discuss other strategies just ask. I expect you are aware of the following; All from my Windows position;

• Timimi
• tw-receiver on php
• TiddlyServer
• TiddlyDesktop
• Bob/Bobeexe
• TWexe
  
• Others

Regards

Tony

[Mark S.]

Customize and change folders ... where did you get that?

[Mark S.]

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!

On Wednesday, March 11, 2020 at 2:35:58 AM UTC-7, PMario wrote:

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!

-mario

More details

FireFox 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.

AND

Most 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.

[PMario]

On Tuesday, March 24, 2020 at 10:07:53 PM UTC+1, Mark S. wrote:

...

On another issue, what path can you give fb to tell it to save in an absolute location?

OK I see. Absolute position is forbidden by the browser web-extension API.

 

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.

Important for those who don't use a root directory as the browser download dir.

As long as you stay inside the "browser downloads" directory "area" a ../twBackups as the "Backup directory" will work.

BUT as soon as you "leave" the "area" you will see this message in the browser dev Console (F12): save-wiki error: Error: "filename must not contain back-references"

I didn't think about this setting, that's why there is no user facing message atm. So if the setting is wrong there is no warning _and_ NO BACKUPS

I will create a bug-report at github for this.

-mario

[PMario]

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.

That's an interesting setup, I didn't think of and therefore didn't test it. ... So I will have to have a closer look, what's going on. 

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.

Can you hit the F12 key and open the dev-console and view the Console tab. There's probably the error message form the last post.

 

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.

Yea, that's expected, since the ../../xx goes up 2 levels. But there may be only 1 level left. So may be an error state.

 

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.

I'll have to test this. ... Is D:\ a windows network directory, or is it a "samba mount" to a unix-like system.

 

Thanks!

Thx for the feedback! ... I think we have gone past our "communication and naming problems" ;)

-mario

[PMario]

On Tuesday, March 24, 2020 at 10:07:53 PM UTC+1, Mark S. wrote:

 

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.

Ahh OK. your "download path directory" is my "Backups Directory" as labeled  in the config dropdown. ... My "download directory" is the one, where to save the open wiki, if you hit the TW save-wiki button.

-m

[PMario]

On Tuesday, March 24, 2020 at 10:07:53 PM UTC+1, Mark S. wrote:

...

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.

OK I see.

 

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.

Yea, TD creates an unlimited number of files. file-backups creates the number of files you allow it, to create (PLUS 1 for the "out of order" save). So the size should be deterministic.

------

I was thinking about the possibility to create something like a "Snapshot Save". Which will do a similar thing as the "out of order" backup, but with the possibility to configure a "snapshot-name". ... like: myWiki-(Version 1) ... where "Version 1" is the snapshot name and can be anything.

Following our discussion, I think there should be a different directory setting for the snapshots. Defaulting to twSnapshots

-mario

[TonyM]

Mark,

Perhaps I misread your paragraph,

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.

No probs, just trying to help.

Regards

Tony 

[TonyM]

Mario,

Snapshot saves are very useful when designing especialy if the restore to latest snapshot is clear and easy. Backups server more of an everyday guarantee, snapshots are a nice ad hoc option, perhaps just before saving a tiddler with a potential show stopper in it.

Love your work

Tony

[Mark S.]

On Wednesday, March 25, 2020 at 4:24:52 AM UTC-7, PMario wrote:

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.

Thanks!

[Mark S.]

Like you, I rotate which methods I use for saving. Sometimes because one method is superior to another, and sometimes just because.

The thing that bothers me about tiddlydesktop, and it isn't even an actual error, is that it appears in the icon tray just as a plain square icon. It just feels unofficial like that.

Thanks!

[PMario]

@Mark S.

On Thursday, March 26, 2020 at 4:07:24 AM UTC+1, Mark S. wrote:

...

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.

I did a test with a network connection to my ununtu-pc ... I did mount a shared folder as Z:\ to the windows pc and used it as browser download folder.

Everything worked as expected. ...

Do you have some "strange" / special characters in your filename or paths ?

-mario

[PMario]

On Wednesday, March 25, 2020 at 12:24:52 PM UTC+1, PMario wrote:

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.

@Mark .. I did read this again .. So what you want is:

You load a file D:\xx\test.html and you want the backups to be saved in D:\temp\twbackups ... Is that what you want? ... So the backups should be always saved relative to the root?

If yes, at the moment, there is a problem, if 2 wikis have the same name, but a different content. They would be saved in the same backups path. ...

-mario

[Mark S.]

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.

[PMario]

On Saturday, March 28, 2020 at 8:52:32 PM UTC+1, Mark S. wrote:

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.

ok

 

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's the logic, that I use to create to save backups. Backups are intended to be relative to the saved wiki, because that's the easiest way with the limited browser download API. I don't have to create checks for same name wikis in subdirectories. ... It just works.

If \temp\twbackups should be an absolute path, I need to create the backups directory structure in a new and different way.

I have to think about that. ... But it will definitely need a new AddOn version.

 

It worked fine with the C: drive. So assume there is something different about how the browser sees the D: drive.

No. "Mapped" network drives are transparent. So the app doesn't even know it's a network drive. 

have fun!

mario

[Mark S.]

But why then does it work with c:, and /temp/twbackups ?