[G Tablet Q&A, Help & Troubleshooting] rajeevvp:
Here's my /system/etc/vold.fstab in its entirely. With this, my tablet uses the internal SD card as the default for storage.

## Vold 2.0 NVIDIA Harmony fstab

#######################
## Regular device mount
##
## Format: dev_mount <label> <mount_point> <part> <sysfs_path1...>
## label - Label for the volume
## mount_point - Where the volume will be mounted
## part - Partition # (1 based), or 'auto' for first usable partition.
## <sysfs_path> - List of sysfs paths to source devices
######################

#dev_mount sdcard /mnt/sdcard auto /devices/platform/tegra-sdhci.3/mmc_host/mmc0 /devices/platform/tegra-sdhci.3/mmc_host/mmc1
# dev_mount sdcard /mnt/sdcard auto /devices/platform/tegra-sdhci.2/mmc_host/mmc1
# dev_mount emmc /mnt/emmc auto /devices/platform/tegra-sdhci.3/mmc_host/mmc2

dev_mount sdcard /mnt/sdcard auto /devices/platform/tegra-sdhci.3/mmc_host/mmc2
dev_mount emmc /mnt/emmc auto /devices/platform/tegra-sdhci.2/mmc_host/mmc1
dev_mount usbdisk /mnt/usbdisk auto /devices/platform/tegra-ehci

Ah, OK. The reason for the difference is due to the way the move is actually implemented in File Manager and Root Explorer.

I had an idea about why File Manager couldn't move files across filesystems, and to confirm my suspicion I attached strace to a running File Manager:

$ su
# strace -e rename -p `pidof org.openintents.filemanager`
Process 28466 attached - interrupt to quit

[I]lots of irrelevant output omitted[/I]

rename("/mnt/sdcard/Kernel/Pershoot/lib-2632.40_gb.tar.gz", "/data/local/tmp/lib-2632.40_gb.tar.gz") = -1 EXDEV (Cross-device link)

[I]more irrelevant output omitted[/I]

File Manager calls the rename() system call to move the lib-2632.40_gb.tar.gz file, which, as the spec says, will fail in this case. The program is then supposed to do the move the old-fashioned way if rename() returns an EXDEV error: copy file1 to file2 by reading bytes from file1 and writing bytes into file2; then delete file1 if the copy is successful.

But, File Manager doesn't perform this very basic fallback step. It throws up its hands at the first error and spits out the error message you got. And, it's not just File Manager. The system mv command (if you have it) in /system/bin also exhibits the same dumb behaviour. The busybox mv is more robust. (You should actually report this as a bug to the File Manager people.)

Which brings us to Root Explorer. I got curious about it after the experiment with File Manager. RE handles cross-device moves just fine. What's more, it also moves entire directory trees across devices. Having written directory tree-moving programs before, I know that this is a non-trivial bit of programming. So, I ran strace on Root Explorer to see how it handled things, and the result made me laugh.

$ su
# strace -f -e execve `pidof com.speedsoftware.rootexplorer`
Process 3602 attached with 12 threads - interrupt to quit

[I]lots of irrelevant output omitted[/I]

10893 execve("/system/xbin/busybox", ["busybox"..., "cp"..., "-pr"..., "/sdcard/Kernel/Pershoot/lib-2632"..., "/data/local/tmp/lib-2632.40_gb.t"...], [/* 19 vars */] <unfinished ...>
10893 <... execve resumed> ) = 0
10914 execve("/system/xbin/rm", ["rm"..., "-r"..., "/sdcard/Kernel/Pershoot/lib-2632"...], [/* 19 vars */] <unfinished ...>
10914 <... execve resumed> ) = 0

[I]more irrelevant output omitted[/I]

Root Explorer is also taking the easy way out: It's actually using busybox to do (almost) all of its work.

I suspected this when I compiled a new version of busybox a few days ago to test out a new compiler toolchain. I moved the newly compiled busybox into /system/xbin without properly testing it first, and discovered that most of the commands died with segfault errors.

I re-uploaded the working version of busybox back onto the tablet in /mnt/sdcard/download, and then went into Root Explorer to move this busybox into /system/xbin, and RE started force closing on every action. Once I had managed to replace busybox through other means, RE started working fine again. At that time, I didn't look at the issue too closely--I thought it was just another example of the random lossage that Android exhibits from time to time. Now I know why.