tramp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BUG] TRAMP 2.1.20: "uudecode -o /dev/stdout" check


From: Dmitry Kurochkin
Subject: Re: [BUG] TRAMP 2.1.20: "uudecode -o /dev/stdout" check
Date: Mon, 19 Dec 2011 19:11:53 +0400
User-agent: Notmuch/0.10.2+96~g74e5ae5 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

On Mon, 19 Dec 2011 10:01:21 +0100, Michael Albinus <address@hidden> wrote:
> Dmitry Kurochkin <address@hidden> writes:
> 
> > Hi Michael.
> 
> Hi Dmitry,
> 
> > It is possible that the command TRAMP uses for decoding was just
> > removed.  What would happen then?  As I understand, TRAMP would print an
> > error that write failed because the command would fail.  But at the same
> > time it would wipe out the file because output is done via a
> > redirection.
> 
> Indeed. However, I've never heard about such a situation all the years
> I'm using Tramp. And there is still the backup file which could be moved
> back, isn't it?
> 

Do you mean the local backup file created by Emacs?

> > Another (and probably better) option may be to add "which command &&" or
> > similar to all decoders.
> 
> Maybe. But there are also other dangerous commands in  Tramp, which must
> be protected then. Isn't this overcautious?
> 

I guess you know better.  But IMHO it is not.  I do not know about other
commands, but if they use output redirection, they should probably be
protected as well.

If decoders were using output file options instead or redirection
(i.e. uudecode -o file instead of uudecode -o- > file), then "which"
protection would not be needed.

> > BTW if TRAMP finds that remote encoder/decoder fails, does it start
> > checking for a working encoder/decoder again?
> 
> There are situations, Tramp cleans up its whole cache (for example, when
> a connection has been broken). And there are the `tramp-cleanup-*'
> commands, which give the user the same mean, interactively.
> 

Thanks,
  Dmitry

> > Regards,
> >   Dmitry
> 
> Best regards, Michael.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]