Re: tramp (2.1.18-23.2); emacs on WinXp remote access FreeBSD

2011/6/26 Michael Albinus <michael.albinus <at> gmx.de>:
> Could you, please, start a new Emacs session with "emacs -Q". Then apply
> the following forms:
>
> (tramp-cleanup-all-connections)
> (setq tramp-verbose 6)
>
> Afterwards, run your test until the problem happens. Save Tramp's debug
> buffer into a file, and send it as email.
>
>> Thanks!
>
> Best regards, Michael.
>

Hi,Michael
It was busy these days.
The new debug buffer message you need is in the attachment.It works
well with the as5 servers of company by the way,perhaps I'd change my
box to as5.
Thanks!

_______________________________________________
Tramp-devel mailing list
Tramp-devel <at> gnu.org
https://lists.gnu.org/mailman/listinfo/tramp-devel

Re: tramp (2.1.18-23.2); emacs on WinXp remote access FreeBSD

Zhang hw <zhhw210095 <at> gmail.com> writes:

> Hi,Michael

Hi,

> The new debug buffer message you need is in the attachment.It works
> well with the as5 servers of company by the way,perhaps I'd change my
> box to as5.

Honestly, the traces don't show any error. So I don not know what I
could do else but debugging in your environment (which isn't possible,
of course).

What I can tell is that *BSD targets always raise problems. See
tramp-sh.el and its dozen of comments for workarounds. Maybe there is
also another problem we haven't detected yet.

OTOH, Tramp 2.2 might behave better in your case. There are several
bugfixes which are not included in Tramp 2.1.18.

I'm very sorry that I cannot help.

> Thanks!

Best regards, Michael.

tramp (2.1.20); dired buffers have modified bit set

Enter your bug report in this message, including as much detail
as you possibly can about the problem, what you did to cause it
and what the local and remote machines are.

If you can give a simple set of instructions to make this bug
happen reliably, please include those.  Thank you for helping
kill bugs in Tramp.

Before reproducing the bug, you might apply

  M-x tramp-cleanup-all-connections

This allows to investigate from a clean environment.  Another
useful thing to do is to put

  (setq tramp-verbose 9)

in the ~/.emacs file and to repeat the bug.  Then, include the
contents of the *tramp/foo* buffer and the *debug tramp/foo*
buffer in your bug report.

--bug report follows this line--

Hi,

Modified dired buffers seem to cause problems for some packages,
e.g. magit: https://github.com/magit/magit/issues/231
The only ones I've seen have been tramp buffers, so I thought maybe
you'd want to look at it.

Re: tramp (2.1.20); dired buffers have modified bit set

Dave Abrahams <dave <at> boostpro.com> writes:

> Hi,

Hi Dave,

> Modified dired buffers seem to cause problems for some packages,
> e.g. magit: https://github.com/magit/magit/issues/231
> The only ones I've seen have been tramp buffers, so I thought maybe
> you'd want to look at it.

It doesn't seem to be a pure Tramp problem. The backtrace you have
published indicates a problem in `magit-save-buffers-predicate-tree-only':

(defun magit-save-buffers-predicate-tree-only ()
  "Only prompt to save buffers which are within the current git project (as
  determined by the dir passed to `magit-status'."
  (let ((current-buf-dir
         (file-name-directory (buffer-file-name (current-buffer)))))
  ...

(buffer-file-name (current-buffer)) implies, that every buffer has a
file name. This is not the case; the call could return
`nil'. `file-name-directory' returns an error then.

A better approach might be to use `default-directory', which is bound
locally in every buffer.

> Cheers,
> Dave

Re: tramp (2.1.20); dired buffers have modified bit set

Hi Michael,

Yeah, sorry for the false report.  We determined that it's a magit
problem.

on Fri Jul 08 2011, Michael Albinus <michael.albinus-AT-gmx.de> wrote:

> Dave Abrahams <dave <at> boostpro.com> writes:
>
>> Hi,
>
> Hi Dave,
>
>> Modified dired buffers seem to cause problems for some packages,
>> e.g. magit: https://github.com/magit/magit/issues/231
>> The only ones I've seen have been tramp buffers, so I thought maybe
>> you'd want to look at it.
>
> It doesn't seem to be a pure Tramp problem. The backtrace you have
> published indicates a problem in `magit-save-buffers-predicate-tree-only':
>
> (defun magit-save-buffers-predicate-tree-only ()
>   "Only prompt to save buffers which are within the current git project (as
>   determined by the dir passed to `magit-status'."
>   (let ((current-buf-dir
>          (file-name-directory (buffer-file-name (current-buffer)))))
>   ...
>
> (buffer-file-name (current-buffer)) implies, that every buffer has a

Re: tramp (2.1.20); dired buffers have modified bit set

Dave Abrahams <dave <at> boostpro.com> writes:

> Hi Michael,

Hi Dave,

> Yeah, sorry for the false report.  We determined that it's a magit
> problem.

No problem. I'm happy it isn't a Tramp error.

Best regards, Michael.

tramp (2.2.2-pre); non-working "stat -c" no longer correctly handled or recorded in ~/.emacs.d/tramp

Using tramp via ssh/scp to connect to a box that doesn't like "stat -c"
(such as OSX) aborts with the message:

byte-code: `\stat -c '("%N" %s)' /' returns with error

For long-time tramp users this is usually masked by an existing entry in
~/.emacs.d/tramp such as
  ("stat" nil)
so the bug is never triggered.

Apparently, the bug is recent and only occurs in recent versions of
Emacs 24, so you'll only detect it with trying out new hosts.
(or tricking out tramp by connecting to /hoStname: etc.)

--bug report follows this line--

Emacs  : GNU Emacs 24.0.50.1 (x86_64-apple-darwin, NS apple-appkit-1038.35)
 of 2011-07-16 on virtualmac.porkrind.org
Package: tramp (2.2.2-pre)

(nothing useful here)

Re: tramp (2.2.2-pre); non-working "stat -c" no longer correctly handled or recorded in ~/.emacs.d/tramp

Carsten Bormann <cabo <at> tzi.org> writes:

> Using tramp via ssh/scp to connect to a box that doesn't like "stat -c"
> (such as OSX) aborts with the message:
>
> byte-code: `\stat -c '("%N" %s)' /' returns with error
>
> For long-time tramp users this is usually masked by an existing entry in
> ~/.emacs.d/tramp such as
>   ("stat" nil)
> so the bug is never triggered.
>
> Apparently, the bug is recent and only occurs in recent versions of
> Emacs 24, so you'll only detect it with trying out new hosts.
> (or tricking out tramp by connecting to /hoStname: etc.)

Should be fixed now.

Thanks for reporting, and best regards, Michael.

Re: tramp (2.2.2-pre); non-working "stat -c" no longer correctly handled or recorded in ~/.emacs.d/tramp

> Should be fixed now.

I can confirm that this now works properly again in Emacs 24, revno: 105316

Thank you very much!

Gruesse, Carsten

Tramp 2.2.2

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.sources as well.

Hello,

The Tramp team is happy to announce the release of Tramp 2.2.2.

Tramp is a remote file editing package for Emacs and XEmacs.  Tramp uses
different methods like ssh or scp to access files on remote hosts as if
they were local files.  Access to the remote file system for editing
files, version control, directory editing and running processes on the
remote host are transparently enabled.

Tramp 2.2.2 supports Emacs since version 22 and XEmacs since version
21.4.  Starting with this release, Tramp 2.2 is the main line of Tramp
development.  It can be used also in production systems.  Tramp 2.1 will
be modified only in case of serious problems.

This release is merged into the Emacs 24 repository.  The XEmacs package
repository is not updated, we would be happy if an XEmacs developer
could take over this task.

The download files are located at ftp://ftp.gnu.org/gnu/tramp/

Tramp's homepage is http://www.gnu.org/software/tramp/ (for Emacs) or
http://www.gnu.org/software/tramp/tramp-xemacs.html (for XEmacs),
respectively.

Best regards, Michael.