Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #244820 > unrolled thread

why copying big file fails?

Back to article view | Back to linux.debian.user

Contents

  why copying big file fails? a <loushanguan2015@sina.com> - 2022-01-30 21:20 +0100
    Re: why copying big file fails? "Andrew M.A. Cater" <amacater@einval.com> - 2022-01-30 21:20 +0100
      Re: why copying big file fails? a <loushanguan2015@sina.com> - 2022-01-30 21:40 +0100
        Re: why copying big file fails? "Andrew M.A. Cater" <amacater@einval.com> - 2022-01-30 22:00 +0100
        Re: why copying big file fails? "Thomas Schmitt" <scdbackup@gmx.net> - 2022-01-30 23:00 +0100
    Re: why copying big file fails? ghe2001 <ghe2001@protonmail.com> - 2022-01-30 21:30 +0100
      Re: why copying big file fails? a <loushanguan2015@sina.com> - 2022-01-31 00:00 +0100
    Re: why copying big file fails? Reco <recoverym4n@enotuniq.net> - 2022-01-30 22:10 +0100
      Re: why copying big file fails? Hans <hans.ullrich@loop.de> - 2022-01-30 22:30 +0100
        Re: why copying big file fails? Reco <recoverym4n@enotuniq.net> - 2022-01-31 07:20 +0100
      Re: why copying big file fails? Michael Stone <mstone@debian.org> - 2022-01-31 16:20 +0100
        Re: why copying big file fails? lou <loushanguan2015@sina.com> - 2022-01-31 22:20 +0100

#244820 — why copying big file fails?

i create video mp4 with android's screen-recorder, it's about 4G

i connect it to debian with jmtpfs and copy it to ext4 hard disk with 
more than 10G  of free space

it fails: cp: error reading 
'DCIM/ScreenRecorder/Screenrecorder-2022-01-30-12-29-58-111.mp4': 
Invalid argument

i run "ls -l", about 2G has been copied

i've play this mp4 using android, didn't meet reading error

BTW which package in bullseye can play mp4? mplayer has failed, and some 
player require gnome , but i haven't installed gnome

[toc] | [next] | [standalone]

#244822

On Sun, Jan 30, 2022 at 03:11:36PM -0500, a wrote:
> i create video mp4 with android's screen-recorder, it's about 4G
> 
> i connect it to debian with jmtpfs and copy it to ext4 hard disk with more
> than 10G  of free space
> 
> it fails: cp: error reading
> 'DCIM/ScreenRecorder/Screenrecorder-2022-01-30-12-29-58-111.mp4': Invalid
> argument
> 
> i run "ls -l", about 2G has been copied
> 
> i've play this mp4 using android, didn't meet reading error
> 
> BTW which package in bullseye can play mp4? mplayer has failed, and some
> player require gnome , but i haven't installed gnome
> 
> 

How did you copy it? To a machine running what processor or architecture - 
amd64/i386/arm?

You may find that there's a file size issue somewhere there - can you
use scp and verify the transfer?

All the very best, as ever,

Andy Cater

[toc] | [prev] | [next] | [standalone]

#244824

Thank Andrew!

i connect android phone with jmtpfs and use cp command to copy it

i use bullseye for i386, intel core2 Q8200 2.33G

why shall i use scp? it's to be used for copying between hosts

[toc] | [prev] | [next] | [standalone]

#244825

On Sun, Jan 30, 2022 at 03:32:47PM -0500, a wrote:
> Thank Andrew!
> 
> i connect android phone with jmtpfs and use cp command to copy it
> 
> i use bullseye for i386, intel core2 Q8200 2.33G
> 
> why shall i use scp? it's to be used for copying between hosts
>

Because scp will verify transfers as it copies.

if you've got i386, you may have hit something with a 2G file limit is
my guess.

I'm more used to using 64 bit OS these days.

All the very best, sa ever,

Andy Cater 

[toc] | [prev] | [next] | [standalone]

#244829

Hi,

a <loushanguan2015@sina.com> wrote:
> it fails: cp: error reading
> 'DCIM/ScreenRecorder/Screenrecorder-2022-01-30-12-29-58-111.mp4': Invalid
> argument
>
> i run "ls -l", about 2G has been copied

> i use bullseye for i386, intel core2 Q8200 2.33G

That's a machine whiere type "long" has 32 bit. I.e. the non-negative
range is 0 to 2,147,483,647.

2 GB limits are usually due to call fseek(3)

       int fseek(FILE *stream, long offset, int whence);
       ...
       EINVAL The whence argument to fseek() was not  SEEK_SET,  SEEK_END,  or
              SEEK_CUR.  Or: the resulting file offset would be negative.

So it would match the error message if the fseek offset value surpassed
2,147,483,647 bytes.

The seek() method of jmtpfs class MtpLocalFileCopy uses fseek(3):
  https://sources.debian.org/src/jmtpfs/0.5-3/src/MtpLocalFileCopy.cpp/?hl=90#L90
It is used by the Read() method of MtpFile
  https://sources.debian.org/src/jmtpfs/0.5-3/src/MtpFile.cpp/?hl=71#L71
So it would be plausible that this is the place where "Invalid argument"
comes from.


What happens if you try a program that is less suspicious of using
random access reading ?
Like:

  cat </the/jmtpfs/file/path >/the/ext4/file/path


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#244823

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256




‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, January 30, 2022 1:11 PM, a <loushanguan2015@sina.com> wrote:

> BTW which package in bullseye can play mp4? mplayer has failed, and some
> player require gnome , but i haven't installed gnome

I'm still on Buster (XFCD4), but have you tried VLC?

--
Glenn English



-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsBzBAEBCAAGBQJh9vRgACEJEJ/XhjGCrIwyFiEELKJzD0JScCVjQA2Xn9eG
MYKsjDJEBgf/U+K4wJ3wGcH4Twc4oUtnL6Gx2hQPQDihssZmO4sBKLwQPCXp
ko8B0qReYf/dFCLpILfIvCtC8j2F4V+gyvHd48RGTWYuaqZLXfO7w4VW/E34
c/nbIcAQw7KijxxGTXu+cYsSw5Rurce04vxLHiweHoY64I3+sBVrOvt76Hqz
C2O+iwBjqJapSemLUw0kEGQVPZJ5NtVVcH4zVekHOpwn0UyKkuPu4WJlNYU8
FTLKMk6fa+xaSKd60R5TP/eCoTTuY4qkCwoo9ixNs/TNsq+s3ZeypgAxawn/
b3vN+azQ+paT/cDjW+hcU7xE7+5DASeUiDyNs4ByFI1Utv3d4EHRLQ==
=e0wL
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#244830

Thank ghe2001, Andrew, Reco, Hans and Thomas!

i try bullseye for amd64, as Andrew suggest, it succeeds in copying 4G 
mp4 video

transfer speed is slow, i have to wait for half an hour after entering 
cp command

and i can't check progress by running "ls -l" in other terminal

("ls -l" shows new file hasn't been created)


actually mplayer can play mp4, there's some error msg when i resize 
window, but it's not important

surely it can't play incomplete mp4 file (2G instead of 4G)

[toc] | [prev] | [next] | [standalone]

#244826

	Hi.

On Sun, Jan 30, 2022 at 03:11:36PM -0500, a wrote:
> i run "ls -l", about 2G has been copied

This. Method you're using for copying files does not matter.
Whatever your phone is using instead of a proper filesystem does.
2G file size limit is typical for FAT, and chances are it's exactly what
your phone uses.

There's no way around it, probably even if you root your phone.

Split your file in chunks, that's how it will work.


> BTW which package in bullseye can play mp4?

mpv or vlc. Everything else is not a media player anyway.

Reco

[toc] | [prev] | [next] | [standalone]

#244827

Am Sonntag, 30. Januar 2022, 21:53:00 CET schrieb Reco:

> > BTW which package in bullseye can play mp4?
> 
> mpv or vlc. Everything else is not a media player anyway.
> 
> Reco

Hmm.......

I had very good success with smplayer on slower computers. Some files ran 
fluently whilst they lagged with vlc, eveen on opengl accelerated graphic 
card. (VLC supports opengl drivers).

So I would not say, others are no mediaplayers. 

Aso XINE looks like a good player, too, or kaffeine. However, XINE got an 
awful gui and kaffeine might not be installed, when using something elese than 
plasma5.

Best

Hans
 

[toc] | [prev] | [next] | [standalone]

#244847

	Hi.

On Sun, Jan 30, 2022 at 10:23:12PM +0100, Hans wrote:
> Am Sonntag, 30. Januar 2022, 21:53:00 CET schrieb Reco:
> 
> > > BTW which package in bullseye can play mp4?
> > 
> > mpv or vlc. Everything else is not a media player anyway.
> 
> Hmm.......
> I had very good success with smplayer on slower computers.

An mpv or mplayer frontend. Most probably you've used mpv one, it's
listed first in the Depends list.

> So I would not say, others are no mediaplayers. 

Everyone should be allowed some exaggeration now and then, me included
:)
Let me say it another way - if one needs a mediaplayer that will play
everything one throws at it, and wants to disregard assorted frontends
available - there are exactly two choices. First is mpv, and second is
vlc.

> Aso XINE looks like a good player,

That's its appearance, indeed. Subject to change once one starts using
the thing.

> too, or kaffeine.

It's KDE VLC frontend.

Reco

[toc] | [prev] | [next] | [standalone]

#244865

On Sun, Jan 30, 2022 at 11:53:00PM +0300, Reco wrote:
>	Hi.
>
>On Sun, Jan 30, 2022 at 03:11:36PM -0500, a wrote:
>> i run "ls -l", about 2G has been copied
>
>This. Method you're using for copying files does not matter.
>Whatever your phone is using instead of a proper filesystem does.
>2G file size limit is typical for FAT, and chances are it's exactly what
>your phone uses.

File size limit for FAT is 4GByte, not 2GByte. Clearly, if he has a 
4GByte file on the phone, a 2GByte filesystem limit is not the issue.

i386 (32bit) debian can also work just fine with files of 4GByte. Where 
you run into issues is if a 32bit program also uses 32bit offsets when 
working with files (there is a build time option to use 64bit offsets in 
32bit programs, while 64bit programs always use 64bit offsets). Probably 
what is happening is that something in the chain of fuse, libmtpfs, and 
jmtpfs is constraining the size of a file to 2GByte because it is using 
a 32bit offset where it needs a 64bit one. Using the amd64 version of 
debian will avoid that issue (and is better in essentially all real 
cases when possible). It may be possible to find and fix whatever is 
causing the 32bit version to fail, but the number of people trying to 
open files > 2GByte via mtp on i386 debian is probably really, reallly 
small so there's probably not a large pool of people willing to dig into 
that. (And if the program is trying to mmap the file, it will never work 
for large files on i386 because there isn't enough address space.)

The OP might try go-mtpfs as an alternative to jmtpfs, both on i386 to 
see if it avoids the 2GByte limit, as well as on amd64 to see if it 
performs better. I bounce between jmtpfs and go-mtpfs, with each
sometimes working better and sometimes working worse.

[toc] | [prev] | [next] | [standalone]

#244884

Thank Michael! i install go-mtpfs for i386 and it can copy 4G file, and 
i can check progress with "ls -l"

strange thing about go-mtpfs is you'd better add & at end of command

go-mtpfs seems faster than jmtpfs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web