In order to describe this unappreciated behavior which we may also call a bug
(without knowing which participant of the scenario depicted in the following is
the buggy one) let's assume this situation:
Two different users have access to the so-called "Citrix Program Neighborhood"
(called PN from now on). The PN publishes MS Excel, among other apps. Both users
start their very personal instance of MS Excel on their own PC.
On the Samba server which is a member of a Windows 2000 domain reside two shares
There is a file myfile.xls both (!) in /share_1 as well as in /share_2. In other
words: there are two files which go by the same file name but are stored in two
different locations (shares or directories).
At the very moment when one of these two users will store an updated version of
his very own file, he will be presented with a dialog box telling that another
user has updated the file and whether he wants to overwrite these changes or not.
Resumée: In the depicted scenario Samba will mix up two files which go by the
same name but happen to reside in two different directories.
This problem occurs on a regular basis as soon as the conditions listed above
are given. We've seen this on Samba 2.0.7, 2.2.5, and 2.2.7.
For us this is a very critical bug.
I'm sorry but I forgot to mention that (of course) both of the users have to
open their own file "myfile.xls". As long as only one user opens the file
nothing bad happens (of course).
We have observed that normally every user has his own PID with respect to Samba.
Users who access via PN share the same PID! So it's possible that you have 20 or
more users sharing the same Samba process/session due only to the fact that
their Windows sessions run on the same Citrix Metaframe XP terminalserver.
I think that this behaviour could be part of the problem. And this behaviour
will become a problem by itself when one of these users runs into a problem
which freezes his Samba session: kill his session and you'll kill all sessions
from all users coming via the terminalserver...
Sorry, but the 2.2 is not under development any longer.
If you can reproduce this bug against the latest 3.0 release,
please reopen this bug and change the version in the report.