Lucid Lynx and SlickEdit 14.0.2.2

[Scott H]

The code uses st_mtime. 

(edit... elaborating)   We call stat() to get file info in the form of a stat struct.  To get the last modified time, the code then uses gmtime() for UTC time, or localtime() for non-UTC time, passing the st_mtime member of the stat struct.

[shadowbane]

Hi,

I experienced this problem a couple of years ago and came to the conclusion that it was due to the servers time being set differently than the workstations time, even by a fraction of a second. I'm fairly sure my issue was caused because as SE saved the file the file's timestamp was set in to the future (relative to the workstation) by Samba on the server. 

If it is the same problem, perhaps a way to make it more robust would be to add an option that causes SE to reread the file's timestamp immediately after a save and use that as the most recent save time.  If this were done, I think it should be an option for two reasons

• it opens up a race condition where by another application could overwrite the file in between the save and stat
• it may negatively affect performance to re-stat a file after every save.

-shad

[Scott H]

This is actually the way it already works.  When SlickEdit saves a file, it immediately queries that file's last modified time stamp after saving it, then stores that time stamp with the buffer.  When we check for modified files, we query the last modified time stamp of a buffer's file and compare it with the previously stored time stamp (done directly after the save).  This eliminates the client machine's time as a potential problem, and it's one of the reasons we're having a difficult time figuring out what the problem is.

Do you think that race condition could realistically cause a problem?  I don't see any other way to remove the client machine's potential time difference from the process (which is necessary) and not have at least a microsecond potential race condition between the save and the stat() call.

[chuckj]

I experienced this problem a couple of years ago and came to the conclusion that it was due to the servers time being set differently than the workstations time, even by a fraction of a second. I'm fairly sure my issue was caused because as SE saved the file the file's timestamp was set in to the future (relative to the workstation) by Samba on the server. 

I had previously come to this conclusion, but have since decided this is not the problem.  My oldest server, which causes me no trouble, the clock is actually about 40 minutes slow.  My workstation and another server with which I had timestamp problems are both synchronized every five minutes using ntpdate.  I experimented with different time settings on the troublesome server and neither faster nor slower than the workstation (with ntpdate cron instruction removed so time stuck) made any difference.

[shadowbane]

The race condition could cause an issue if the sequence of events goes something like this:

SE completes writing to file
Samba writes out file contents and updates timestamp
SE closes file
SE reads timestamp
Samba offically closes file and again updates timestamp

Is it possible that something like this is happening?

Edit: I guess technically this would be a race condition in Samba, not the one in SE, but who's counting?

[Scott H]

That could be the case.  The problem however, if that's true, is that when we save a file I don't know how we could possibly get the "correct" last modified time stamp to test against later when we check for external file changes to reload.

It's interesting as well, colonel_coder ran a test for us (link) and the differences in time stamps he saw between the two machines are striking (some several seconds apart).  It was something beyond a simple race condition in that case, but it cleared up when he compiled the latest Samba.

[vivitron]

What if SE ran a diff in the background on the file before prompting the user to reload the file?

I know I've had cases unrelated to this one where the timestamp gets update and it prompts me to reload even though the file doesn't change.

I can see it being a potential performance issue, so I guess it becomes an option...

Just a thought...

[Scott H]

We already can do that!  Just go to the command line and type "set-var def_filetouch_checking", then hit enter, and set the value to 1.  You'll need to have backup history on (Tools > Options > File Options > Backup) for this to work properly.

[vivitron]

Didn't know that!

So... Shouldn't this band-aid the Samba problem for those who cannot upgrade?

Would test here, but no Linux boxes handy...

[colonel_coder]

The code uses st_mtime.

According to the man page, that is the correct field.

(edit... elaborating)   We call stat() to get file info in the form of a stat struct.  To get the last modified time, the code then uses gmtime() for UTC time, or localtime() for non-UTC time, passing the st_mtime member of the stat struct.

Why the conversion?  You should be able to compare two time_t values directly.  I just dug through the Linux headers on an Ubuntu 8.10 machine to find that the underlying type is "long int".  I would have to dig around some more to find a paragraph in a standard that guarantees that the underlying type is always a signed intrinsic type.

[Scott H]

band-aid the Samba problem

That's the problem exactly for this situation, it's a band aid.  This was originally implemented for a situation where files in open buffers are touched and their last modified timestamps are updated without the contents changing.  However, applying this solution to the Samba timestamp problem is hackish, since (as far as we know) touch isn't involved.  This could potentially be slow over a laggy network share, too.  But it is there and should be a perfectly good workaround to the samba timestamp problem, we just want to understand why its happening at all.