[Samba] Samba and Adobe Illustrator locking issues.

[Jeremy Allison]

On Mon, Jan 04, 2021 at 11:44:34PM -0800, Yogesh Kulkarni via samba-technical wrote:
>Hi,
>
> I have a strange case of lost updates with the Adobe Illustrator .ai files
>and
> samba server. I am writing this to validate my findings and ask if there
>is a
> known workaround to this issue.
> The samba version is 4.9.5 running on debian 10.x and clients are multiple
>MacOS
> versions.
>
> The customer reports an issue with multiple users working on .ai files.
>Here is
> the use case -
> User A - edits a file test.ai and saves the changes
> User B - opens the file and expects the changes to be present in the file.
> (almost immediately). So, they are not co-editing, but opening the files in
> quick succession.
> However, it turns out that User B cannot see the changes.
>
> Observations -
> On the client side, finder shows that one or more '.tmp' files are getting
> created when a user saves the .ai file. These .tmp files sometimes go away
>and
> other times stay till the user disconnects the share.
> Network caps indicate that the application does **not** use oplocks/leases.
>
> Hypothesis -
> UserA writes to the test.ai file and the application writes the updates to
>.tmp file.
> UserB has their finder open and obtains a lock on the .tmp file. Now, when
>UserA
> tries to rename the file from xyz.tmp to the test.ai file, since UserB has
>a lock
> this operation does not go through. In a way this is a deadlock as UserB
>will try
> to open the file to see the updated content, but it cannot do so, since it
>locks
> the resource and that prevents UserA from updating the content.
>
> Experimentation and results
> In order to verify this hypothesis and cater to the customer case, we
>experimented
> renaming the locking.tdb without restarting the daemon. This addresses the
>issue.
> Obviously, if we take out the locking component, there is always potential
>risk
> of simultaneous users overwriting each others data.
> I experimented with the locking = No, and checked with smbstatus, but with
>preview
> enabled, I see that a .pdf file shows as locked in output of smbstatus
>command.
> So I conclude that the samba process internally acquires the advisory lock
>on
> the file.
>
> Is there a more elegant way of turning off the locking than just renaming
>the
> locking.tdb ? We do not use clustered mode and will probably never support
>that in
> the product.
> Are there any such cases seen in the field in your knowledge ?
> Is there a tried and tested solution to this issue ?

You can always set "locking = no" but that turns off only the
byte range locking not the share mode locks.

I'd recommend you log a bug and upload the wireshark traces
so this can be investigated. Might be an issue with the
MacOSX client but it's hard to tell from the description.