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 like this: /share_1 /share_2 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. Thanks.
database cleanup