Author Topic: "Replace newer file?"  (Read 2829 times)

Margaret

  • Community Member
  • Posts: 70
  • Hero Points: 0
"Replace newer file?"
« on: July 14, 2017, 05:04:50 PM »
I'm being driven mad by Slick v9 telling me that the file on disc is newer and more wonderful and do I really want to replace it with this old grotty one I've just been editing.  I don't have auto-save on.

To irritate me further, Slick sometimes asks me whether I want to reload the file since some other unnamed application has just modified it.  But when I ask for the diffs, there are none.

This is not a case of me storing the files on my server-of-all-work where ZFS checksums them and thus updates their timestamp.  I'm saving them to a different (faster) FreeBSD box where the filesystem is UFS, which doesn't fondle files unless asked.

I've gone so far as to set XP's clock 5 minutes ahead of the BSD box's so that the edited version I'm trying to save is definitely "newer".  Doesn't help.

How can I make it stop?

jporkkahtc

  • Senior Community Member
  • Posts: 2620
  • Hero Points: 210
  • Text
Re: "Replace newer file?"
« Reply #1 on: July 14, 2017, 06:07:22 PM »
Are you asking for Slick not to complain in these cases, or because Slick is confused about the files being changed?

Margaret

  • Community Member
  • Posts: 70
  • Hero Points: 0
Re: "Replace newer file?"
« Reply #2 on: July 14, 2017, 06:30:58 PM »
I want a way to force Slick to get its act together and stop complaining about the disc file being newer.  Since XP's clock is telling Slick that the version in the buffer is a minimum of five minutes newer than the file on disc, something really goofy must be going on.  Either Slick is checking something other than the respective timestamps, or there's some setting I don't know about that's meddling with the test.

jporkkahtc

  • Senior Community Member
  • Posts: 2620
  • Hero Points: 210
  • Text
Re: "Replace newer file?"
« Reply #3 on: July 14, 2017, 06:40:24 PM »
Are you using SAMBA on the server, or some other network filesystem? (NFS?)

Have you tried a test from a CMD window doing something like
 pushd \\bsdbox\share\src
 echo >> file.txt
 dir file.txt
 echo %DATE% %TIME%

Is the timestamp on the file the same as the clock on XP?

Also try modifiying the file from a login on the bsdbox, then looking at the timestamp from XP.

Margaret

  • Community Member
  • Posts: 70
  • Hero Points: 0
Re: "Replace newer file?"
« Reply #4 on: July 14, 2017, 07:52:59 PM »
Are you using SAMBA on the server, or some other network filesystem? (NFS?)

Have you tried a test from a CMD window doing something like
 pushd \\bsdbox\share\src
 echo >> file.txt
 dir file.txt
 echo %DATE% %TIME%

Is the timestamp on the file the same as the clock on XP?

Also try modifiying the file from a login on the bsdbox, then looking at the timestamp from XP.

I'm using samba 4.4, since at least it's being maintained --unlike Microsoft's version of nfs.

The bsd timestamp is the same no matter where I edit or from which box I look at the file ---I've checked it back and forth.  I have both boxes syncing time hourly with my server-of-all-work, and their clocks don't drift discernably in an hour.  After they sync they're observably the same within a second at most. 

The goofy part, which seems as though it ought to be significant, is that even when XP's clock ahead of the BSD's clock by five minutes, Slick still asked me whether I wanted to replace the "newer" file.  The only possibility I can think of is that Slick looks not just at the local clock, but also at the destination clock and calcs the offset to decide which version is newer.  But that would be really obnoxious.

jporkkahtc

  • Senior Community Member
  • Posts: 2620
  • Hero Points: 210
  • Text
Re: "Replace newer file?"
« Reply #5 on: July 14, 2017, 08:50:54 PM »
AFAIK, Slick is just looking at the timestamp on the file.

When it complains, it looks at the timestamp of the file when Slick loaded or last saved it, and compares that to the current timestamp of the file.
The system clock shouldn't directly affect this comparison.

Normally Windows only shows you the hour and minute of the modification time.
You might need more information - since Windows keeps timestamps for files in 100ns increments, and Unix typically keeps it accurate to the second.

The only thing in Windows I know that shows more accurate filetime is "wmic".
From a CMD window, enter this:
wmic datafile where name="C:\\temp\\x.txt"  get lastmodified

Where "DIR C:\temp\x.txt" shows
    07/14/2017  01:32 PM                26 x.txt
WMIC will show much more precisely:
    20170714133238.517893-420


On Windows, the FAT filesystem only keeps timestamps accurate to 2 seconds - so most programs, including Slick deal with that. On a file share, Slick may *assume* that the timestamp is more accurate than it really is - thus confusing things (though, I've never seen this happen - but then, I don't usually edit really big files on Samba servers).

V21 slick has auto-reload options to compare the file contents before complaining - but this is no good for really big files (as I think you are using, right?).

I thought it had an options WRT the FAT 2-second thing, but I can't find it.


See:
def_filetouch_checking
def_autoreload_compare_contents
def_autoreload_compare_contents_max_ksize




Margaret

  • Community Member
  • Posts: 70
  • Hero Points: 0
Re: "Replace newer file?"
« Reply #6 on: July 14, 2017, 09:54:34 PM »
AFAIK, Slick is just looking at the timestamp on the file.

When it complains, it looks at the timestamp of the file when Slick loaded or last saved it, and compares that to the current timestamp of the file.
The system clock shouldn't directly affect this comparison.

Normally Windows only shows you the hour and minute of the modification time.

I get the seconds by selecting the file in the listing and looking at properties -- it shows seconds.  It should be possible to default to showing seconds, but of course Microsoft decided that was TMI.

Quote
V21 slick has auto-reload options to compare the file contents before complaining - but this is no good for really big files (as I think you are using, right?).

Yes, that's for sure a nice feature that should have been there from the off, or offered as a patch.  Pity it wasn't.  Yes, at least some files I need to edit are >200GB.  I did buy a copy of v20 for the sake of the address space, but it turned out to have problems with really big files.  So I don't use it and am back to writing filters to do the job instead.   Once I get some free time -if I'm not dead by then- I reckon I'll build a copy of Geany that knows how to page large files in and out.