| Index > Scribe > backup for inscribe? | |
|---|---|
| Author/Date | backup for inscribe? |
| spazma 27/02/2007 5:25am | hi. my name is spazma
im new here ;) and my question: why inscribe not have a backup option? p.s. today i buy inscribe :) i like it!!! |
| fret 28/02/2007 2:43am | Well I havn't had time for that feature yet. But there is a number of export functions that you could use.
Also this year I'll be moving to a maildir format mail storage which you can back up with a standard file backup tool. Hence I'm not really worried about the situation right now. |
| Mike 03/03/2007 3:35pm | Well, based on what little bit I know about maildir (e.g., Wikipedia article), I suppose I may give up on future versions of Scribe. I had been looking forward to ver 2 for 5+ years.
Some of the problems I see with Maildir are: specification never updated (author doesn't give a hoot) not compatible with Windows w/o modification (i.e., colons in file name) one file for each message -- you can't be serious! maybe on OSes that don't use clusters, but if I wanted messages stored in separate files, I could run an email reader with an even smaller footprint than Scribe Was there any more discussion on this than the 2 comments I saw back in October? I will probably, out of curiosity, try out the new ver (assuming it works on Windows 98), but it's unlikely I will adopt a one message per file program. |
| fret 05/03/2007 10:05am | Well I won't limit myself to some outdated spec. If I have to I'll adjust things to make it work within the application.
I'm not sure that in the face of consistantly increasing available storage that trying to save a few bytes here and there is really worth the extra effort. Also newer file systems have less wasted space. Sure a FAT or FAT32 system might be potentially very wasteful but newer systems like NTFS and the Mac filesystem or Ext2/Ext3/Reiser are much better. So the important metrics are: - time to load - time to insert/delete - space used vs wasted space (mail2 is great till you start deleting stuff) - searching - moving files/attachments - multi-threaded access I have to weigh up all these things. And native file systems have the benift of speed and reliability over mail2. I'm not a file system developer and it shows in the design of the mail2 format. It's frankly crap. No indexing, easily corrupted and fragile. I want to move beyond it and native filesystems are the easy direction to head down. Otherwise a known filesystem inside a file would be ok if it grew/shrank in a reasonable way. And I don't have to write it or support it / fix the bugs. I've tried sqlite and it's ok, its fast for read but slow to write to with the number of indexes I wanted. Anyway I hope this gives you an idea of what I'm up against as a developer and the reasons behind the directions I want to take. |
| Steven Hodson 28/03/2007 4:12am | In the meantime is there currently a good way to safely backup InScribe data and then restore it to a fresh install?
I am facing a reinstall of windows in the near future so I am hoping for a workable suggestion. |
| fret 28/03/2007 5:14am | As long as the directory holding the folders.mail2 and options files (scribe.r or ScribeOptions.xml) survives then you will be fine. All the data and options are stored in the same folder as the executable, makes for easy backup / portability. I.e. you can just copy the whole folder to a USB key drive and off you go, mobile InScribe. |
| Reply | |