This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: New rename(2) function
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Wed, 1 Aug 2007 16:09:56 +0200
- Subject: Re: New rename(2) function
- References: <20070731155745.GE21952@calimero.vinschen.de> <46B082EF.1010102@byu.net>
- Reply-to: cygwin-developers at cygwin dot com
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:
http://www.opengroup.org/onlinepubs/009695399/functions/rename.html
[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
Cygwin.
> 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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat