Good morning, first of all thank you very much for the help and suggestions about how to hide shares to users that have no rights. Now I have another problem. The configuration is: 1) A linux server (RedHat 6.2), samba 2.0.7, a text editor (vi). 2) A Win95 PC. The user (USER) creates with vi a text file (version 1.0) in his home directory on the linux server. Then USER goes on the PC and tries to access (through samba) to his home directory. It works and with notepad USER can also open the text file created before with vi (version 1.0) Now USER modifies with vi the text file to obtain version 1.2 (for example). Now if USER goes again back to the Win95 PC and opens with notepad the text file he still sees version 1.0. Why? The file is changed and he still sees the first version of the file. Now, if USER selects the file and chooses "property" and opens the file with notepad he sees version 1.2. Again, why? Why he sees the new version of the file only after the "property" selection? For example, the F5 (refresh) action has not the same effect. The problem is mission critical for me because in a more complex case, vi is a unix software that creates text files that have to be read and elaborated in real time by another software running on Win95. Well, the software on Win95 doesn't read the last modified file created in unix. Can you help me? Lorenzo. ___________________________________________________ Se vuoi un indirizzo di posta elettronica gratuito, iscriviti a http://www.katamail.com
Lorenzo Corradini wrote:> > The user (USER) creates with vi a text file (version 1.0) in his home > directory on the linux server. Then USER goes on the PC and tries > to access (through samba) to his home directory. It works and with > notepad USER can also open the text file created before with vi (version 1.0) > Now USER modifies with vi the text file to obtain version 1.2 (for example). > Now if USER goes again back to the Win95 PC and opens with notepad the > text file he still sees version 1.0. Why?Oplocks. When you opened the file with notepad the first time, thw client requested and obtained an oplock from Samba. The file data was cached locally, and on the subsequent open you were shown the cached data. Using vi did not cause Samba to break the oplock, so the Windows client thought that the file was unchanged, and it was safe to show you the cached data.> The file is changed and he still > sees the first version of the file. Now, if USER selects the file and chooses > "property" and opens the file with notepad he sees version 1.2. Again, why?You broke the oplock, by forcing a read of data that was not already cached.> Why he sees the new version of the file only after the "property" selection? > For example, the F5 (refresh) action has not the same effect. > > The problem is mission critical for me because in a more complex case, vi > is a unix software that creates text files that have to be read and > elaborated in real time by another software running on Win95. Well, the > software on Win95 doesn't read the last modified file created in unix.Disable oplocks in Samba. You'll take a performance hit, but for what you're trying to do, you have no other option. It's also worth pointing out that if you're trying to interoperate between Unix and Windows applications like this, you may have problems with line end conventions. HTH Mike.
On 27 Oct 2000, Lorenzo Corradini wrote:> The user (USER) creates with vi a text file (version 1.0) in his home > directory on the linux server. Then USER goes on the PC and tries > to access (through samba) to his home directory. It works and with > notepad USER can also open the text file created before with vi (version 1.0) > Now USER modifies with vi the text file to obtain version 1.2 (for example). > Now if USER goes again back to the Win95 PC and opens with notepad the > text file he still sees version 1.0. Why?"Opportunistic Locking", aka "oplocks". The Windows machine has asked the Samba server if it is okay to cache the file locally, and Samba has given permission. Samba knows if someone else touches the file *via Samba*, and sends notification to the client that the cached version is out of date (an oplock break message). Unfortunately, Samba doesn't (normally) have a way of knowing if some other Unix process opens the file. If real time synchronization between the files as seen by Unix processes and as seen by Samba clients is important then you should turn off oplocks on the share in question (check the smb.conf man page). Alternatively, there is a facility called "kernel oplocks", whereby the Samba and the kernel collaborate and Samba *does* issue an oplock break if another Unix process opens a file. This is only available with a few Unix kernels which have had the appropriate hooks added. Recent IRIX 6.5.x ("feature stream" rather than "maintanence stream") is the only one I know of for sure, and I don't know whether Linux has them or not. Regards, -- Neil Hoggarth Departmental Computer Officer <neil.hoggarth@physiol.ox.ac.uk> Laboratory of Physiology http://www.physiol.ox.ac.uk/~njh/ University of Oxford, UK
Lorenzo Corradini wrote:> Now USER modifies with vi the text file to obtain version 1.2 (for example). > Now if USER goes again back to the Win95 PC and opens with notepad the > text file he still sees version 1.0.As other folks said, oplocks. One low-hassle way to ensure that "pc" files are always up to date is to pretend they're on a pc: run smbsh and edit the pathname "/smb/<serer name>/ <share name>/<file name>. Smbsh provided a local virtual file system that acesses all the smb servers in your workgroup via the smb protocol, and causes oplocks to be treated properly. --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | //www.oreilly.com/catalog/samba/author.html Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb@canada.sun.com