1 |
on 2012-12-21 at 23:20 Neil Bothwick wrote: |
2 |
|
3 |
> No, and there's a good reason for that. |
4 |
|
5 |
well, i'm glad to know that there's a good reason to use MTP, because what |
6 |
i've read so far about it made me wonder... |
7 |
|
8 |
from the link mark sent earlier: |
9 |
|
10 |
<quote> |
11 |
libmtp (and I assume the MTP protocol itself) doesn’t support seeking |
12 |
within a file or partial file reads or writes. You have to fetch or send |
13 |
the entire file. To simluate normal random access files, when a file is |
14 |
opened the entire file contents are copied from the device to a temporary |
15 |
file. Reads and writes then operate on the temporary file. When the file |
16 |
is closed (or if a flush or fsync occurs) then if a write has occurred |
17 |
since the file was last opened the entire contents of the temporary file |
18 |
are sent back to the device. This means repeatedly opening a file, making |
19 |
a small change, and closing it again will be very slow. |
20 |
|
21 |
Renaming or moving a file is implemented by copying the file from the |
22 |
device, writing it back to the device under the new name, and then |
23 |
deleting the original file. This makes renames, especially for large |
24 |
files, slow. This has special significance when using rsync to copy files |
25 |
to the device. Rsync copies to a temporary file, and then when the copy is |
26 |
complete it renames the temporary file to the real filename. So when |
27 |
rsyncing to a jmtpfs filessystem, for each file, the data gets copied to |
28 |
the device, read back, and then copied to the device again. There is a |
29 |
true rename (but not move) supported by libmtp, but this appears to |
30 |
confuse some Android apps, so I don’t use it. Image files, for example, |
31 |
will disappear from the Gallery if they’re renamed. |
32 |
</quote> |