Mv `Argument list too long` for a single file

bugsfilesosxvfat

I was trying to move a set of 7 files to my computer, via mv g* dir. The command line moved 6 of them, and for the last file gave the following error:

mv: g.tex: Argument list too long

Since the other files, both those before and after it, are already moved, I tried mv g.tex dir. Same error. Moving other files works fine. (Note: g.tex is a file, not a directory.)

Update: Renaming the file via mv also works fine; moving it to another directory on the USB drive also works fine. However, even when I rename it, or move it to another directory on the USB drive, I still cannot move it to my computer.

I tried to cat this file, to copy its contents to the desktop:

cat: g.tex: Argument list too long

What else might be causing this problem?

Update: after comparing output of dtruss with a file which successfully moved, here are the lines of the log which differ:

read(0x3, "\0", 0x20000)         = -1 Err#7
write_nocancel(0x2, "mv: \0", 0x4)       = 4 0
getrlimit(0x1008, 0x7FFF5A00BC78, 0x4)       = 0 0
write_nocancel(0x2, "g.tex\0", 0x5)      = 5 0
write_nocancel(0x2, ": \0", 0x2)         = 2 0
write_nocancel(0x2, "Argument list too long\n\0", 0x17)      = 23 0
unlink("/Users/username/Desktop/Tex/g.tex\0", 0x7FFF5A00B8A0, 0x17)      = 0 0
close(0x3)       = 0 0

From the list of Unix error codes for read:

#define E2BIG        7  /* Argument list too long */

On a successful move, it displays instead:

read(0x3, "Beginning of file contents...", 0x20000)      = 0 0
fstat64_extended(0x3, 0x7FF1F5C02568, 0x7FF1F5C02660)        = 0 0
fstat64(0x4, 0x7FFF5A653EF0, 0x7FF1F5C02660)         = 0 0
fchmod(0x4, 0x180, 0x7FF1F5C02660)       = 0 0
__mac_syscall(0x7FFF8E670D02, 0x52, 0x7FFF5A653E70)      = -1 Err#93
flistxattr(0x4, 0x0, 0x0)        = 0 0
flistxattr(0x3, 0x0, 0x0)        = 23 0
flistxattr(0x3, 0x7FF1F5C02490, 0x17)        = 23 0
fgetxattr(0x3, 0x7FF1F5C02490, 0x0)      = 11 0
fgetxattr(0x3, 0x7FF1F5C02490, 0x7FF1F6001000)       = 11 0
fsetxattr(0x4, 0x7FF1F5C02490, 0x7FF1F6001000)       = 0 0
fstat64_extended(0x4, 0x7FFF5A653628, 0x7FF1F5C02660)        = 0 0
fchmod_extended(0x4, 0xFFFFFF9B, 0xFFFFFF9B)         = 0 0
fchmod(0x4, 0x0, 0xFFFFFF9B)         = 0 0
close(0x3)       = 0 0
fchown(0x4, 0x6300000063, 0x63)      = 0 0
fchmod(0x4, 0x81FF, 0x63)        = 0 0
fchflags(0x4, 0x0, 0x63)         = 0 0
utimes("/Users/aleksander/Desktop/Tex/new_filename\0", 0x7FFF5A654860, 0x63)         = 0 0

Just in case this helps, the remainder of the lines, which match for a successful mv command and for the failed one, right before the differing text quoted above:

open("/dev/dtracehelper\0", 0x2, 0x7FFF53E619B0)         = 3 0
ioctl(0x3, 0x80086804, 0x7FFF53E61938)       = 0 0
close(0x3)       = 0 0
thread_selfid(0x3, 0x80086804, 0x7FFF53E61938)       = 167920154 0
bsdthread_register(0x7FFF8E8710F4, 0x7FFF8E8710E4, 0x2000)       = 1073741919 0
ulock_wake(0x1, 0x7FFF53E6116C, 0x0)         = -1 Err#2
issetugid(0x1, 0x7FFF53E6116C, 0x0)      = 0 0
mprotect(0x10BDA5000, 0x88, 0x1)         = 0 0
mprotect(0x10BDA7000, 0x1000, 0x0)       = 0 0
mprotect(0x10BDBD000, 0x1000, 0x0)       = 0 0
mprotect(0x10BDBE000, 0x1000, 0x0)       = 0 0
mprotect(0x10BDD4000, 0x1000, 0x0)       = 0 0
mprotect(0x10BDD5000, 0x1000, 0x1)       = 0 0
mprotect(0x10BDA5000, 0x88, 0x3)         = 0 0
mprotect(0x10BDA5000, 0x88, 0x1)         = 0 0
getpid(0x10BDA5000, 0x88, 0x1)       = 28838 0
stat64("/AppleInternal/XBS/.isChrooted\0", 0x7FFF53E61028, 0x1)      = -1 Err#2
stat64("/AppleInternal\0", 0x7FFF53E610C0, 0x1)      = -1 Err#2
csops(0x70A6, 0x7, 0x7FFF53E60B50)       = 0 0
sysctl([CTL_KERN, 14, 1, 28838, 0, 0] (4), 0x7FFF53E60CA8, 0x7FFF53E60CA0, 0x0, 0x0)         = 0 0
ulock_wake(0x1, 0x7FFF53E610D0, 0x0)         = -1 Err#2
csops(0x70A6, 0x7, 0x7FFF53E60430)       = 0 0
stat64("/Users/aleksander/Desktop/Tex\0", 0x7FFF53E62B88, 0x7FFF53E60430)    = 0 0
lstat64("g.tex\0", 0x7FFF53E62AF8, 0x7FFF53E60430)       = 0 0
lstat64("/Users/aleksander/Desktop/Tex\0", 0x7FFF53E62A68, 0x7FFF53E60430)   = 0 0
stat64("g.tex\0", 0x7FFF53E62AF8, 0x7FFF53E60430)        = 0 0
stat64("/Users/aleksander/Desktop/Tex/g.tex\0", 0x7FFF53E62A68, 0x7FFF53E60430) = -1 Err#2
access("/Users/aleksander/Desktop/Tex/g.tex\0", 0x0, 0x7FFF53E60430)         = -1 Err#2
rename("g.tex\0", "/Users/aleksander/Desktop/Tex/g.tex\0")       = -1 Err#18
stat64("/\0", 0x7FFF53E5FB60, 0x7FFF53E60430)        = 0 0
open_nocancel(".\0", 0x0, 0x1)       = 3 0
fstat64(0x3, 0x7FFF53E5F900, 0x1)        = 0 0
fcntl_nocancel(0x3, 0x32, 0x7FFF53E61980)        = 0 0
close_nocancel(0x3)      = 0 0
stat64("/Volumes/NO NAME\0", 0x7FFF5A00A870, 0x7FFF5A00C980)         = 0 0
stat64("/Volumes/NO NAME\0", 0x7FFF5A00AB60, 0x7FFF5A00C980)         = 0 0
getattrlist("/Volumes/NO NAME/g.tex\0", 0x7FFF8E715B04, 0x7FFF5A00C470)      = 0 0
statfs64(0x7FFF5A00C980, 0x7FFF5A00CD88, 0x7FFF5A00C470)         = 0 0
lstat64("g.tex\0", 0x7FFF5A00C8F0, 0x7FFF5A00C470)       = 0 0
open("g.tex\0", 0x0, 0x0)        = 3 0
open("/Users/aleksander/Desktop/Tex/g.tex\0", 0xE01, 0x0)        = 4 0
fstatfs64(0x4, 0x7FFF5A00BFF8, 0x0)      = 0 0

xattr -l g.tex doesn't give any output.
ls -l g.tex yields:

-rwxrwxrwx 1 username staff 159939 Aug 15 11:54 g.tex

mount yields:

/dev/disk5s1 on /Volumes/NO NAME (msdos, local, nodev, nosuid, noowners)

Best Answer

E2BIG is not one of the errors that read(2) may return. It looks like a bug in the kernel.

Pure speculation, but it could be down to some corruption on the file system and the macOS driver for the FAT filesystem returning that error upon encountering that corruption which eventually makes it through to the return of read.

In any case, it looks like you've taken the investigation as far as it gets. Going further would require dissecting the file system and the kernel driver code.

You could have a look at the kernel logs to see if there's more information there. You could try mounting the FS on a different OS. Or use the GNU mtools to access that FAT filesystem.

You could also report the problem to Apple as at least a documentation issue (to include E2BIG as one of the possible error codes, and the conditions upon which it may be returned).

Related Solutions

What does this zsh solution to “the argument list is too long” do

The best way, to look at zsh documentation is using info.

If you run info zsh, you can use the index (think of a book's index) to locate the section that describes the zmodload command.

Press i, then you can enter zmo and press Tab. You'll get straight to the zmodload builtin description which will tell you all about it.

In short, zmodload -F loads the module (if not loaded) and enables only the specified features from that module.

With -m, we enabled the features that match a pattern, here b:zf_*. b: is for builtin, so the above command loads the zsh/files module (see info -f zsh -n 'The zsh/files Module,' for details on that) and only enables the builtins whose name starts with zf_.

zmodload -F zsh/files

loads the module, but doesn't enable any feature:

$ zmodload -FlL zsh/files
zmodload -F zsh/files -b:chgrp -b:chown -b:ln -b:mkdir -b:mv -b:rm -b:rmdir -b:sync -b:zf_chgrp -b:zf_chown -b:zf_ln -b:zf_mkdir -b:zf_mv -b:zf_rm -b:zf_rmdir -b:zf_sync

lists the features of that module specifying which are currently enabled (none for now). You'll notice there's both a mv and zf_mv builtin.

$ zmodload -mF zsh/files 'b:zf_*'
$ zmodload -FlL zsh/files
zmodload -F zsh/files -b:chgrp -b:chown -b:ln -b:mkdir -b:mv -b:rm -b:rmdir -b:sync +b:zf_chgrp +b:zf_chown +b:zf_ln +b:zf_mkdir +b:zf_mv +b:zf_rm +b:zf_rmdir +b:zf_sync

You'll notice the zf_mv builtin has been enabled, but not the mv one (same for the other builtins). That means, those builtin versions of the system commands have been enabled, but without overriding the system one:

$ type zf_mv
zf_mv is a shell builtin
$ type mv
mv is /bin/mv

Now that you have a builtin mv, as zf_mv, not mv, you can do:

zf_mv -- ^*.(jpg|png|bmp) targetdir/

Because zf_mv is builtin, there's no execve() system call, so you won't hit the Too many args limit associated with it.

Of course, you can also do:

zmodload zsh/files # without -F, all the features are enabled
mv -- ^*.(jpg|png|bmp) targetdir/

But beware that replaces the system's mv with zsh builtin equivalent.

To overcome the E2BIG execve() error (the Too many args upon executing an external command), zsh also provides with a zargs function.

You run:

autoload zargs # in ~/.zshrc if you use it often

To mark it for autoloading.

Then you can use:

zargs -- ^*.(jpg|png|bmp) -- mv -t targetdir/

(here assuming GNU mv for the -t option). zargs will run as many mv commands as necessary to avoid the E2BIG (as xargs would do).

Shell – /bin/ls: Argument list too long

Don’t parse the output of ls. Just say foreach f (*). Also,
You should always quote your shell variable references (e.g., "$f") unless you have a good reason not to, and you’re sure you know what you’re doing.

Best Answer

Related Solutions

What does this zsh solution to “the argument list is too long” do

Shell – /bin/ls: Argument list too long

Related Question