Sharing Database - Windows/XP

John Ralls jralls at ceridwen.us
Sat Apr 24 14:43:20 EDT 2010


On Apr 24, 2010, at 11:24 AM, Robert Heller wrote:

> At Sat, 24 Apr 2010 08:46:38 -0700 John Ralls <jralls at ceridwen.us> wrote:
> 
>> 
>> 
>> On Apr 24, 2010, at 8:39 AM, Robert Heller wrote:
>> 
>>> At Sat, 24 Apr 2010 07:15:23 -0700 John Ralls <jralls at ceridwen.us> wrote:
>>> 
>>>> 
>>>> 
>>>> On Apr 24, 2010, at 5:32 AM, Robert Heller wrote:
>>>> 
>>>>> At Fri, 23 Apr 2010 13:25:49 -0400 Phillip Richcreek <pwrichcreek at gmail.com> wrote:
>>>>> 
>>>>>> 
>>>>>> Geert,
>>>>>> 
>>>>>> I had just summarized and re-stated my question before seeing your
>>>>>> reply; so I did not (could not!) incorporate your reply in my
>>>>>> restatement. I think it does, however, go to the heart of the issue.
>>>>>> I'm no Windows expert, but I believe there are locking mechanisms
>>>>>> available for the ntfs file system that (I believe) Windows/XP uses in
>>>>>> the limited network environment that I am running.
>>>>> 
>>>>> 'NFS' (as mentioned below) is a *UNIX* network file system (sharing
>>>>> files across multiple *unix* computers on a network).
>>>> 
>>>> NFS is a platform-independent TCP/IP remote mount protocol. It has
>>>> been implemented on just about every operating system for which TCP/IP
>>>> has, including Microsoft Windows. True, it's commonly provided with
>>>> unix-like systems including Linux and the BSD, but I have used it on
>>>> Microsoft Windows (both DOS-based and NT), VAX VMS, TOPS-20,  VM/CMS,
>>>> OS/400, and PrimeOS.
>>> 
>>> Yes, this is all true.  NFS is *native* to most UNIX and UNIX-variants
>>> (eg is a basic part of all Linux kernels and the user-mode utilites
>>> related to NFS are a pretty standard part of any Linux distro and are
>>> commonly installed by default).
>>> 
>>> It is unlikely that a network of only Microsoft Windows machines would
>>> be using NFS.  NFS is not normally a part of the Microsoft Windows
>>> installation. 
>> 
>> So what?
>> 
>> You do realize that Geert said NTFS (which is the native, not shared, file system used by Microsoft's NT kernel), not NFS,
>> don't you?
> 
> Yes, but the original post he was responding to (top-posting no less,
> which seems to have caused the original message to be lost), was talking
> about NFS and the point of the .LCK + .LNK files link(2)ed together relates
> to NFS Locking issues.  The link(2)ed .LCK + .LNK files don't occur
> under MS-Windows both because the link(2) system service does not exist
> (in the same sense as under UNIX) and because NFS Locking issues are not
> an issue under MS-Windows because NFS is rarely used under MS-Windows.

Well, here's the bit that got chopped off:

On Fri, Apr 23, 2010 at 11:43 AM, Geert Janssens
<janssens-geert at telenet.be> wrote:
> On Wednesday 21 April 2010, Robert Heller wrote:
>> At Wed, 21 Apr 2010 12:42:32 -0700 (PDT) Phil Longstaff
> <plongstaff at rogers.com> wrote:
>>> I don't know if this is related to bug
>>> https://bugzilla.gnome.org/show_bug.cgi?id=352491 or not.
>> 
>> I just did some experiments on my Linux box.  GnuCash creates a single
>> file with *two* names (trivial to do under UNIX with a UNIX-flavored
>> file system -- just a matter of fun with the link(2) system service).
>> The .LCK and .LNK files refer to the *same* inode.  Does MS-Windows let
>> you do that?  And does the NETBIOS protocol support such magic?
>> 
> For windows this doesn't matter. The .LCK and .LNK functionality is explicitly
> disabled on Windows systems. That code was added to deal with nfs locking
> issues. Nfs is (assumed) not (to be) available on Windows, so the extra code
> is not compiled in that platform.
> 
> But it might indeed be relevant when accessing your data file from a linux box
> over netbios (via samba), when the code is enabled, while NETBIOS doesn't
> support such tricks.
> 
> Geert

I don't see what you're going on about. You're the one who brought up the whole link(2) irrelevance in the first place, and Geert told you that it was irrelevant because the code is disabled.

Regards,
John Ralls


More information about the gnucash-user mailing list