Darren Reed <[EMAIL PROTECTED]> wrote:
> > Wrt. to standards, quote from:
> >
> > http://www.opengroup.org/onlinepubs/009695399/functions/rename.html
> >
> > ERRORS
> > The rename() function shall fail if:
> > [ ... ]
> > [EXDEV]
> > [CX] The links named by new and old are on different file systems
> > and the
> > implementation does not support links between file systems.
> >
> > Hence, it's implementation-dependent, as per IEEE1003.1.
>
> This implies that we'd also have to look at allowing
> link(2) to also function between filesystems where
> rename(2) was going to work without doing a copy,
> correct? Which I suppose makes sense.
Thank you for mentioning this.
This brings us closer to the demand that st_dev/st_ino need to be
kept during a rename.
Basically, rename has been introduced in order to avoid a privileged
link(2)/unlink(2) on directories in order to rename directories. For this
reason, I would expect a rename(2) to work similar to a link/unlink
chain.
Something that I should mention also is that there may be programs
that rename open files and asume traditional st_dev/st_ino semantic in case
that rename worked.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
