locked
DFS File Locking RRS feed

  • Question

  • Good Day, We have an issue, where users at one site accessing a file. Then other users at the datacenter accessing the same file. Each one does their work and then the saves the file. Neither one knows that the file is opened by the other user. How can we ensure the file is locked and placed in read-only mode as if they were opening the file from the same location.

    Does Server 2008 R2 support file locking?

    What options do I have?

    Thank you!
    Paul


    Duramaxster

    Tuesday, December 10, 2013 4:42 PM

Answers

All replies

  • Good Day, We have an issue, where users at one site accessing a file. Then other users at the datacenter accessing the same file. Each one does their work and then the saves the file. Neither one knows that the file is opened by the other user. How can we ensure the file is locked and placed in read-only mode as if they were opening the file from the same location.

    Does Server 2008 R2 support file locking?

    What options do I have?

    You don't have any options. It's application user deals with who decides file it opens can be shared for reading, writing, deletion or no shared actions @ all.

    In theory you can hire somebody who will write you a custom filer or mini-filter hooking particular application file I/O and patching open attributes to the ones you want. But on practice it would be 1) expensive and 2) overkill as I'm pretty sure your app of choice is not broken and knows what it's doing: opens files in a proper sharing mode. See:

    http://www.osronline.com/article.cfm?article=17

    Q7 How do I deal with file-sharing issues in my filter driver? 

    File sharing semantics are often an unforeseen complication for file system filter drivers. This is because filter drivers often wish to create separate handles against the file so that they can perform operations against the file, independent of the application-initiated request to access the file. For example, an on-access virus scanner might wish to read an executable in order to scan it - this requires read access, while execution does not require read access. 

    Regardless of the reason, the "problem" that many file system filter drivers have is that when they attempt to open the file, they must be able to handle file-sharing issues. Specifically, if another application opens the file, it might specify exclusive access to the file. It may be critical to the function of the filter driver that it be allowed to access the file even though normal file sharing semantics would reject the access request. There are a few techniques that a file system filter driver can use to "circumvent" file sharing semantics: 

    - The filter driver can implement the file sharing internally in the filter driver; in this case it always asked the underlying FSD for full-sharing of the file and enforces the sharing at its level; or
    - The filter driver can use memory mapping to access the file; or
    - The filter driver can build IRPs and access the file directly; 

    While it is possible for a file system filter driver to implement the file sharing semantics internally within the file system filter driver; it is often the most difficult situation because of the complex nature of the sharing semantics. To properly track sharing state, the file system must track (on a per-file basis) the current sharing state of the file. Typically, this is done to mirror the behavior of the FAT file system example in the IFS Kit. Thus, when the file is opened, the sharing is managed by using IoCheckShareAccess and/or IoUpdateShareAccess. When the user closes the file (as specified by the IRP_MJ_CLEANUP operation) the filter removes the share access (IoRemoveShareAccess) so that subsequent operations to access the file succeed. 

    In computing share access there are two important elements: 

    - The access requested for the specific open instance of the file, which is recorded in the file object; and
    - The share access allowed by existing applications using the file. 

    The actual implementation of this can be somewhat complicated, which is why it is generally best to allow the FSD to manage this, or to use the I/O Manager routines. 

    A second approach is to keep in mind that the section object for a file can always be used to memory map the file. 

    A third approach is to build read and write IRPs directly. Because security checks (including whether or not a read/write is allowed) are done in the I/O Manager before the operation is passed to the file system. Thus, the filter driver can perform I/O operations against a file object that was not opened for read or write access, simply by constructing read and write IRPs within the filter driver itself.


    StarWind iSCSI SAN & NAS

    Tuesday, December 10, 2013 10:03 PM
  • Hi Paul,

    This is an unfortunate "missing" feature when it comes to DFS. I'm not aware of any version of DFS that has this functionality. This article would probably be an interesting read: http://blogs.technet.com/b/askds/archive/2009/02/20/understanding-the-lack-of-distributed-file-locking-in-dfsr.aspx 

    I can't say if it's any good or not but I've heard of the following product that attempts to fill this gap: http://www.peersoftware.com/products/file-collaboration/peerlock.html

    The other option would be to try and segregate the data within DFS into structures based on department and then location so teams in different locations know what's theirs and when they need to pick up the phone to the other office. Even if they don't pick up the phone, at least this will limit the amount of conflicts.

    I hope this helps,
    Mark

    • Marked as answer by Mandy Ye Tuesday, December 17, 2013 9:54 AM
    Tuesday, December 10, 2013 10:29 PM