Michael Albinus | 2 Jan 07:05 2008
Picon
Picon

Re: TRAMP problem report

"Robert A. Lerche" <ral <at> msbit.com> writes:

> I sent this to tramp-devel <at> gnu.org but it doesn't seem to be showing
> up in the archive (I checked a day later and it wasn't present at
> http://lists.gnu.org/archive/html/tramp-devel/)

It is a moderated list. There might be a delay of some few days, when
Adrian, our very responsive moderator, is offline.

> Scenario: trying to use tramp to edit (locally on my laptop) files on
> a "one laptop per child" (OLPC XO) system.
>
> Because the XO has only wireless network access, I am going through a
> wireless access point that does NAT.  In order to initiate connections
> from my laptop to the OLPC I first create a tunnel via "ssh -f -N -R
> 10000:localhost:22 ral <at> archie" on the OLPC console.  This allows me to
> open an SSH connection from archie (my laptop, on the "outside" of the
> wireless access point) to the OLPC (behind it) via "ssh -p 10000
> root <at> localhost".

Tramp has some optimization code which applies a direct copy when Tramp
"believes" it is on the local host. Your tunnel via port 10000 makes
Tramp believe it. Hmm, bad.

I'll check whether I can fix it. For the time being, you might not
establish a tunnel but use Tramp's multi-hop feature. See the Tramp
manual, section "Multi-hops". Note that you must use the "ssh" method
instead of "scp"; the latter one is not suited for multi-hops.

I'll come back when I have fixed it.
(Continue reading)

Michael Albinus | 3 Jan 00:50 2008
Picon
Picon

Re: file storage in IMAP (eventually for Tramp) working and needs testing

Ted Zlatanov <tzz <at> lifelogs.com> writes:

> MA> I'm a little bit lost. Does it mean you don't want to offer *all*
> MA> messages in a mailbox?
>
> Correct, otherwise it's hard to handle invalid messages: are they
> invalid files or something else?  I wanted also to treat duplicates as
> automatic backups but if you don't like that idea then I'll drop it.

Maybe we should see real life examples. I don't know whether it is
always good to present selected contents only. If there are technical
restrictions - that's another game.

> MA> The more serious work with Tramp is that all file operations towards
> MA> IMAP must be mapped to Emacs' file name handler primitives like
> MA> file-local-copy or write-region. If you want, I could support you a
> MA> little bit(1) in writing a tramp-imap.el.
>
> Sure.  In fact trimp.el is tramp-imap.el, shortened :) The name is not
> important, if you want the latter.  Should it live in Tramp instead of
> Gnus?  If so, imap.el will be needed, and it's only in Emacs after 22 I
> believe.  Any opinions (Reiner?) are welcome.
>
> Let me know what pieces you need from me, and if there's an example in
> Tramp I should follow to implement this.

It would be nice if it could live in the Tramp repository. I'm not
fundamentalistic about names, but so far we have just tramp*.el files
there.

(Continue reading)

Michael Albinus | 3 Jan 13:56 2008
Picon
Picon

Re: file storage in IMAP (eventually for Tramp) working and needs testing

Ted Zlatanov <tzz <at> lifelogs.com> writes:

> I've submitted Emacs papers and Gnus papers, so no worries either way.

Thanks. I have no idea whether an additional Tramp paper is needed
then, we will ask the FSF.

However, it is reasonable for me to give you write access to the Tramp
CVS repository. I've just added you on savannah.

> Ted

Best regards, Michael.
Michael Albinus | 4 Jan 12:00 2008
Picon
Picon

Re: file storage in IMAP (eventually for Tramp) working and needs testing

Ted Zlatanov <tzz <at> lifelogs.com> writes:

> Say you have these article UIDs and subjects, and UIDs are ordered by
> date.  Note the ENCODED_FILENAME will be the filename encoded in some
> way and /a/b/c is the filename without any risky characters; Gnus has
> the subject encoding functionality already.  The subject format is
> specifically to allow easy searching.
>
> 1 "tramp-imap-marker /a/b/c ENCODED_ABC"
> 2 "tramp-imap-marker /a/b/c ENCODED_ABC"
> 3 "tramp-imap-marker /a/b/c ENCODED_ABC"
> 4 "hello world"
>
> Do we 
>
> A) allow for three identically named files, dynamically renaming 2 and 3
> with the Emacs <1> and <2> convention?
>
> B) ignore 1 and 2, never create them intentionally, and (optionally)
> erase duplicates when a file is saved?  This is probably easiest to
> implement in code.
>
> C) treat 1 and 2 as backups (there will be a tramp-imap-backups
> parameter to control how many are allowed per filename, and older ones
> over that limit are erased when a file is saved)?  We'll need a
> mechanism to revert to a backup, which I don't think Tramp has built-in
> at the moment.

If 1, 2 and 3 are created only by tramp-imap, then C might be the
preferred choice. B doesn't look good to me, I believe all files must
(Continue reading)

Michael Albinus | 4 Jan 13:43 2008
Picon
Picon

Re: TRAMP problem report

I wrote:

> "Robert A. Lerche" <ral <at> msbit.com> writes:
>>
>> Because the XO has only wireless network access, I am going through a
>> wireless access point that does NAT.  In order to initiate connections
>> from my laptop to the OLPC I first create a tunnel via "ssh -f -N -R
>> 10000:localhost:22 ral <at> archie" on the OLPC console.  This allows me to
>> open an SSH connection from archie (my laptop, on the "outside" of the
>> wireless access point) to the OLPC (behind it) via "ssh -p 10000
>> root <at> localhost".
>
> Tramp has some optimization code which applies a direct copy when Tramp
> "believes" it is on the local host. Your tunnel via port 10000 makes
> Tramp believe it. Hmm, bad.

It's not only the optimization code, there are other settings too
which are not working when you establish your tunnel. The problem is
shortly discussed in the Tramp manual, section "Reusing connection
related information".

Could you consider changing your ~/.ssh/config as it is proposed there?

>> Thanks for your help.

Best regards, Michael.
Reiner Steib | 3 Jan 12:32 2008
X-Face

Re: file storage in IMAP (eventually for Tramp) working and needs testing

On Thu, Jan 03 2008, Michael Albinus wrote:

> The only "piece" I would need from you are legal papers from the FSF for
> Tramp and for Emacs. Guess you have it partly already because of gnus.

Ted (Teodor Zlatanov) already has an assignment for Emacs on file.
I'd guess this covers Tramp as well, doesn't it?
(Like an assignment for Emacs covers Gnus.)

Bye, Reiner.
--

-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
James Cloos | 3 Jan 18:31 2008
Face

Re: file storage in IMAP (eventually for Tramp) working and needs testing

On namespaces in IMAP, do note that not every imapd uses . (full stop)
as the hierarchy separator character; many use / (virgule).  The LIST
command will show what that server uses.

Also, some (many?) users will probably not like the idea of turning
INBOX into a parent.  That convention seems to be a uw thing, AFAICT.

Were I to use this I’d want to put it all under something like
Emacs/Tramp/ or so.

-JimC
--

-- 
James Cloos <cloos <at> jhcloos.com>         OpenPGP: 1024D/ED7DAEA6
Ted Zlatanov | 3 Jan 14:27 2008
X-Face

Re: file storage in IMAP (eventually for Tramp) working and needs testing

On Thu, 03 Jan 2008 07:21:42 -0600 Ted Zlatanov <tzz <at> lifelogs.com> wrote: 

TZ> Third question: namespaces.  I feel that it's much better
TZ> for the user to store all the files in a single mailbox:

TZ> INBOX.storage holds /a/b/c, /d/e/f, and /g/h/i

TZ> I believe you proposed that instead we should auto-create:

TZ> INBOX.storage.a.b to hold /a/b/c
TZ> INBOX.storage.d.e to hold /d/e/f
TZ> INBOX.storage.g.h to hold /g/h/i

I realized there is a third option: don't allow directories.  Everything
is at the top level /, and make-directory fails.  That would simplify
the code tremendously though users may not like it.

Ted
Ted Zlatanov | 3 Jan 13:43 2008
X-Face

Re: file storage in IMAP (eventually for Tramp) working and needs testing

On Thu, 03 Jan 2008 12:32:44 +0100 Reiner Steib <reinersteib+gmane <at> imap.cc> wrote: 

RS> On Thu, Jan 03 2008, Michael Albinus wrote:
>> The only "piece" I would need from you are legal papers from the FSF for
>> Tramp and for Emacs. Guess you have it partly already because of gnus.

RS> Ted (Teodor Zlatanov) already has an assignment for Emacs on file.
RS> I'd guess this covers Tramp as well, doesn't it?
RS> (Like an assignment for Emacs covers Gnus.)

I've submitted Emacs papers and Gnus papers, so no worries either way.

Ted
Ted Zlatanov | 3 Jan 14:21 2008
X-Face

Re: file storage in IMAP (eventually for Tramp) working and needs testing

On Thu, 03 Jan 2008 00:50:56 +0100 Michael Albinus <michael.albinus <at> gmx.de> wrote: 

MA> Ted Zlatanov <tzz <at> lifelogs.com> writes:
MA> I'm a little bit lost. Does it mean you don't want to offer *all*
MA> messages in a mailbox?
>> 
>> Correct, otherwise it's hard to handle invalid messages: are they
>> invalid files or something else?  I wanted also to treat duplicates as
>> automatic backups but if you don't like that idea then I'll drop it.

MA> Maybe we should see real life examples. I don't know whether it is
MA> always good to present selected contents only. If there are technical
MA> restrictions - that's another game.

(I'm leaving Ding on the CC in case anyone has comments)

Say you have these article UIDs and subjects, and UIDs are ordered by
date.  Note the ENCODED_FILENAME will be the filename encoded in some
way and /a/b/c is the filename without any risky characters; Gnus has
the subject encoding functionality already.  The subject format is
specifically to allow easy searching.

1 "tramp-imap-marker /a/b/c ENCODED_ABC"
2 "tramp-imap-marker /a/b/c ENCODED_ABC"
3 "tramp-imap-marker /a/b/c ENCODED_ABC"
4 "hello world"

Do we 

A) allow for three identically named files, dynamically renaming 2 and 3
(Continue reading)


Gmane