Re: Any better ideas for file sharing?

Thanks everyone for the responses! Let's see if I can clarify.

Threat Model - My wife's laptop is a mac air and it gets taken to lots 
of places outside of the house. My wife is also not a computer security 
expert and so the security hygiene on the box (e.g. installing updates, 
recognizing phishing mails, etc.) is pretty low. While I do intend to 
give her an encrypted file any half decent script kiddy could break that 
password pretty quickly and anyway I would expect my wife to keep MD 
running pretty much all the time. So the number of vectors by which an 
evil doer could extract useful information are many.

Approved vs Denied Approach - Edward's suggestion to use an 'approved 
list' approach (e.g. copy over known good as opposed to deleting known 
bad) makes a ton of sense. This was actually my first thought. I tried 
to approach it by exporting my Moneydance file as Moneydance XML (I 
couldn't read my .md file directly since I keep it encrypted on disk). 
The end result was 30.4 MB. And I realized that I didn't have the 
schema. Now, the XML does seem to be reasonably self describing but 
still I didn't know what I didn't know which means my solution would 
always be at risk of breaking anytime anything was changed in the 
schema. With the API approach I was using supported, documented, 
interfaces. So I had to tradeoff between something that is probably 
safer but more fragile against something that was probably less safe but 
more robust.

Does anyone actually know the schema for the moneydance XML file? I 
searched for it but didn't find anything,

         Thanks,

             Yaron


On 3/29/12 12:16 PM, Lewis G Rosenthal wrote:
> Sorry for the late follow-up!
>
> On 03/27/12 02:59 am, Thomas Garson thus wrote :
>> Lewis,
>>
>> Using OS/2 since 2.0, although I have, on the shelf, a 1.21 version 
>> of Acer branded Microsoft OS/2 whose 5-1/4" floppies have never been 
>> out of their sleeves.....
>>
> :-)
>> I used to run Moneydance at home on OS/2 without any hitches, however 
>> I only keep one OS/2 system active these days and it's a Warp 4.52 
>> box that has been going unmolested, with the exception of adding 
>> Netdrive and the Samba plugin, for close to 10 years.
>>
> Amazing how good stuff just "works," isn't it? The latest Java 1.6 b24 
> has been like a breath of fresh air for us, as has the latest Flash 11 
> beta drop.
>> My current Moneydance box is my hex core 64 bit AMD + Suse 12.1 hotrod.
>>
> As a Novell guy, SuSE is my distro of choice, too (not because anyone 
> affiliated with SuSE pre-Novell considers the current SuSE to be 
> "real," but because of my novell training being focused on SuSE).
>> As I stated previously, using group permissions to grant read only 
>> access by other users to the MD file should be fairly straight 
>> forward, but I need my wife to have write privileges as well. As 
>> things stand, when either of us tries to open MD for read/write when 
>> its file is in use by the other, the server does lock that "new" user 
>> out of the file. MDs reaction to this is to give its "I can't find my 
>> file" message, which confuses her. Fortunately, I've convinced her to 
>> not start punching keys in frustration when something doesn't work as 
>> expected, which used to be her first reaction, and which sometimes 
>> had very adverse effects.
>>
> You might try scripting a wrapper to copy the data file to a different 
> location when *you* exit MD. This secondary location would be the one 
> where your wife has access. It wouldn't even need to be read-only, as 
> you'd overwrite her changes, anyway. Just a thought.
>> I've no experience working directly with an SQL, at least not since 
>> the days when I wrote in DBII, or even further back when I had to 
>> write my own B-tree program for credit in a compsci course when I was 
>> on a 4.77 MHz PC and DOS 2.1, so I have to defer to those who have 
>> kept current with such things.
>>
> It's pretty much the same. The databases are bigger, but SQL is pretty 
> much SQL, and if you worked with DB2, you could work with MySQL or 
> sqlite. The nice thing about a concept like this, is that it could 
> de-couple the data storage from the application itself. Single users 
> could keep the data in a flat file (or sqlite), whereas multi-users 
> could choose an option best suited to their scale (MySQL or Postgres). 
> The program itself would read and write the same data.
>> I *think* it would be cool if MD could be set up to have a front and 
>> back end where the front end was basically the program interface as 
>> we see it and the back end, which would be the actual data 
>> "shuffler", could be running as a server, either locally or on a 
>> remote box over the network.
>>
> Exactly, and this is the beauty of client/server apps. In fact, a web 
> interface to MD could be a straightforward proposition, as well as 
> handheld or tablet interfaces customized for the particular platform, 
> as the engine would all be the same.
>> On the other hand, I have absolutely NO interest in any software that 
>> requires, or allows, my data to live in the "CLOUD". I want my data 
>> to physically (now there's a contradiction in terms) reside on a 
>> local server that I control and is inside MY firewall!
>>
> I could not agree more. See my "anti-cloud" rant on my blog: 
> http://www.2rosenthals.net/wordpress/why-the-concept-of-the-cloud-is-as-old-as-dirt-and-about-as-useful-139/ 
> .
>
> Cheers!!
>> On 03/26/2012 06:14 PM, Lewis G Rosenthal wrote:
>>> Hi, guys...
>>>
>>> PMFJI
>>>
>>> On 03/26/12 08:01 pm, Thomas Garson thus wrote :
>>>> On 03/26/2012 02:56 PM, Edward Reid wrote:
>>>>> Thomas Garson wrote:
>>>>>> ..........
>>>>>> Since Moneydance is not promoted as a multi-user product, we do not
>>>>>> attempt to access it at the same time, so I can't say how a usage
>>>>>> conflict would play out.
>>>>>
>>>>> I haven't actually tried it. However, MD is basically a
>>>>> document-oriented application. The "database" is a simple 
>>>>> line-oriented
>>>>> data file which is loaded and saved. (Obviously a far more complex
>>>>> structure is built internally when the file is loaded, but that's not
>>>>> relevant for sharing concerns.) So my guess is that the result of a
>>>>> usage conflict would be the usual in such cases: whoever saves last
>>>>> overwrites changes the other has made.
>>>>
>>> This, of course, assumes that the file is not locked by the first 
>>> system
>>> to access it. I've never tried accessing the same data file from two
>>> systems simultaneously (on any platform or filesystem).
>>>
>>> It would indeed be nice if MD could store its data in sqlite or MySQL
>>> (which would be a fairly simple upgrade from single user to multiuser).
>>> However, as a "personal" finance manager, I would suspect that this 
>>> is a
>>> bit beyond the scope of Sean's original intentions (though food for
>>> thought for some enterprising extension developer). :-)
>>>
>>> While I can see Yaron's approach as a clever system of scrubbing the
>>> file, I like your idea better, Edward. If *I* were to do it, I'd create
>>> a sparse MD data file on the "other" machine, and then export the
>>> account data as necessary from the "live" system. If it truly does only
>>> need to be read only, updating would be a simple mater of wiping the
>>> data file and re-importing every so often (and assuming the systems 
>>> were
>>> on the same LAN at regular (anticipated) times, this could be
>>> semi-authomated with cron (or, if on Windows, at).
>>>>
>>>> I suspect that you are correct, which is why I avoid using MD if there
>>>> is any chance my wife is doing her entries.
>>>>
>>>> It would be nice if the MD database were set up as a tree with record
>>>> locking of the leaves, but that would entail a major rewrite of its
>>>> database system and I'm OK with what it currently is for what I need
>>>> it for, and what it costs.
>>>>
>>>> For my business, I still use Peachtree Complete Accounting 12 for DOS,
>>>> as it uses a record locked C Tree, offers all of the features I need,
>>>> is very simple to use and is nearly bulletproof. It runs well on OS/2
>>>> Warp 4.52 or eCom Station, using Netdrive with the Samba Client Plugin
>>>> for server access.
>>>>
>>> Tom, it's *always* great to bump into another eCS user. :-)
>>>
>>> I'm presently running MD under OpenJDK6_b24 on eCS 1.2, and it works
>>> quite well. Our standard accounting app in the office (we are
>>> accountants, by the way) which we use for client write-up is a DOS app
>>> circa 1995 (Howell Client Accounting) which is a Btrieve app and runs
>>> beautifully under eCS, which is our standard desktop OS.
>>>
>>> I'd love to see (or even present) a Moneydance session at Warpstock one
>>> of these days. ;-)
>>>
>>> (Apologies to all for the bit of OT chat.)
>>>
>>> Cheers/2
>>>
>>
>> _______________________________________________
>> For Moneydance customer support, please visit 
>> http://help.infinitekind.com
>> [email protected]
>> http://moneydance.com/mailman/listinfo/moneydance-info
>>
>
_______________________________________________
For Moneydance customer support, please visit http://help.infinitekind.com
[email protected]
http://moneydance.com/mailman/listinfo/moneydance-info