New rename(2) function

Corinna Vinschen
Wed Aug 1 14:10:00 GMT 2007

Hi Eric,

On Aug  1 06:56, Eric Blake wrote:
> According to Corinna Vinschen on 7/31/2007 9:57 AM:
> > As the coreutils maintainer you are quite involved in how the rename
> > function is supposed to work, especially  due to Cygwin hacks for mv(1),
> > so I would like to ask you to give this new implementation a thorough
> > test.
> OK, the following is based just on comparing the current source code with
> POSIX; I'll still try and play with it more.
> > 
>   - If oldpath is unstattable => EACCES, ELOOP, ENAMETOOLONG, ENOTDIR
>  (but I think that is covered by oldpc.error, correct?)

It should, yes.

> > - If oldpath doesn't exist => ENOENT
>   - If dirname(newpath) is unstattable => EACCES, ELOOP, ENAMETOOLONG, ENOTDIR

That should be covered by newpc.error, or it will be covered later
when calling NtSetInformationFile.

>   - If either name requires writes to a read-only system => EROFS
> (hmm, how come you only check newpc.isspecial?)

That's a good question, let me think...

[time passes]

I have no idea.  I will add that.

> > - If oldpath is a dir
> >   - If newpath exists and is not a dir => ENOTDIR
> >   - If newpath is a subdir of oldpath => EINVAL
>     - If oldpath or newpath ends in . or .. => EINVAL (are you missing
> this check?)

Erm... I see this requirement in SUSv3, but I don;t see what error
code this situation is supposed to set:

[more time passes]

Ouch, that's a new requirement in IEEE P1003.1 Draft 3.  Ok, will do.

>     - If newpath is a non-empty dir => EEXIST (are you missing this check,
> or is it covered by the NtSetInformationFile?)

Sigh.  It's *basically* covered by NtSetInformationFile, but unfortunately
it returns STATUS_ACCESS_DENIED which is translated to EACCES.  So I have
to add another test when NtSetInformationFile fails with STATUS_ACCESS_DENIED
and newpc.isdir().  Oh well.

> >       Otherwise, if oldpath is no shortcut symlink and no .exe binary,
> >       and newpath has a .lnk or .exe suffix, *and* the suffix has
> >       been given explicitely to the rename function, rather than
> >       being tacked on when creating the native Win32 path
> (typo in the code?  you checked for suffix of newpc &&
> !new_explicit_suffix.  Actually, I think the code is right, so your above
> description should be "...*and* the suffix was not given explicitly")

Yep, typo in the description.

> >       => If newpath is a shortcut symlink or .exe binary, delete it.
> >       => Drop the .lnk or .exe suffix from newpath and rename
> > 	 oldpath to newpath w/o .lnk or .exe suffix.
> Also, where do you check that rename("a","a") is a successful no-op, as
> well as rename("a","b") when a and b are hard links to the same inode
> (perhaps both of these cases are covered by NtSetInformationFile?)

rename ("a", "a") is a no-op because NtSetInformationFile will just
return with status 0, doing nothing.

I don't see anything about rename("a","b") with both hardlinks to the
same inode being a no-op.  Neither in Linux, nor in SUSv3, nor in IEEE
P1003.1 Draft 3.  Actually, rename("a","b") will rename a to b, thus
decreasing the link count of the file by 1, on Linux as well as on

> And do you intend to add EXDEV when crossing device boundaries, since
> Windows doesn't allow hard links across devices, but does allow non-atomic
> renames across devices, in violation of POSIX?

Nope, it doesn't, no worries.  What you mean is the win32 function
MoveFile/MoveFileEx.  NtSetInformationFile correctly returns with
STATUS_NOT_SAME_DEVICE which is translated to EXDEV.

> Just from my read of the source code, your approach looks okay.  Now it's
> time for me to compile a snapshot and play with it.

Thanks a lot!  I will (try to) implement something to fix the above
outlined problems.  Stay tuned.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list