…or at least, not if you don’t mind loosing all your file’s dates!
BeOS R5 can work with CIFS (SMB — Windows or SAMBA) networking shares by using the cifsmount commandline tool, and it can be very useful to get to your fileshares using this method. However, don’t be fooled! There are a number of problems with it, including:

• Connections timing out
• Tracker frequently crashing
• Slow speed

And the biggie…

• Dates get destroyed upon sight!

Whenever Tracker „sees“ a file, be it in a file selector or in a Tracker window, the file’s datestamp gets physically destroyed on the server, by setting it to the current day. This appears to occur in all Tracker/OT versions, and many other BeOS GUI apps. This does not appear to occur from the terminal, or other Unix POSIX programmes, so if you really must use CIFS, use the command line with it.
You do not even have to highlight a file to have the date removed — simply the act of it being drawn (even off-screen) in tracker causes the date to be lost forever.
The most shocking thing about this is that, not only is it not immediately obvious it is happening (you have to go out and into the directory again to see the damage), but it happens when the server is set to READ ONLY!
This problem seems to crop up with Linux and FreeBSD working as SAMBA servers, and Windows 95/98 using filesharing too.
If your projects attach any importance to file dates whatsoever (including automated backups), then don’t even think about touching a windows networking share unless you can be sure that Tracker, or indeed any other GUI-based BeOS app, will never come in contact with your shared volumes.
I am not aware of a solution to this problem, although feel free to contact me if anyone out there has any idea what is causing it. Tracker itself doesn’t appear to be the problem, but rather some kind of interaction between bugs in the server, bugs in the BeOS file system handling code, and the BeOS CIFS handling code.