SAMBA 2.0.6 / Module open.c Enhancment needed.

[John E. Malmberg]

Jeremy Allison wrote:

> This is something we intend to address for HEAD, but it will
> be left as-is in the 2.0.x branch.

> The reason behind it is the multiplexing of fd's into
> a reference counted structure due to the POSIX file
> locking problems. Under POSIX, locks are held *per
> process*, not per file descriptor (this is braindead IMHO).
>
> This means we need to ask for maximum permissible access
> on the first open, as we don't know if subsequent opens
> will require r/w access or not, even if the first open is
> r/o. So long as any client process has the file open the
> first fd is used.
>
> When the tdb lock database is used instead of the posix
> locks in HEAD this will be solved, but this is a subtle
> issue and not one we want to mess with for 2.0.x.
>
> Hope this helps,

Thank you for the response, it helps quite a bit.

I am not quite sure how "per process" and "per file descriptor" locking
differs.  The locking mechanism in OpenVMS is usually hidden away, and
somewhat automatic.  That is a specific record (not byte range) is locked
during a write to it when you use a high level language.

So it is not something that most programmers need to deal with on that
platform.

Normally if you want to do a lock, read, some processing, write, unlock
cycle you have to use the native file record locking.


In OpenVMS, the fcntl() function does implement file locking, so I had to
write a fcntl() like function using the native RMS (Record Management
System) locking functions.  The native locking was used so that it would
obey locks taken out by other applications, and they would also obey it.

In my implementation of fcntl(), all locks held by a file descriptor are
released when the file descriptor is closed.  This corresponds to the way
that the OpenVMS native file locking works.

Locks from a second file descriptor can be blocked by the locks on the first
file descriptor in a process, and the reverse.

RMS can also only lock records that exist in a file, so I have had to
compensate for that in some of the code.  Most of that is contained in the
locking_slow.c routine.  I had to change it so much that it is probably best
I rename that version to be locking_slow_vms.c.  The big hit there was that
unlink() in OpenVMS honors RMS locks.

Now that I understand what how the module works, I can implement a version
that uses the native in-memory locking mechanism.  This would eliminate the
orphan share locking files when the smbd process I am testing times out and
exits with out cleaning up.  It should be significantly faster, but so far,
this does not look to be a major performance hit.  (I may find out different
when I run it with the execution profiler active.)


As I write this, I realized something else:

Since RMS will not lock a file that is opened read-only, thus using my
implementation of fcntl() will always cause a file to be opened for write
access, thus modifying the dates.

So when windows explorer is searching for icons in the files, the
modification dates will be changed anyway.  :-(

It may be that an option such as in some database applications, where you
can specify that "readlock = nolock" would be a solution.  In this case
there would not be an issue if a write lock was specified.


It would not be good to hardcode in that assumption, but it may be usable as
either a per-share or a global option.

The other hack would be if I knew that the file had not really been
modified, and thus restore the modification date and backup date when the
file descriptor was closed, but I would rather not do that.

-John
wb8tyw at qsl.net