Windows Vista Tips

Windows Vista Tips > Newsgroups > Windows Server > File Systems > file locking mechanisms - dfs limitation or this is able to do it ?

Reply
Thread Tools Display Modes

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

 
 
IT Staff
Guest
Posts: n/a

 
      07-06-2009

Using windows 2003 r2.

Can file locking mechanisms be implemented ?


 
Reply With Quote
 
 
 
 
HAL07
Guest
Posts: n/a

 
      07-06-2009

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
 
Reply With Quote
 
Dave Warren
Guest
Posts: n/a

 
      07-06-2009

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.
 
Reply With Quote
 
Anthony [MVP]
Guest
Posts: n/a

 
      07-07-2009

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 ?
>

 
Reply With Quote
 
Dave Warren
Guest
Posts: n/a

 
      07-07-2009

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.
 
Reply With Quote
 
HAL07
Guest
Posts: n/a

 
      07-08-2009

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.
 
Reply With Quote
 
Dave Warren
Guest
Posts: n/a

 
      07-08-2009
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.
 
Reply With Quote
 
DaveMills
Guest
Posts: n/a

 
      07-09-2009

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.
 
Reply With Quote
 
Dave Warren
Guest
Posts: n/a

 
      07-09-2009
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.
 
Reply With Quote
 
HAL07
Guest
Posts: n/a

 
      07-09-2009

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
 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
VPC 2007 file size limitation Jack Virtual PC 7 06-12-2007 05:02 PM
Windows (Vista) Mail and 2GB file limitation? news.microsoft.com Windows Vista Mail 7 02-05-2007 03:24 PM
Vista file security mechanisms Warren Windows Vista Administration 2 09-24-2006 01:17 PM
CAT file limitation. Joey Windows Update 0 11-08-2005 08:55 PM
File size limitation in DFS? Yaacov Klapisch File Systems 1 09-21-2005 06:19 PM



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59