From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D52D81381F3 for ; Sat, 22 Dec 2012 12:20:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4654421C05C; Sat, 22 Dec 2012 12:20:08 +0000 (UTC) Received: from mail-ea0-f173.google.com (mail-ea0-f173.google.com [209.85.215.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1FE7CE05D9 for ; Sat, 22 Dec 2012 12:18:58 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id i13so2339956eaa.32 for ; Sat, 22 Dec 2012 04:18:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:subject:message-id:in-reply-to:references :organization:x-mailer:mime-version:content-type :content-transfer-encoding; bh=XN9rfaflODo9W4ZmNZ3UWnDvQg4CzcXQZzj4YXoeUXc=; b=svBfIAzcJddIARd2AOElaw/aI5K9d/fnBhODQq9RuDCTVDT127DXQrXjpD6H5nu7xE jyiuDY/tv7gjB+JLttqffKyor8hpXVS+2v7O5MJwE3xV4b75b351Pi43be3tFArpmOlB WUBFDz/z/xaFZoQ/z7NNQc67xQ6UxlV1wc19SZsn7ohd8YdazSCeNAQsBDQv7vi6+3FO VDw+8x85TI63A3v5F3wbxp6Pweit/2L2Yv8FqBxHv0IgZZdoLU0Oq00ZPCFX8EEdPJxj N3QjNCZM8RMZFWufa9dT15V7NKRsMlubR8h/4Lh65Dj8htD2Q9nQPLLKS1/vG2hfUcp5 xbUw== X-Received: by 10.14.207.195 with SMTP id n43mr39364130eeo.38.1356178737622; Sat, 22 Dec 2012 04:18:57 -0800 (PST) Received: from khamul.example.com (196-215-209-117.dynamic.isadsl.co.za. [196.215.209.117]) by mx.google.com with ESMTPS id z8sm27894777eeo.11.2012.12.22.04.18.54 (version=SSLv3 cipher=OTHER); Sat, 22 Dec 2012 04:18:56 -0800 (PST) Date: Sat, 22 Dec 2012 14:15:12 +0200 From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] android and mtp Message-ID: <20121222141512.2c2dbfef@khamul.example.com> In-Reply-To: <20121222100137.2a21405c@acme7.acmenet> References: <20121221195656.217987ce@acme7.acmenet> <20121221232036.6df0fd1f@digimed.co.uk> <20121222100137.2a21405c@acme7.acmenet> Organization: Internet Solutions X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.14; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: a60ace02-5129-4b8d-b1fc-fb0ac9878312 X-Archives-Hash: 795caaa8f6938bb4023b0b9354a2ef0c On Sat, 22 Dec 2012 10:01:37 -0200 luis jure wrote: >=20 > on 2012-12-21 at 23:20 Neil Bothwick wrote: >=20 > > No, and there's a good reason for that. >=20 > well, i'm glad to know that there's a good reason to use MTP, because > what i've read so far about it made me wonder... It all becomes understandable when you figure out what MTP actually is. It's Media Transfer Protocol, it's not eg Media Transfer Filesystem. Wiki tells you some more: http://en.wikipedia.org/wiki/Media_Transfer_Protocol So it's a protocol for getting an entire file (originally usually an mp3) from storage to a device that would play it. It makes sense to copy the entire file to an mp3 player then play it, seeks would not involve network (or bus) traffic. Consider that http also doesn't let you usually transfer bits of files. That protocol is also happier giving you all or nothing (yes, you can do partial downloads, but that's not really a seek action, it's a once-off action to say where the start of the copy happens from. >=20 > from the link mark sent earlier: >=20 > > libmtp (and I assume the MTP protocol itself) doesn=E2=80=99t support see= king > within a file or partial file reads or writes. You have to fetch or > send the entire file. To simluate normal random access files, when a > file is opened the entire file contents are copied from the device to > a temporary file. Reads and writes then operate on the temporary > file. When the file is closed (or if a flush or fsync occurs) then if > a write has occurred since the file was last opened the entire > contents of the temporary file are sent back to the device. This > means repeatedly opening a file, making a small change, and closing > it again will be very slow. >=20 > Renaming or moving a file is implemented by copying the file from the > device, writing it back to the device under the new name, and then > deleting the original file. This makes renames, especially for large > files, slow. This has special significance when using rsync to copy > files to the device. Rsync copies to a temporary file, and then when > the copy is complete it renames the temporary file to the real > filename. So when rsyncing to a jmtpfs filessystem, for each file, > the data gets copied to the device, read back, and then copied to the > device again. There is a true rename (but not move) supported by > libmtp, but this appears to confuse some Android apps, so I don=E2=80=99t= use > it. Image files, for example, will disappear from the Gallery if > they=E2=80=99re renamed. >=20 --=20 Alan McKinnon alan.mckinnon@gmail.com