lock/unlock support

Home Forums PFM Developer Support lock/unlock support

Tagged: 

This topic contains 6 posts, has 3 voices, and was last updated by  Joe Lowe 2 years, 6 months.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts

  • cdarau
    Posts: 1

    Hello!

    How could I support lock/unlock functionality through PFM?

    From what I tested, the lock/unlock calls don’t reach the PfmFormatterDispatch interface and any write calls that superpose with the locked interval don’t reach the interface also.

    Thank you very much!

    Cristian


    Joe Lowe
    Posts: 101

    Byte range locking and share modes are handled by the kernel client, not passed on the the server.


    Sergiu Pol
    Posts: 2

    Hi Joe,

    We need also those operations to be handled by the server/user-mode code in order to manage lock conflicts generated by multiple sessions accessing the same remote file.

    Is this feature in the roadmap?

    10x!
    Sergiu.


    Joe Lowe
    Posts: 101

    There are currently no plans to forward byte range locking on to the server.


    Sergiu Pol
    Posts: 2

    Too bad :(
    This will seriously limit our plans as some of the collaboration features we will not be able to deliver.

    Currently PFM SDK is an incomplete implementation of the file system interface due to the lack of user-exposed locking.

    I suggest you to consider implementing locking also. Do you think this implementation requires too much effort on your side or are there strong technical reasons for not exposing lock/unlock to user-mode?


    Joe Lowe
    Posts: 101

    It is possible to build and support remote file systems, using PFM, that are compatible with the majoriy of user applications.

    Information about specific application compatibility issues will help me identify and prioritize future PFM changes. (I.E. “Our users are running … and when they … it …”)

    Server-managed byte range locking would come with server-managed sharing modes, open modes, and file handle referencing. These changes would significantly increase the complexity of PFM based file systems. The result would be significant increase in man-hour cost for you, with many new failure modes for you to work through. If you are sure you want this, don’t discount the option of just building off the Windows DDK and file system samples directly.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.