This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New rename(2) function


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?)
> - If oldpath doesn't exist => ENOENT
  - If dirname(newpath) is unstattable => EACCES, ELOOP, ENAMETOOLONG, ENOTDIR
  - If either name requires writes to a read-only system => EROFS
(hmm, how come you only check newpc.isspecial?)
> - 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?)
    - If newpath is a non-empty dir => EEXIST (are you missing this check,
or is it covered by the NtSetInformationFile?)
> - If oldpath is a file
>   - If newpath doesn't exist
>     - If fullpath(oldpath) and fullpath(newpath) only differ by
>       their .exe or .lnk suffix, skip all other tests and just
>       rename oldpath to newpath
>     - If oldpath is a shortcut symlink and newpath is missing a .lnk
>       suffix => rename oldpath to newpath.lnk
>     - If oldpath is a .exe binary and newpath is missing a .exe
>       suffix => rename oldpath to newpath.exe
>   - If newpath is a dir => EISDIR
>   - If newpath is a file
>     - If fullpath(oldpath) and fullpath(newpath) only differ by
>       their .exe or .lnk suffix, skip all other tests and rename
>       oldpath to newpath as given.
>     - If oldpath is a shortcut symlink and newpath is not a
>       shortcut symlink and newpath doesn't have a .lnk suffix
>       => delete newpath and rename oldpath to newpath.lnk
>     - If oldpath is a .exe binary and newpath is missing a .exe
>       => delete newpath and rename oldpath to newpath.exe.
>     - This is very tricky:
>       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")
>       => 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?)

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?

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.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]