![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
BitTorrent fun... not!
Dec. 6th, 2013 10:10 pmThe subject is not BitTorrent per se, but BitTorrent Sync (hereinafter BTS), which is a nifty piece of software that lets one use BitTorrent technology to synchronize directories situated on different machines over a network. It provides a fairly straightforward way of creating off-machine backup copies of files.
I'll be twizzled if I can get a good handle on how it works, exactly.
To tell the story from the beginning (or at least closer to it), I'll note that I've begun to reacquaint myself with TiddlyWiki, which has been "rebooted" as something called TiddlyWiki5. The idea behind TiddlyWiki is that an entire functional wiki/web site is contained in a single HTML file, which means—inter alia—that one can create and edit content without the overhead of any kind of content management system. (Several years ago, in fact, my work web site was something I had put together in TiddlyWiki, so it's not as if I'm a stranger to the technology.) But what I find annoying is how there's no really convenient way of saving the result without a lot of manipulation, at least not in Google Chrome.
When saving a displayed web page, you see, most browsers insist on saving the copy on the local hard drive. This presents a difficulty if one wants to keep the TiddlyWiki file available on a web server.
So what I did yesterday is create a sort of loop, which starts by my saving a modified TiddlyWiki in Chrome. The result ends up in my Downloads folder, whereupon I then manually move the file to a directory (call it X) that BTS then synchronizes with my Raspberry Pi web server, so that the next time I load TiddlyWiki, the most recent file is loaded. I realize that I could make things incredibly easier by pointing my browser at directory X directly, but I wanted to see just how long it would take BTS to get around to synchronizing the file.
It's not a short wait, especially if BTS has been configured to keep a bunch of other directories synchronized.
Hmmm. What's more, this is happening while BTS reports "0 kB/s up; 0 kB/s down" (meaning no data is moving); meanwhile, the BTS running on my Raspberry Pi reports no problems.
P.S. BTW, moving the saved file to directory X is unavoidable, since a second attempt to save a TiddlyWiki file results in a file with "(1)" appended to the name, which means one cannot use the browser's reload function without doing some file deletion and renaming.
Or I could go back to using Firefox, which has an extenstion that deals with just this problem.
I'll be twizzled if I can get a good handle on how it works, exactly.
To tell the story from the beginning (or at least closer to it), I'll note that I've begun to reacquaint myself with TiddlyWiki, which has been "rebooted" as something called TiddlyWiki5. The idea behind TiddlyWiki is that an entire functional wiki/web site is contained in a single HTML file, which means—inter alia—that one can create and edit content without the overhead of any kind of content management system. (Several years ago, in fact, my work web site was something I had put together in TiddlyWiki, so it's not as if I'm a stranger to the technology.) But what I find annoying is how there's no really convenient way of saving the result without a lot of manipulation, at least not in Google Chrome.
When saving a displayed web page, you see, most browsers insist on saving the copy on the local hard drive. This presents a difficulty if one wants to keep the TiddlyWiki file available on a web server.
So what I did yesterday is create a sort of loop, which starts by my saving a modified TiddlyWiki in Chrome. The result ends up in my Downloads folder, whereupon I then manually move the file to a directory (call it X) that BTS then synchronizes with my Raspberry Pi web server, so that the next time I load TiddlyWiki, the most recent file is loaded. I realize that I could make things incredibly easier by pointing my browser at directory X directly, but I wanted to see just how long it would take BTS to get around to synchronizing the file.
It's not a short wait, especially if BTS has been configured to keep a bunch of other directories synchronized.
Hmmm. What's more, this is happening while BTS reports "0 kB/s up; 0 kB/s down" (meaning no data is moving); meanwhile, the BTS running on my Raspberry Pi reports no problems.
P.S. BTW, moving the saved file to directory X is unavoidable, since a second attempt to save a TiddlyWiki file results in a file with "(1)" appended to the name, which means one cannot use the browser's reload function without doing some file deletion and renaming.
Or I could go back to using Firefox, which has an extenstion that deals with just this problem.
