wrong timestamp, outdated files & failing moves about go-mtpfs HOT 5 CLOSED

Further observation: when the rename fails i often (always?) see following error message from go-mtpfs ...
2013/11/13 11:33:25 basenameRename failed: RetCode 5218
2013/11/13 11:33:56 AndroidGetPartialObject64 failed: GeneralError
... and the problem seems that the source file is actually truncated before the move! (put differently, it seems the move/rename problem seems to be related that the preceeding write failed to complete)

BTW: this was running head of code (commit bb3f0c2 for go-mtpfs / bc17f6b7a8988d9233968501a32fddc15f617a20 for go-fuse)

from go-mtpfs.

there are other errors i get from basenameRename failures, e.g., RetCode 9278. But again the problems seems to have happened before: the source file seems to exist from a directory perspective, e.g., it is visible with ls but also catting it results in Input/output error and AndroidGetPartialObject64 visible in the go-mtpfs output. Also interesting is that go-mtpfs wrote ``182227 bytes in 45.091926ms: 4 mb/s'' but ls -l shows the file size as 182228!! maybe some off-by-one error?

from go-mtpfs.

To me it seems like not all file extensions are supported. I also can't e.g. see .db or .dat files stored on the Android device.

This is consistent with other mtpfs implementations, so MTP may be at fault here.

My personal workaround is to append .txt to file extensions. Apparently this seems safe, as Android does no CRLF transformation of that or the like. Hope it stays that way.

from go-mtpfs.

I've encountered the incorrect handling of the timezone, too. My locale time currently is GMT+03:00. When I copy ($ nemo --version: nemo 2.2.4) a file from a go-mtpfs-mounted folder, the copy gets a modification time 3 hours later than that of the original file.

from go-mtpfs.

closing due to age.

from go-mtpfs.