Steve_in_Texas wrote on Jun 22^nd, 2011 at 3:51pm:


Neither. The server reads files/directories when requested to by the client.

Can you send me the result of running "ls -laR" in the data directory?

Do you have the Windows machine/partition mapped using NFS and Samba?

That may well be the problem. It is not unlikely that some part of that is timing out.

Turn it off temporarily and see if the problem persists.

It is likely that reconfiguring your current setup, without drastic change, may remedy the immediate problem. How are you configuring and mounting the share?

Do you know about the /etc/fstab file?

If you wish people to have access to it from within Sesame (or let Sesame have access at all), it must be in a directory listed in the rootdirs or the CWD for the server.

You may be able to accomplish this leaving fstab as is, and using the ln ("link") command. This command lets you have a file or directory in two places at the same time.

If I specify:
ln -s /home/me/ADir/FileA /home/me/BDir

The FileA will appear in both Adir and in BDir. It is really the same singular actual file existing only in ADir. But it is "linked" in BDir as well.

Steven J. Vaughn-Nichols has written an article, "The Five Best Linux Desktop Distributions" that may be helpful:

http://www.zdnet.com/blog/open-source/the-five-best-desktop-linux-distributions/...

Realistically, the newer Linux desktop distributions are generally somewhat easier to work with than Windows XP/7 and performance is generally better.  They should be quite adequate for most Sesame applications.  As a practical matter, anyone running a system with so many users, transactions, etc. that they need a full-blown server operating system will probably already have IT people with advanced Linux skills who can handle the (non-GUI) server versions.

Steve_in_Texas wrote on Apr 2^nd, 2011 at 10:25pm:


Hi Steve! I just saw this bit.

This is where relative paths shine. If you use relative paths from your current working directory instead of absolute paths, you can move your applications at will and everything will fall into place.

For awhile I have been seeing problems that occasionally my Windows computers are ahead by about 6 hours (Central Time). I first noticed the problem on a machine with a 2004-era motherboard running XP and it persisted even when changing the CMOS battery. I recently replaced the motherboard in my main computer and noticed the same thing.  That now mainly runs Win 7 but is also set up for XP.  (Home edition in all cases.)

I was checking various tech postings assuming this was a Window flaw.

As described below, it turns out the problem has to do with dual-booting Linux.  As with that user, for each of my machines they are not set up with a bootloader--Linux was installed with no Windows drives present so it wouldn't make any changes to the Windows install.

This is from http://forums.techguy.org/windows-7/927637-win7-clock-keeps-changing.html.

If you boot more than one OS on a PC, it is a dual boot, at least as far as this issue is concerned, even if one of them resides on an external drive.

Both Linux and Windows read the RealTimeClock (RTC) when they are booted.

Pacific Time is GMT-7 at this time of year, so at 1 PM Pacific Daylight Time, it is 8 PM GMT.

Windows assumes the RTC is set to the local time. It does not make any adjustments for the Time Zone you've entered, it simply displays the RTC time and the Time Zone.

Linux assumes the RTC is set to Coordinated Universal Time (UTC) (Equivalent to GMT for this discussion). It reads the clock, then applies the Time Zone offset, and displays this adjusted time.

So, if the RTC is set to 1300 (1 PM), Windows reads it, converts to 12 hour format if needed, and displays 1 PM, and the Time Zone.
Linux reads the RTC, checks what Time Zone you've entered, adds the offset (-7 in this case), converts to 12 hour format if needed, and will display 6AM and the Time Zone.

The problem arises if Linux is set to check the time online and update the RTC. Online time sources provide the GMT time.
If Linux thinks the RTC is set to UTC, it does a direct compare, sees the RTC is off by 7 hours and corrects it, changing it to 2000 (8 PM).
Windows on the other hand, converts the Internet time to local before comparing.

Windows, when not connected to a Domain, checks the time online once a week.

Linux may be set to check the time much more frequently, and may check as soon as an internet connection is detected after boot, so may adjust the clock before the display is even initialized, so you may never see that the time is off when you boot into Linux, it's being synced online too fast.

It could also be that Linux is seeing the RTC as local time, but whatever service is checking the time online is not, so once an online check is done, the RTC is set wrong. Linux never looks at the RTC except at boot, so won't show that it has been changed.

So you have to tell Linux that the RTC is set to Local time, not UTC, so it will behave like Windows does.

I have been looking for a Windows utility that will automatically update the RTC every time I boot but so far I haven't found one.  There is a program w32tm.exe included in Windows but it only looks to a local time server on the LAN--you can't tell it to check any on-line time server.