Thomas Anders wrote: > we're running Sharity 2.7 (built from source) on Solaris 8 02/02 > (Sparc) with the new NFS3 frontend which we highly appreciate. > > However, when cifsmount'ing a CIFS share from a Windows 98 > machine, Sharity misses a file that has been created lately > (after the cifsmount) on the Win98 machine, although smbclient > (Samba 2.2.4) shows it: > > - --- snip --- > foo# cifsmount //bar/solar-system /netdoc/www/server/data/Solar -r -Uguest > -Pmypass > foo# ls -l /netdoc/www/server/data/Solar/DATA/Juni_2002/*_19_* > -rw-rw-rw- 1 httpd httpd 1689062 Jun 19 23:49 > /netdoc/www/server/data/Solar/DATA/Juni_2002/Messfile_Mi_19_Jun_2002.txt > foo# ls -l /netdoc/www/server/data/Solar/DATA/Juni_2002/*_20_* > foo# smbclient //bar/solar-system mypass > smb: \> ls DATA/Juni_2002/*_19_* > Messfile_Mi_19_Jun_2002.txt A 1689062 Wed Jun 19 23:49:50 2002 > > 53925 blocks of size 131072. 48472 blocks available > smb: \> ls DATA/Juni_2002/*_20_* > Messfile_Do_20_Jun_2002.txt A 1243112 Thu Jun 20 17:26:26 2002 > > 53925 blocks of size 131072. 48472 blocks available > smb: \> exit > foo# > - --- snap --- > > If I cifsumount and cifsmount again, it accidentally fails: > > - --- snip --- > foo# cifsumount /netdoc/www/server/data/Solar > foo# cifsmount //bar/solar-system /netdoc/www/server/data/Solar -r -Uguest > -Pmypass > FRW: Internal error: IPC parameters > foo# > - --- snap ---
This one is interesting. If you can reproduce it, please get in contact with me at [EMAIL PROTECTED] > If I restart sharityd and do the cifsmount again, it successfully > mounts and shows the missing file: > > - --- snip --- > foo# ls -l /netdoc/www/server/data/Solar/DATA/Juni_2002/*_20_* > -rw-rw-rw- 1 httpd httpd 1258550 Jun 20 2002 > /netdoc/www/server/data/Solar/DATA/Juni_2002/Messfile_Do_20_Jun_2002.txt > foo# > - --- snap --- > > > This "missing file problem" also happened with Sharity 2.5 before, > so it's probably not related to the NFSv3 frontend (but the > "internal error" hasn't been seen before). The "missing file" problem is most likely a consequence of different semantics between Unix and Windows. On Unix, the modification date of a directory is changed when a file is created (or deleted or renamed). On Windows, the date stays unchanged. Unix applications (and sometimes even the kernel) base caching strategies on these semantics. If the modification date of a directory has not changed, cached contents can be used and there is no need to re-request the data. This means that the kernel is probably not even asking Sharity for the directory listing because the directory modification date has not changed. You can enable a "workaround" for this, turning off the kernel's cache all together. Sharity can change the modification date slightly on each read. The option which enables this feature in sharity.cfg is "changeMicrosecondFileTimes". Please note that turning off kernel caching for Sharity may have a negative impact on performance. Regards, Christian. -- Dipl.-Ing. Christian Starkjohann Objective Development mailto:[EMAIL PROTECTED] | http://www.obdev.at/ _______________________________________________ Sharity-talk mailing list [EMAIL PROTECTED] To unsubscribe see http://at.obdev.at/mailman/listinfo/sharity-talk
