Byte range locks...

NTFSD
1

In the platform SDK for UnlockFileEx() it says:

If a process terminates with a portion of a file locked
or closes a file that has outstanding locks, the locks
are unlocked by the operating system. However, the time
it takes for the operating system to unlock these locks
depends upon available system resources. Therefore, it
is recommended that your process explicitly unlock all
files it has locked when it terminates. If this is not
done, access to these files may be denied if the operating
system has not yet unlocked them.

Can anyone explain what this really means (or in other
words, what is going on behind the scenes here.)

I’m extending the serve side of my redirector to support
byte range locking… and I’m wondering if it needs
to track the locks it has issued so it can release them
before closing the handle (if the client fails to do
so.)

If the above text mean “5 or 10 minutes” I might be
tempted not to bother. If it means “not until the
cache manager releases its reference in a couple of
days,” I probably can’t get away without doing it.

Thanks,

Joseph

2

As far as I know file systems release range locks synchronously during
IRP_MJ_CLEANUP processing. Releasing range locks just before closing handle
doesn’t make any difference.

Alexei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Joseph Galbraith
Sent: Tuesday, January 10, 2006 11:01 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Byte range locks…

In the platform SDK for UnlockFileEx() it says:

If a process terminates with a portion of a file locked
or closes a file that has outstanding locks, the locks
are unlocked by the operating system. However, the time
it takes for the operating system to unlock these locks
depends upon available system resources. Therefore, it
is recommended that your process explicitly unlock all
files it has locked when it terminates. If this is not
done, access to these files may be denied if the operating
system has not yet unlocked them.

Can anyone explain what this really means (or in other
words, what is going on behind the scenes here.)

I’m extending the serve side of my redirector to support
byte range locking… and I’m wondering if it needs
to track the locks it has issued so it can release them
before closing the handle (if the client fails to do
so.)

If the above text mean “5 or 10 minutes” I might be
tempted not to bother. If it means “not until the
cache manager releases its reference in a couple of
days,” I probably can’t get away without doing it.

Thanks,

Joseph

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@vmware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Alexei Jelvis wrote:

As far as I know file systems release range locks synchronously during
IRP_MJ_CLEANUP processing. Releasing range locks just before closing handle
doesn’t make any difference.

So I should report that snippet in the PSDK to the
PSDK team as bogus?

Thanks,

Joseph

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Joseph Galbraith
Sent: Tuesday, January 10, 2006 11:01 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Byte range locks…

In the platform SDK for UnlockFileEx() it says:

> If a process terminates with a portion of a file locked
> or closes a file that has outstanding locks, the locks
> are unlocked by the operating system. However, the time
> it takes for the operating system to unlock these locks
> depends upon available system resources. Therefore, it
> is recommended that your process explicitly unlock all
> files it has locked when it terminates. If this is not
> done, access to these files may be denied if the operating
> system has not yet unlocked them.

Can anyone explain what this really means (or in other
words, what is going on behind the scenes here.)

I’m extending the serve side of my redirector to support
byte range locking… and I’m wondering if it needs
to track the locks it has issued so it can release them
before closing the handle (if the client fails to do
so.)

If the above text mean “5 or 10 minutes” I might be
tempted not to bother. If it means “not until the
cache manager releases its reference in a couple of
days,” I probably can’t get away without doing it.

Thanks,

Joseph

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@vmware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Yes. We’ll try to figure out where that statement came from … as it
stands, I know of no justification for it. The filesystem is responsible
for synchronous unlocks in the cleanup path, as Alexei says.

Dan Lovinger
Microsoft File System Group
This posting is provided “AS IS” with no warranties, and confers no
Rights

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Galbraith
Sent: Tuesday, January 10, 2006 11:33 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Byte range locks…

Alexei Jelvis wrote:

As far as I know file systems release range locks synchronously during
IRP_MJ_CLEANUP processing. Releasing range locks just before closing
handle
doesn’t make any difference.

So I should report that snippet in the PSDK to the
PSDK team as bogus?

Thanks,

Joseph

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Joseph
Galbraith
Sent: Tuesday, January 10, 2006 11:01 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Byte range locks…

In the platform SDK for UnlockFileEx() it says:

> If a process terminates with a portion of a file locked
> or closes a file that has outstanding locks, the locks
> are unlocked by the operating system. However, the time
> it takes for the operating system to unlock these locks
> depends upon available system resources. Therefore, it
> is recommended that your process explicitly unlock all
> files it has locked when it terminates. If this is not
> done, access to these files may be denied if the operating
> system has not yet unlocked them.

Can anyone explain what this really means (or in other
words, what is going on behind the scenes here.)

I’m extending the serve side of my redirector to support
byte range locking… and I’m wondering if it needs
to track the locks it has issued so it can release them
before closing the handle (if the client fails to do
so.)

If the above text mean “5 or 10 minutes” I might be
tempted not to bother. If it means “not until the
cache manager releases its reference in a couple of
days,” I probably can’t get away without doing it.

Thanks,

Joseph

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@vmware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com