fails with "Invalid cross-device link" if cwd is not same filesystem as $HOME

Hi Scott,

I've tested this in Maverick and can't reproduce this bug. I see that you already running natty, so that might be the reason why this is failing. Unfortunately, I don't have anything running natty just yet. I'll take a look at it again whenever I upgrade to natty, which should be in the next couple of weeks.

Also, could you please show the output aswell, such as:

roaksoax@shift:/tmp$ testdrive -u http://cdimage.ubuntu.com/daily/current/natty-alternate-i386.iso
INFO: version passed: False
INFO: config passed: None
INFO: Trying config in /etc/testdriverc
INFO: Using configuration in /etc/testdriverc
INFO: Trying config in /home/roaksoax/.testdriverc
INFO: Using configuration in /home/roaksoax/.testdriverc
INFO: Trying config in /home/roaksoax/.config/testdrive/testdriverc
INFO: Using KVM for virtual machine hosting...
INFO: Retrieving the Ubuntu ISO list from cache...
INFO: Syncing the specified ISO...
      http://cdimage.ubuntu.com/daily/current/natty-alternate-i386.iso
  HTTP/1.1 200 OK
#################### 100.0% 458.3 kBps DONE

No relevent local data found - I will be downloading the whole file. If that's not what you want, CTRL-C out. You should specify the local file is the old version of the file to download with -i (you might have to decompress it with gzip -d first). Or perhaps you just have no data that helps download the file
downloading from http://cdimage.ubuntu.com/daily/current/natty-alternate-i386.iso:
#################### 100.0% 1155.7 kBps DONE

verifying download...checksum matches OK
used 0 local, fetched 744520021
INFO: Validating Virtualization Method....
INFO: Setting up Virtual Machine...
Creating disk image [/home/roaksoax/.cache/testdrive/img/testdrive-disk-ShckFG.img]...
Formatting '/home/roaksoax/.cache/testdrive/img/testdrive-disk-ShckFG.img', fmt=qcow2 size=6442450944 encryption=off cluster_size=0
INFO: Launching Virtual Machine...
Running the Virtual Machine...
INFO: Cleaning up disk image [/home/roaksoax/.cache/testdrive/img/testdrive-disk-ShckFG.img]...
INFO: You may wish to clean up the cache directory...
      /home/roaksoax/.cache/testdrive/iso and /home/roaksoax/.cache/testdrive/img

Note, the subject of the bug says:
   if cwd is not same filesystem as home

I can reproduce this on a lucid server I have access to , so I suspect its also a bug on maverick.

the bug is actually in zsync, which is (i think) trying to create a hardlink.

$ df / /home
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda8 20650996 8295264 11306692 43% /
/dev/sda5 100791896 62157596 33514292 65% /home

$ cd /tmp
$ zsync http://cdimage.ubuntu.com/daily/current/natty-alternate-i386.iso.zsync -o /home/smoser/foo.iso
#################### 100.0% 541.5 kBps DONE

No relevent local data found - I will be downloading the whole file. If that's not what you want, CTRL-C out. You should specify the local file is the old version of the file to download with -i (you might have to decompress it with gzip -d first). Or perhaps you just have no data that helps download the file
rename: Invalid cross-device link
rename: Invalid cross-device link

This can be worked around in testdrive easily enough by changing the working directory to the target directory before invoking zsync.

Hi Scott,

Sorry for the delay. Could you please test this to see if it is fixed, with the following patch?

http://bazaar.launchpad.net/~testdrive/testdrive/trunk/revision/308

Thank you!

This appears fixed for me.

So, it looks like it is fixed, but I don't think that its a good idea to change the cwd in the testdrive.py . Changing of current working directory is an unexpected side effect of calling 'get_proto' that might break other things.

I would suggest only changing the working directory in the command string that is returned as in this patch.

This bug was fixed in the package testdrive - 3.3-0ubuntu1

---------------
testdrive (3.3-0ubuntu1) natty; urgency=low

  * Fix zsync failure if cwd is not same filesystem as $HOME (LP: #680138)
    - Thanks to Scott Moser for providing a better patch.
 -- Andres Rodriguez <email address hidden> Wed, 05 Jan 2011 14:38:11 -0500