What non-editor updates file timestamps?

MMacD

MMacD

I keep getting a message while editing (under XP) that something has updated the copy of the file on my (non-ZFS) FreeBSD machine and would I like to reload it. The file content is unchanged, so I presume it's the timestamp that's being bumped. It's driving me mad trying to find it. Is there a dayfile that records, or could record if I knew how to set it up, all such unasked-for actions as those file "updates".

I should mention that this is not a case of not-quite-sync'd time: I set my XP's clock five minutes ahead of the FreeBSD machine's. Which argues for it being a real content change, but if that's what's happening I'm not seeing it.
 
In general, the mtime of a file is only changed when something writes to it. In general, there are no applications that randomly write to files. There may be some backup application running in the background, or you may have the locate service running, or be running glimpse/agrep, but they (a) only read, so they'll at worst update atime, not mtime, and (b) in most cases only read the file metadata (directory entry and inode), so even the atime should not be updated by them.

In theory, it is possible to set the mtime to anything you want, using the utimes system call; in practice, this should not be happening.

How does the XP machine access the content on the FreeBSD machine? What happens if you do directory listings on both XP and FreeBSD machines while the file is being edited?

Also: Setting the time forward on the XP machine may or may not help. The XP application may simply be checking that the mtime of the file is *different* from what it expects, not *greater*. Actually, if you don't feel like fully debugging the problem, just make it go away, try this: Use NTP or a similar mechanism to synchronize the times as closely as possible; given that in practice applications that check file modification times usually allow for a few seconds of slop (because their developers know about network file systems and clock synchronization problems), and the whole issue may just silently go away.
 
ralphbsz said:
In general, the mtime of a file is only changed when something writes to it. In general, there are no applications that randomly write to files. There may be some backup application running in the background, or you may have the locate service running, or be running glimpse/agrep, but they (a) only read, so they'll at worst update atime, not mtime, and (b) in most cases only read the file metadata (directory entry and inode), so even the atime should not be updated by them.
Click to expand...

I've not checked for background jobs, but I know I haven't intentionally started any that would meddle with just any file ad libitum.

How does the XP machine access the content on the FreeBSD machine? What happens if you do directory listings on both XP and FreeBSD machines while the file is being edited?
Click to expand...

I use samba44 as the nfs-substitute. I've done the best I can to get simultaneous listings (I use a kvm that requires multiple button clicks to wrap around) and can't see anything obviously fishy. As stored, the file date & time correspond to the clock on the FreeBSD machine, i.e.: earlier.

Also: Setting the time forward on the XP machine may or may not help. The XP application may simply be checking that the mtime of the file is *different* from what it expects, not *greater*. Actually, if you don't feel like fully debugging the problem, just make it go away, try this: Use NTP or a similar mechanism to synchronize the times as closely as possible; given that in practice applications that check file modification times usually allow for a few seconds of slop (because their developers know about network file systems and clock synchronization problems), and the whole issue may just silently go away.
Click to expand...

Setting the time forward definitely didn't help, and syncing them such that there's no more than a 1 second diff also does no good.

I'm using Slickedit v9.0, and ZFS on my server-of-all-work creates the same problem by picking up files and checksumming them after every save. Which is why my first thought was that perhaps there's some system job, started by default under the table, that was doing something similar even though on this machine the fs is ufs.
 
I know it's not nice to blame the victim, but maybe Slickedit is just broken, and can't handle the time stamp not doing *exactly* what it expects? If by watching ls and dir on both machines you don't see a problem, maybe we have to assume that there really is no real problem (pun intended), and Slickedit is being too picky? Perhaps check with Slickedit-specific discussion forums or their support?
 
ralphbsz said:
I know it's not nice to blame the victim, but maybe Slickedit is just broken, and can't handle the time stamp not doing *exactly* what it expects?
Click to expand...
I'm coming to that conclusion! I'm also beginning to suspect that the "some other app changed the file" is a reaction to it having just updated the file, and that it doesn't really know how to cope with editing files stored on servers.

Perhaps check with Slickedit-specific discussion forums or their support?
Click to expand...
Went there, did that, no joy. :(
 
What's the actual change to the file, if any?

Can you run sha1 and print the attr and xattr of the file at time t and t+error so know exactly what's causing the message to show?
 
You must log in or register to reply here.
Back
Top