# What non-editor updates file timestamps?



## MMacD (Jul 13, 2017)

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.


----------



## ShelLuser (Jul 13, 2017)

What file are you editing? That might help us to shed more light on this.


----------



## ralphbsz (Jul 13, 2017)

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.


----------



## MMacD (Jul 14, 2017)

ShelLuser said:


> What file are you editing? That might help us to shed more light on this.



Nothing to do with the system -- it's just another filter that I'm writing so that I don't have to edit a 171GB file by hand.


----------



## MMacD (Jul 14, 2017)

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.



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?



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.



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.


----------



## ralphbsz (Jul 14, 2017)

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?


----------



## MMacD (Jul 15, 2017)

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?


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?


Went there, did that, no joy.


----------



## poorandunlucky (Jul 16, 2017)

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?


----------

