[plt-scheme] Cross device link?

On Thu, Mar 08, 2007 at 01:12:40PM -0600, Robby Findler wrote:
> I'm not sure why it isn't handled, but the utility of the error number
> is probably the same as it would be in C -- a little more information
> about what's gone wrong. Probably reading some header file, equipped
> with that number, would tell you if, indeed, your theory is correct
> about why rename-file-or-directory failed.

The relevant header file is <errno.h> as specified in the 1999 ANSI/ISO C
standard.  (You'll likely have to chase #include pointers to the file where
the macros are actually defined.  Alternatively, just grep through
/usr/include and subdirectories for EINVAL.)

Unfortunately, that's not likely to get you more info that you already
have:

> On 3/8/07, Paulo J. Matos <pocm at soton.ac.uk> wrote:
> >Hello all,
> >
> >When using rename-file-or-directory I'm getting:
> >rename-file-or-directory: cannot rename file or directory:
> >/mnt/camera/dcim/100olymp/p3080001.jpg to:
> >/home/pmatos/fotos/pod/pod-832007.jpg (Invalid cross-device link; errno=18)
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^

The underlined text appears to be the output of strerror() for EXDEV.
errno.h is not likely to give you more information.

To find out what's going on, you need to figure out what system call is
signalling EXDEV and read its manpage.  Most Unix-like OSes come with
utilities that generate a log of the communications across the user/kernel
boundary for an arbitrary process, but the specific command and its
invocation differs widely from OS to OS.

I tried it on my desktop and discovered that the error is coming from the
rename system call (q.v.).  This is consistent with the documented behavior
of rename: src and destination must be in the same filesystem.

This is also consistent with the documented behavior of
rename-file-or-directory, at least in 369.8.  Since the two paths are on
different filesystems, it's throwing an exn:fail:filesystem.

Richard