Clipboard transfer between MACs

Richard Schletty rschletty "at"
Wed, 27 Jun 2001 19:35:24 +0000

I also weigh a file transfer capability more heavily than the clipboard
transfer. I've been using Timbuktu for years -- its Exchange feature has a
very basic interface (only a single column listing files alphabetically) but
is very robust. An essential element is its Find function. TB2 for Mac has
a bonus Drag n' Drop capability.

I use TB2's Clipboard transfer less often.

Richard Schletty
Schletty Graphics
Design & illustration for print & web publishing.
Desktop publishing support. Network administration.
Saint Paul, Minnesota
rschletty "at"
Vox 651-222-2526
Fax 651-227-1492

> From: Jonathan Morton <chromi "at">
> Reply-To: vnc-list "at"
> Date: Wed, 27 Jun 2001 12:57:22 +0100
> To: vnc-list "at"
> Subject: Re: Clipboard transfer between MACs
>>> I haven't been able to do a Clipboard transfer between Macs running Mac OS
>>> 9.x. Is it possible? If so, how?
>> Ok, well, that's not one I know how to handle. I haven't had easy access to
>> an unrestricted MAC in several years now....
>> What I was referring to is that the VNC protocol already support clipboard
>> transfer. I'm surprised if there isn't support in at least one of the MAC
>> servers/viewers combinations, but I really don't know. It works with all
>> combinations of Xvnc and WinVNC, though.
> Unfortunately, that's an unimplemented feature in ChromiVNC for the
> time being.  I can add it to my TO-DO list if it's a
> commonly-requested feature...  Also, I think a number of Mac clients
> don't handle the Clipboard yet either, apart from being able to
> "rapid-type" text from the client Clipboard by sending keypresses
> (this doesn't quite work either, I need to put an anti-overflow
> thingy in the server).
> In any case, I'm much more in favour of a dedicated file-transfer
> scheme being added to the RFB protocol, rather than being hacked into
> the Clipboard-transfer stuff.  In particular, the Clipboard on most
> systems has some kind of memory constraint, and may not be 8-bit
> clean for content described as "text".  Do you really want to spend 2
> hours transferring a file only to find there wasn't enough memory to
> hold it all?  Or that the system has munged it, making it useless?
> Or that the server drops the connection as soon as you try, without
> telling you the reason is that it's run out of memory?
> Also, the RFB connection would be "locked up" for the duration of the
> transfer, which could be hours for a particularly large file and a
> slow connection.  On top of this, different OSes have differing
> amounts of meta-information associated with a file (some, such as the
> Mac, have entire extra data forks as well as file-type information)
> which it would usually be a good idea to preserve in transit (even if
> it is ignored by the recipient).  Converting filename conventions is
> child's play compared to converting meta-information.
> A further "desirable feature" might be to allow multiple files to be
> transferred in a single session, without having to manually select
> new filenames and destinations for each one.  Fair enough, you can
> just as easily make a ZIP or StuffIt or tarball archive and transfer
> that, but what if the required tool isn't on the other end?
> (Different platforms again!)  Such a feature is easily handled by a
> sufficiently well-designed protocol, without excessive code bloat on
> either end of the connection.
> If you absolutely have to transfer stuff by the Clipboard, there are
> already tools which let you do that without inserting hacks on top of
> the RFB protocol.  Base64, UUencode, and so on will make an 8-bit
> file ASCII-clean for transfer.  Copy the result into the Clipboard,
> transfer it to the target, and decode it.  For something which
> everyone is supposed to implement, I want something cleaner than
> that, and fully cross-platform compatible.
> -- 
> --------------------------------------------------------------
> from:     Jonathan "Chromatix" Morton
> mail:     chromi "at"  (not for attachments)
> website:
> geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
> V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
> tagline:  The key to knowledge is not to rely on people to teach you it.
> ---------------------------------------------------------------------
> To unsubscribe, send a message with the line: unsubscribe vnc-list
> to majordomo "at"
> See also:
> ---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at"
See also: