(2014-01-07) Trying Dropbox Synch For Private Wiki
Given my SimpleNote hassles, and my new Nexus Seven Tablet, and Phil Jones nagging me about jumping to the WikiFarm category in Picking A Wiki For Your Private Notebook, I want to take a shot at using Drop Box as a Data Synch system for my Private Wiki instead of SimpleNote.
Epistle got good reviews. It has been renamed "Draft" and is $2.50. Buy, install.
Discover Drop Box doesn't have a way to flag a whole folder for Data Synch for Off-Line use on Android - have to Favorite individual files. Install Drop Sync app. Hrm, seems like it makes a duplicate local folder that I have to create.... So make a local
Private Wiki folder, then it lets me pick my Drop Box
Private Wiki folder to synch to it.
- Hmm, but does Draft work with that local folder? It doesn't seem like it....
- Or maybe Draft does its own Drop Box synching/caching, and I don't need Drop Sync?
- Separate issue - it looks like Draft won't recognize a note file with no file extension, which is what my PikiPiki WikiEngine generates.
- Jan21 update: Draft developer responds: Draft keeps an internal database of files, not accessible by other apps. You can create a subfolder in you Dropbox account and store those files there, then tell Draft to syncronize with that folder. 2000 files should be problematic. And yes, Draft ignores files with no extension (it'd not be able to determine if those files are valid plain text files).
Try FetchNotes - no settings for folder location.
Same with MNotes. (
So most promising path forward at this point seems like Drafts, if I can convert my WikiEngine to use file extensions...
- most file managers seem to only search on file name, not contents
- ah, find A Grep app which does the searching. Then you can launch any editor against a match. Unfortunately, A Grep doesn't have a browse-all window, so if you're jumping back and forth between browsing and searching lists, it's rather inconvenient.
- then also discover it looks like Drop Sync set the mod-date on every file it syncs to the synch-time, rather than the underlying original-file-mod-time! Which makes browsing on the Android side (by date) pretty useless. Have emailed to ask about this....
- update: Just realized that only 492 files (out of 2478!) in the directory had ever been synched! Seems like it times out at some point even if it isn't done and is making progress. If you hit the Sync button again it finds more, but stops before finishing. And while it tells you how many files it moved, it doesn't tell you that it didn't finish.
Going to check if any real problems around that Drop Sync mod-date issue...
- the Drop Box folder I'd dumped my copy of files into had most-recent-change on Jan07.
- that first batch of files that was actually synched to Android was on Jan07, so all those files have that timestamp. The rest all have Jan15 timestamps since that's when I realized they hadn't been synched before.
- what if I take an original file that was created before Jan07, but last-modified between Jan07-15, and not synched until Jan15, and copy it from original-wiki-folder to Drop Box, will Drop Sync re-sync that file to Android? Or will it think the file is older than the Jan15 last-sync-date, and therefore ignore it?
z2012-04-18-GrandChallengeIdeaListswhich was created back then (prev last-mod Jul12), copied Jan07, modified (in orig folder) Jan09, synched Jan15. Take fresh copy from orig source, copy into Drop Box.
- launch Drop Sync. Yes, it caught that fresh file!
- conclusion: bad mod-dates are bad for browsing by mod-date on Android for now, but synching is safe.
- this inaccurate data becomes less important over time, but essentially moddate stays inaccurate within synched-batch.
- so copy over the other files modified since Jan07 into Drop Box.
- update: Drop Sync guys tell me Android 4.3 and later doesn't allow apps to set the lastmod timestamp. Dropsync tries but the system does nothing. I think I can live with this....
Edited: | Tweet this!