Re: problem with tramp-time-diff

[Kai Großjohann]

Rodney Sparapani <address@hidden> writes:

> I think I've figured out what problem my solution was
> actually fixing.  Initially, I was having some
> problems with subtract-time that seem to have disappeared.  I recently
> upgraded some packages so maybe that fixed it (I had an APEL
> package, in particular, that was installed incorrectly).

Okay.  There were some problems regarding tramp-time-diff: some parts
of Tramp assumed it was returning a list of numbers, other parts were
assuming it returns just a number.  I think I fixed those troubles
with the following changes:

2003-06-08  Kai Großjohann  <address@hidden>

        * tramp.el (tramp-handle-file-newer-than-file-p):
        `tramp-time-diff' returns integer, not list.  Do not apply `car'
        to the return value of `tramp-time-diff'.  Reported by David
        D. Smith <ultrasoul at ultrasoul.com>.
        (tramp-time-diff): Convert return value of subtract-time to a
        number of seconds in a correct manner, by applying float-time or
        time-to-seconds.  Also correct compat code accordingly.  The
        XEmacs branch for itimer-time-difference didn't need correction,
        it returned a float already.  Reported by David D. Smith
        <ultrasoul at ultrasoul.com>.

I obfuscated the email address a bit.

> However, occasionally when I'm trying to open a directory remotely
> in a dired buffer with tramp, itimer will fail with a message.
> Something like:  itimer:  "<itimer -1>" (nocatch nil).  So, I went
> back to my fix for the subtract-time problem and it also fixes the
> itimer problem.  That was the part of the story that I was
> forgetting when I brought this up last month.

Hm.  This seems to be a different problem: Tramp is calling itimer and
that is failing for some reason.  By using your own implementation of
subtract-time you are avoiding the call to itimer.

So, what does one do?  It seems that this is a bug in itimer, though
of course I can't be sure and I don't want to put the blame on it if
it's not the cause ;-).  Can you get a backtrace via (setq
debug-on-error t) or suchlike?

Any XEmacs experts here who know about this problem?
-- 
~/.signature