Setting window title in 10.10 breaks `ls` on FAT32 mount points?

I and a couple other users are seeing some weird behavior with respect to setting the window title and subsequent ls commands. On OS X 10.10 Mavericks, if you are in a directory which is the mount point for a FAT32 filesystem, and you set the window title using the \e]2;title\a escape sequence, an immediate ls command will produce incorrect output or error out.

iTerm2 Version 2.1.1. Also tested on iTerm 2.0 and iTerm 2.9.20150626 beta; they show the same behavior. OS X 10.10.4. Have also seen it reported on OS X 10.10.2.

I found this from a report by an Oh My Zsh user: https://github.com/robbyrussell/oh-my-zsh/issues/4161.

Do you know what could be causing this? I am rather baffled.

Reproduction

To reproduce:

• Using Disk Utility, create a DMG disk image of 100 MB that contains a FAT32 filesystem called "DISK IMAGE". (The name isn't important.)
• Double-click the .dmg file to mount it.
• Open a new iTerm2 window that is running bash or zsh
• cd /Volumes/DISK\ IMAGE
• printf "\e]2;foobar\a"
• ls or ls -l
• ls

The first ls command will produce incorrect output, either listing "." for plain ls, or ls: .: Invalid argument for ls -l.

taran-yos:~ janke$ cd /Volumes/DISK\ IMAGE/
taran-yos:DISK IMAGE janke$ ls
bar	foo	subdir
taran-yos:DISK IMAGE janke$ printf "\e]2;foobar\a"
taran-yos:DISK IMAGE janke$ ls
.
taran-yos:DISK IMAGE janke$ ls
bar	foo	subdir
taran-yos:DISK IMAGE janke$ printf "\e]2;foobar\a"
taran-yos:DISK IMAGE janke$ ls -l
ls: .: Invalid argument
taran-yos:DISK IMAGE janke$ ls -l
total 4
-rwxrwxrwx  1 janke  staff     0 Jul 17 03:24 bar
-rwxrwxrwx  1 janke  staff     0 Jul 17 03:24 foo
drwxrwxrwx  1 janke  staff  2048 Jul 17 03:29 subdir
taran-yos:DISK IMAGE janke$

Diagnosis

Doesn't happen on OS X 10.9.

This seems to be specific to iTerm2. I've tried Terminal.app, xterm, and urxvt on OS X, and they don't show this breakage. Also tried xterm, urxvt, Konsole, and GNOME Terminal on Debian 7. None of them showed the weird behavior either.

The find and du commands will break similarly to ls.

Only seems to happen with FAT32 ("MS-DOS (FAT)") filesystems. Doesn't happen with HFS+ or exFAT filesystems.

com.googlecode.iterm2.plist

Title changed from Setting window title in 10.10 breaks ls on FAT32 mount points to Setting window title in 10.10 breaks ls on FAT32 mount points?

This is the weirdest bug report I've seen in a long time. Can't wait to dig in.

Milestone changed to Ship 3.0

I don't have to do printf to get ls to break in a disk image. Just running ls twice or three times does it, and it happens for me in either Terminal or iTerm2. The OS appears to be broken :(

Status changed to closed

I can confirm that it happens in Terminal, too: after switching from zsh to bash in Terminal, I can reliably reproduce it there.

mentioned in issue #4519 (closed)