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

Using windows 2003 r2.

Can file locking mechanisms be implemented ?

HAL07

2009-07-06 09:15:37 UTC

Post by IT Staff
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/Forums/en-US/windowsserver2008r2branchoffice/thread/4715ab04-7702-43b0-a034-1a8dc2e08c7b

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

--
-- HAL07, Engineering Services, Norway

Dave Warren

2009-07-07 22:45:28 UTC

Post by IT Staff
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.

HAL07

2009-07-08 10:53:08 UTC

Post by IT Staff
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.

Dave Warren

2009-07-08 23:48:23 UTC

Post by IT Staff
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.

DaveMills

2009-07-09 05:26:08 UTC

Post by IT Staff
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.

Dave Warren

2009-07-09 08:01:28 UTC

Post by DaveMills
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?

Post by DaveMills
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.

HAL07

2009-07-09 08:43:39 UTC

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

DaveMills

2009-07-11 07:12:07 UTC

Okay great, but if all servers aren't available or reachable, then what?
You still haven't addressed how you'd handle failure cases.
1) Do you lie to users and omit the warning, telling users they're safe
to proceed with editing when they aren't?

No: if DFS can see all copies and know that nobody is editing the file anywhere
then no warning. In all other cases a warning.

Post by Dave Warren
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?

Never block just warn and allow the user to proceed just as Office does when the
file is locked except you should not be forced to do Read Only.

Overall this would introduce a warning when there is a risk and no warning when
there is no risk. If the user proceeds than they cannot argue that they did not
know. This is no worse that the current situation. However it gives the option
of declining the edit and making a copy.

It could even be implemented with an admin setting in the DFS console with
"Warn", "Block" or "Ignore" options so the Admin can choose the behaviour for
individual DFS folders.

In HAL07's case he may wish to block opens even if this is simply because one
server is unavailable. It could also be possible to get round a failed server
by for example disabling the Link which would remove the failed server from
consideration. The key point being that the Admin is acutely aware of what
copies are at risk and can take special measures. It all depends upon the
perception of the business risk. I can foresee cases when the loss arising form
a lost edit (especially undetected ones) could run to very large money.

Post by DaveMills
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.

--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.

Dave Warren

2009-07-12 06:45:30 UTC

Post by DaveMills

No: if DFS can see all copies and know that nobody is editing the file anywhere
then no warning. In all other cases a warning.

How? How does DFS know whether or not anyone is editing a file *when
one or more servers are unreachable*?

DaveMills

2009-07-12 07:52:15 UTC

Post by DaveMills

No: if DFS can see all copies and know that nobody is editing the file anywhere
then no warning. In all other cases a warning.

How? How does DFS know whether or not anyone is editing a file *when
one or more servers are unreachable*?

It doesn't but it can assume that some is editing and issue the warning. You are
looking to determine that somebody is actually editing the file before issuing a
message and I am looking just to prove they are NOT editing before NOT issuing
the warning (or block), i.e you are not allowed access unless the system can be
assured that the file is NOT being used.

There are also performance implications if this type of check were to be
implemented which would mean it should be off by default and only turned on for
individual shares by the administrator.

There are configurations where this type of locking would work perfectly, a
single site with two replicas for example. The current situation provides no
protection whereas this type of lock would provide protection for some
configurations and those it could not work well in would be no worse off than
now.

--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.

Dave Warren

2009-07-06 11:29:38 UTC

Post by IT Staff
Using windows 2003 r2.
Can file locking mechanisms be implemented ?

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

Anthony [MVP]

2009-07-07 12:19:50 UTC