Author Topic: Replace existing newer file on Samba share (SlickEdit Version 15.0.0.5)  (Read 38217 times)

colonel_coder

  • Community Member
  • Posts: 49
  • Hero Points: 1
I use Slickedit to edit files on a Samba share on a Linux machine.  If I try to do back-to-back saves (e.g. when making small edits and saving my work as I go), Slickedit displays a dialog stating

"File 'path-to-file\filename' is a new version.  Replace existing version? [Yes][No][Cancel]"

How do I fix this?  I have tried adjusting the "dos filetime" parameters in smb.conf, I have tried syncing both machines to the same NTP time server, but nothing works.

If anyone knows the secret sauce, please let me know.


SlickEdit Support

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 336
  • Hero Points: 26
One of SlickEdit's secret 11 herbs and spices is located at Tools > Options > File Options > Load > Auto Reload.  If you remove this spice from the sauce (set Auto Reload = False) it should resolve your issue.

The problem probably stems from different system times on each of your flavorful Operating Systems causing confusion in the recipe. 

colonel_coder

  • Community Member
  • Posts: 49
  • Hero Points: 1
set Auto Reload = False
I am reluctant to do that, as I also do a lot of editing on a Windows file system in situations where other programs might modify the file.  What I would really like is a solution to the problem rather than a band-aid fix.

This has been a problem with Slickedit (and apparently Visual Studio, which I am told was originally based on Slickedit) for many years now.  I think it is time for the Slickedit team to step up to the plate and offer a solution which does not require disabling a desirable feature.

Mike

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 100
  • Hero Points: 20
Does this also happen with deliciously local files?

I say, we do have an option to prevent the prompting, if that is what you are looking for:
'Tools > Options > File Options > Load' > "Suppress prompt unless modified" = True

If we are misunderstanding the problematic portion of this process, please clarify your expectation.

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
MS Visual Studio and SlickEdit are completely independent products; neither is based on the other.

The root of this problem appears to be a time synchronization issue between the two machines. SlickEdit detects that the file you previously saved in SlickEdit is a newer version because the file system reports a timestamp that is later than when you saved--which is why we prompt for reloading.

We did put in a new option that will actually compare the file to the version saved in the backup history and only prompt you if the files do not match. Set "def_filetouch_checking" to 1 to enable it. You must also have Backup History on, which is on by default (and so very useful that I cannot image anyone turning it off).

Let us know if this fixes your problem.

colonel_coder

  • Community Member
  • Posts: 49
  • Hero Points: 1
Does this also happen with ... local files?
No.

I say, we do have an option to prevent the prompting, if that is what you are looking for:
'Tools > Options > File Options > Load' > "Suppress prompt unless modified" = True
I do not want to suppress the prompting.  Your solution is the software equivalent of putting black electrical tape over the "Check Engine" light.  What I want is for the feature to work properly whether or not the file is local or on a Samba share on a Linux machine.

If we are misunderstanding the problematic portion of this process, please clarify your expectation.
My development process involves saving my work very frequently.  Quite often, I save several a couple of times a second by using Alt+F+S.  This might sound like an odd way to work, but I type between 40 to 60 words per second minute.  So for the past 20+ years, saving after every edit has allowed me to work without having to shout, "Oh no!  I just lost [insert your save interval here]'s worth of edits!"  Even if my office has a power blackout, I only lose a few seconds worth of edits.

Now imagine this process with the addition of an annoying dialog every few seconds (every time I save) telling me something that is not true (the file on the Samba share is newer than the one in the editor window) and requiring me to perform an extra action to make the dialog go away.

I understand that there is a reason that Slickedit thinks that the file on the Samba share is newer, but Slickedit is wrong.  The rational conclusion is that Slickedit should be fixed to understand how to correctly detect newer files on Samba shares.  The fact that this has been a problem for at least eight years, and the only current solutions are band-aid fixes which actually disable useful features, is a state of affairs that I find quite troubling.
« Last Edit: June 07, 2010, 07:45:17 pm by colonel_coder »

colonel_coder

  • Community Member
  • Posts: 49
  • Hero Points: 1
The root of this problem appears to be a time synchronization issue between the two machines. SlickEdit detects that the file you previously saved in SlickEdit is a newer version because the file system reports a timestamp that is later than when you saved--which is why we prompt for reloading.
I would be inclined to believe this if I had not previously had the time on two similar machines synchronized to within fractions of a second using NTP while still seeing the problem.

We did put in a new option that will actually compare the file to the version saved in the backup history and only prompt you if the files do not match. Set "def_filetouch_checking" to 1 to enable it. You must also have Backup History on, which is on by default (and so very useful that I cannot image anyone turning it off).
I have backup history enabled and I ran "set_var def_filetouch_checking 1" but it did not solve the problem.

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Did you really mean to say that you type 40 to 60 words per second and that you save several times a second? I'm guessing you meant "minute"--not that this has anything to do with the issue at hand, but it does make me curious.

What is Alt+F+S bound to? Maybe that save mechanism is bypassing Backup History. If you save as frequently as you say, it could be that you have exceeded some maximum and that we are not storing versions any longer. Can you check to see that new entries are being created in Backup History when you do these saves. You can view them in the Backup History tool window by selecting View > Tool Windows > Backup History.

I'm trying to see if there is some way we can look at the timestamps involved in this workflow. Perhaps if you could see when SlickEdit thinks the file was saved and what SlickEdit thinks the timestamp is for the samba share, then we could understand why SlickEdit thinks the remote file is newer. If the two machines are synchronized as you say, then maybe our comparison is being too precise and we need to allow a setting that would allow for them to be off by fractions of a second.



colonel_coder

  • Community Member
  • Posts: 49
  • Hero Points: 1
Did you really mean to say that you type 40 to 60 words per second and that you save several times a second? I'm guessing you meant "minute"--not that this has anything to do with the issue at hand, but it does make me curious.
1000 pardons:  40 to 60 words per minute.  I edited my original post to strikeout the "seconds" and replace it with minutes to prevent confusing posterity.

What is Alt+F+S bound to?
It's the CUA binding for "Save" (also accessed by Ctrl+S, however Alt+F+S does not require moving the fingers away from the home row).

Maybe that save mechanism is bypassing Backup History. If you save as frequently as you say, it could be that you have exceeded some maximum and that we are not storing versions any longer. Can you check to see that new entries are being created in Backup History when you do these saves. You can view them in the Backup History tool window by selecting View > Tool Windows > Backup History.
Just running a quick test of saving the same file repeatedly without making any changes causes the problem but the "Backup History" does not update.

I'm trying to see if there is some way we can look at the timestamps involved in this workflow. Perhaps if you could see when SlickEdit thinks the file was saved and what SlickEdit thinks the timestamp is for the samba share, then we could understand why SlickEdit thinks the remote file is newer. If the two machines are synchronized as you say, then maybe our comparison is being too precise and we need to allow a setting that would allow for them to be off by fractions of a second.
One thing I used to do that was another band-aid workaround was to disable NTP on the Linux machine with the Samba share and set the time to be a few seconds behind the Windows machine.  In this situation, I presumed that the file time always looked like it was in the past.  However, this no longer seems to work.  This indicates to me that something in the file time checking has changed in recent releases of Slickedit.

I just ran a more realistic test where I typed a word, saved the file, backspaced over the word, saved the file, and repeated several times.  This time, the backup history got updated, but I still got the dialog box mentioned in the original post.
« Last Edit: June 07, 2010, 09:05:22 pm by colonel_coder »

colonel_coder

  • Community Member
  • Posts: 49
  • Hero Points: 1
I disabled NTP on the Linux machine with the Samba share.  Then I set the time to be 5 seconds behind the Windows machine.  I ran a test where I added a word to the file, saved the file, removed the word from the file, saved the file, and repeated those steps.  The time in the backup history was the time on the Linux machine (so it appears Slickedit is getting the file time from the Linux machine).  I still get the "Replace existing newer file?" dialog during each save.

I added the settings at the top of this link:  http://www.samba.org/samba/docs/using_samba/ch11.html.  Then I re-synchronized the Linux machine with 0.pool.ntp.org and restarted the NTP server.  After that, I ran the "net time \\linux-machine /set /yes" command on the Windows machine.  This still did not solve the problem.

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
We did find a bug in the Backup History related to getting the most recent version, which is why we think the defvar didn't work for you. We're trying to fix that now.

I really, REALLY want to see the timestamps, so I have someone working on finding a way to display them. Once we can see those, then we'll have some idea what's going on. I hope it's merely a precision issue, that we're comparing to the exact millisecond or something. Then we might be able to offer a fudge variable that says how precise that comparison should be. That should allow for some degree of drift between the two machines...assuming that is the problem. If the timestamps are the same, then we've got to keep thinking.

I'm really glad it is 40 to 60 words per minute. I was feeling pretty inadequate there for a while. I may not be the best typist on the planet, but if someone out there is typing at 40 to 60 words per second, I've got to bust out Mavis Beacon for some practice. ;)

Dan

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2545
  • Hero Points: 141
Could you PM me an email address so I can send you a macro to gather a little more information about what is going on?

colonel_coder

  • Community Member
  • Posts: 49
  • Hero Points: 1
...so I can send you a macro to gather a little more information about what is going on?
The log is below.  However, the log did not update every time I saved the file.  I had to save the file and then click on the "vsapi.dll" icon in the taskbar to get it to update.  You may need to make a change to get it to update after every save.
Code: [Select]
findModifiedAndDeleted p_buf_name=r:\tmp\blah.c
                       p_file_date=20100610140358000
                       bfiledate=20100610140902000
                       diff=544000
findModifiedAndDeleted p_buf_name=r:\tmp\blah.c
                       p_file_date=20100610141042000
                       bfiledate=20100610141049000
                       diff=7000
findModifiedAndDeleted p_buf_name=r:\tmp\blah.c
                       p_file_date=20100610141111000
                       bfiledate=20100610141126000
                       diff=15000
findModifiedAndDeleted p_buf_name=r:\tmp\blah.c
                       p_file_date=20100610141207000
                       bfiledate=20100610141218000
                       diff=11000
findModifiedAndDeleted p_buf_name=r:\tmp\blah.c
                       p_file_date=20100610141218000
                       bfiledate=20100610141227000
                       diff=9000
findModifiedAndDeleted p_buf_name=r:\tmp\blah.c
                       p_file_date=20100610141227000
                       bfiledate=20100610141232000
                       diff=5000
findModifiedAndDeleted p_buf_name=r:\tmp\blah.c
                       p_file_date=20100610141232000
                       bfiledate=20100610141237000
                       diff=5000
findModifiedAndDeleted p_buf_name=r:\tmp\blah.c
                       p_file_date=20100610141237000
                       bfiledate=20100610141243000
                       diff=6000
findModifiedAndDeleted p_buf_name=r:\tmp\blah.c
                       p_file_date=20100610141257000
                       bfiledate=20100610141300000
                       diff=43000
findModifiedAndDeleted p_buf_name=r:\tmp\blah.c
                       p_file_date=20100610141305000
                       bfiledate=20100610141308000
                       diff=3000
findModifiedAndDeleted p_buf_name=r:\tmp\blah.c
                       p_file_date=20100610141342000
                       bfiledate=20100610141346000
                       diff=4000
findModifiedAndDeleted p_buf_name=r:\tmp\blah.c
                       p_file_date=20100610141351000
                       bfiledate=20100610141353000
                       diff=2000

Dan

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2545
  • Hero Points: 141
Are these times for files that you would expect the time stamp to match for?

Is the actual file on a machine on a local network, or is it accessed from a wider network?

Are these timestamps the result of saving in SlickEdit?  Or could something else have set the time the last time the file was updated?


colonel_coder

  • Community Member
  • Posts: 49
  • Hero Points: 1
Are these times for files that you would expect the time stamp to match for?
Yes.

Is the actual file on a machine on a local network, or is it accessed from a wider network?
The file is on a machine on a LAN.  The Windows machine running Slickedit is connected to the same 8-port switch as the Linux machine hosting the Samba share, and the switch is connected to the LAN.

Are these timestamps the result of saving in SlickEdit?  Or could something else have set the time the last time the file was updated?
The timestamps are a result of saving in Slickedit.  No other program accessed the file.  I was deliberately limiting variables.