file locking mechanisms - dfs limitation or this is able to do it ?

Using windows 2003 r2.

Can file locking mechanisms be implemented ?

IT Staff wrote:
> Using windows 2003 r2.
>
> Can file locking mechanisms be implemented ?
>
>
I've asked Microsoft a hundred times, and they have never shown any will to do that.

I asked the same question at
http://social.technet.microsoft.com/...4-1a8dc2e08c7b

The only answer I've seen is http://www.peersoftware.com/solution...e_locking.aspx which is a 3rd party
software which costs about $1000 per server.

--
-- HAL07, Engineering Services, Norway

In message <uQNpoeh$> "IT Staff"
<> was claimed to have wrote:

>Using windows 2003 r2.
>
>Can file locking mechanisms be implemented ?
>

Not natively, although there are third party apps that claim to do the
job.

Distributed file locking is not part of the feature.
Even if you could, I suspect you would run into other problems. If people
need to write to the same data from two different locations I think Terminal
Services is a better solution,
Anthony
http://www.airdesk.com


"IT Staff" <> wrote in message
news:uQNpoeh$...
> Using windows 2003 r2.
>
> Can file locking mechanisms be implemented ?
>

In message <e#GpUph$> HAL07
<> was claimed to have wrote:

>IT Staff wrote:
>> Using windows 2003 r2.
>>
>> Can file locking mechanisms be implemented ?
>>
>>
>I've asked Microsoft a hundred times, and they have never shown any will to do that.

It's not so much a matter of will as being technical infeasible given
the goals of DFS-R.

One of the major goals of DFS&DFS-R is that members will continue to
function even if one or more members are off-line or unreachable for a
period of time. How would you propose file locking should work in such
a circumstance?

If multiple servers (each located in separate branch offices, for
example) aren't able to talk to each other, would you refuse any attempt
at locking files, thereby crippling an otherwise functional server that
happens to be disconnected? Do you cripple the entire DFS-R network, or
is there a hierarchy as to which servers remain functional and which are
crippled?

Or in this event do you simply allow non-synchronized locks, in which
case locking cannot be relied upon, and we're back to today's problem.

Dave Warren wrote:
> In message <e#GpUph$> HAL07
> <> was claimed to have wrote:
>
>> IT Staff wrote:
>>> Using windows 2003 r2.
>>>
>>> Can file locking mechanisms be implemented ?
>>>
>>>
>> I've asked Microsoft a hundred times, and they have never shown any will to do that.
>
> It's not so much a matter of will as being technical infeasible given
> the goals of DFS-R.
>
> One of the major goals of DFS&DFS-R is that members will continue to
> function even if one or more members are off-line or unreachable for a
> period of time. How would you propose file locking should work in such
> a circumstance?
>
> If multiple servers (each located in separate branch offices, for
> example) aren't able to talk to each other, would you refuse any attempt
> at locking files, thereby crippling an otherwise functional server that
> happens to be disconnected? Do you cripple the entire DFS-R network, or
> is there a hierarchy as to which servers remain functional and which are
> crippled?
>
> Or in this event do you simply allow non-synchronized locks, in which
> case locking cannot be relied upon, and we're back to today's problem.

I would like to enable/disable that option myself thank you. Microsoft should not be the one that chooses this for me. We have
redundant lines to all our branch offices.

In message <ujM7Ip7$> HAL07
<> was claimed to have wrote:

>Dave Warren wrote:
>> In message <e#GpUph$> HAL07
>> <> was claimed to have wrote:
>>
>>> IT Staff wrote:
>>>> Using windows 2003 r2.
>>>>
>>>> Can file locking mechanisms be implemented ?
>>>>
>>>>
>>> I've asked Microsoft a hundred times, and they have never shown any will to do that.
>>
>> It's not so much a matter of will as being technical infeasible given
>> the goals of DFS-R.
>>
>> One of the major goals of DFS&DFS-R is that members will continue to
>> function even if one or more members are off-line or unreachable for a
>> period of time. How would you propose file locking should work in such
>> a circumstance?
>>
>> If multiple servers (each located in separate branch offices, for
>> example) aren't able to talk to each other, would you refuse any attempt
>> at locking files, thereby crippling an otherwise functional server that
>> happens to be disconnected? Do you cripple the entire DFS-R network, or
>> is there a hierarchy as to which servers remain functional and which are
>> crippled?
>>
>> Or in this event do you simply allow non-synchronized locks, in which
>> case locking cannot be relied upon, and we're back to today's problem.
>
>I would like to enable/disable that option myself thank you. Microsoft should
>not be the one that chooses this for me. We have
>redundant lines to all our branch offices.

And when one file server does go offline? Hardware failure, heck even a
reboot, what then?

This is an incredibly difficult feature to implement reliably, and
unreliable feature would be worse then flat out saying it's not
supported since everything that can go wrong today would still go wrong
at least some of the time.

On Wed, 08 Jul 2009 16:48:23 -0700, Dave Warren <dave->
wrote:

>In message <ujM7Ip7$> HAL07
><> was claimed to have wrote:
>
>>Dave Warren wrote:
>>> In message <e#GpUph$> HAL07
>>> <> was claimed to have wrote:
>>>
>>>> IT Staff wrote:
>>>>> Using windows 2003 r2.
>>>>>
>>>>> Can file locking mechanisms be implemented ?
>>>>>
>>>>>
>>>> I've asked Microsoft a hundred times, and they have never shown any will to do that.
>>>
>>> It's not so much a matter of will as being technical infeasible given
>>> the goals of DFS-R.
>>>
>>> One of the major goals of DFS&DFS-R is that members will continue to
>>> function even if one or more members are off-line or unreachable for a
>>> period of time. How would you propose file locking should work in such
>>> a circumstance?
>>>
>>> If multiple servers (each located in separate branch offices, for
>>> example) aren't able to talk to each other, would you refuse any attempt
>>> at locking files, thereby crippling an otherwise functional server that
>>> happens to be disconnected? Do you cripple the entire DFS-R network, or
>>> is there a hierarchy as to which servers remain functional and which are
>>> crippled?
>>>
>>> Or in this event do you simply allow non-synchronized locks, in which
>>> case locking cannot be relied upon, and we're back to today's problem.
>>
>>I would like to enable/disable that option myself thank you. Microsoft should
>>not be the one that chooses this for me. We have
>>redundant lines to all our branch offices.
>
>And when one file server does go offline? Hardware failure, heck even a
>reboot, what then?
>
>This is an incredibly difficult feature to implement reliably, and
>unreliable feature would be worse then flat out saying it's not
>supported since everything that can go wrong today would still go wrong
>at least some of the time.

I'm not sue I agree. Having a flag that determines that "all copies are closed
and available" therefore it is a safe edit, i.e. no warning v a warning that
continuing to edit the file may result in data loss, may be better. In the
latter case I can continue knowing that there may be a conflicting edit. In the
former I am safe.

I see the difficulties but being warned of a potential conflict, even if not
100% reliable, must be better than never being warned.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.

In message <> DaveMills
<> was claimed to have wrote:

>I'm not sue I agree. Having a flag that determines that "all copies are closed
>and available" therefore it is a safe edit, i.e. no warning v a warning that
>continuing to edit the file may result in data loss, may be better. In the
>latter case I can continue knowing that there may be a conflicting edit. In the
>former I am safe.

Okay great, but if all servers aren't available or reachable, then what?
You still haven't addressed how you'd handle failure cases.

As far as I can see there are only two options:

1) Do you lie to users and omit the warning, telling users they're safe
to proceed with editing when they aren't?

2) Do you block all attempts to open a file for write and if so, from
all servers across the entire replication group just because one box
somewhere isn't reachable right now?

>I see the difficulties but being warned of a potential conflict, even if not
>100% reliable, must be better than never being warned.

Not at all, a false sense of security is *always* worse then knowing
your risks.

As it is right now, you *know* that you need to take precautions to
avoid conflicts and you can plan your infrastructure appropriately.

A half-way implementation would provide a nice false sense of safety,
and once users get used to being able to modify anything anywhere
without worrying about conflicts you'll have a minor outage, say a DFS-R
hub reboots while two VPs make changes to the same file on different
leaf nodes, not realizing that one of their changes was lost.

Well what can I say? I see your point, however I've already considered this. We have lost money on this due to work lost in
programs that do "database-like"-files.

We have people working on database files in programs that we didn't know used those. We have tried restricting it, but it's hard
for an over-worked IT department to detect what's going on in all the different departments. Also, some programs require these
files to retain in the same folders as other cad-related files, so it's not easy to just create a co-existing folder just for
these purposes. We have a large infrastructure which is concentrated through project numbers. When splitting up these it would
create problems for both our users and our archives and similar.

My suggestion: This will require an update to the DFS client included in Windows.
Windows DFS let us set a filter for known filetypes that require locking. A user will get a block if the branch-office is without
connection, or if the file is registered as opened by another server.
Shouldn't be too much work to make a constant check if the other members are available for all the Replication Group members.
Either by the servers or the client.

--
-- HAL07, Engineering Services, Norway