Files remain locked locally on the OS/2 server

[dmik]

I've just noticed that working with file on an OS/2 share from a remote client sometimes leaves these files in a locked state on the server so that they cannot be opened locally for writing or deleted, even though the file is closed by the remote client. It takes some time for this lock to go away (tens seconds to minutes).

Steps to reproduce:

1. Connect to an OS/2 share with the Sharity client.
2. Open some file (with e.g. an editor), then close it.
3. Attempt to open the file for writing locally on the server -- you will get "The process cannot access the file because it is being used by another process (32)". An attempt to delete it gives "Sharing violation".

Note that you can perfectly save to the same file from the remote client or even delete it from there.

[dmik]

Note that I don't experience this behavior when I connect to the share from a normal Samba client (Linux, OS/2) but Herwig told me that he observes the very same behavior with it too, from time to time. Seeems that in case of Sharity reproducibility is 100% while it's more rare with the Samba client. Probably to a different locking strategy used by Sharity.

[dmik]

The problem exists in Samba 3.0.37-eCS 1.0.5-472 as well.

[Herwig Bauernfeind]

I see the behaviour dmik describes only from a Windows client, not from OS/2 client.

[Silvan Scherrer]

could any of you create a log with level 10?
can such a file be accessed from another client or is it also locked from there?

[dmik]

It's still the issue with the Sharity though I guess it's a documented behavior of this program. At least it contains something like "since we emulate the NFS volume we have to hold the file lock for some seconds after it has been closed bla-bla-bla...".

I don't use Sharity any longer and with the native OS X Lion client the problem doesn't exist. So unless Herwig confirms it is still present in his case, the defect may be closed.

[Silvan Scherrer]

it seems this was invalid, so closing it.