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

Discussion in 'File Systems' started by IT Staff, Jul 6, 2009.

  1. IT Staff

    IT Staff Guest

    Using windows 2003 r2.

    Can file locking mechanisms be implemented ?
    IT Staff, Jul 6, 2009
    1. Advertisements

  2. IT Staff

    HAL07 Guest

    HAL07, Jul 6, 2009
    1. Advertisements

  3. IT Staff

    Dave Warren Guest

    In message <uQNpoeh$> "IT Staff"
    Not natively, although there are third party apps that claim to do the
    Dave Warren, Jul 6, 2009
  4. 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 [MVP], Jul 7, 2009
  5. IT Staff

    Dave Warren Guest

    In message <e#GpUph$> HAL07
    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

    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, Jul 7, 2009
  6. IT Staff

    HAL07 Guest

    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.
    HAL07, Jul 8, 2009
  7. IT Staff

    Dave Warren Guest

    In message <ujM7Ip7$> HAL07
    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.
    Dave Warren, Jul 9, 2009
  8. IT Staff

    DaveMills Guest

    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.
    DaveMills, Jul 9, 2009
  9. IT Staff

    Dave Warren Guest

    In message <> DaveMills
    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?
    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 Warren, Jul 9, 2009
  10. IT Staff

    HAL07 Guest

    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, Jul 9, 2009
  11. IT Staff

    DaveMills Guest

    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.
    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.
    DaveMills, Jul 11, 2009
  12. IT Staff

    Dave Warren Guest

    In message <> DaveMills
    How? How does DFS know whether or not anyone is editing a file *when
    one or more servers are unreachable*?
    Dave Warren, Jul 12, 2009
  13. IT Staff

    DaveMills Guest

    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
    DaveMills, Jul 12, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.