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 8/9/2007 6:02 AM:
> Sigh.  Why does NT claim to be POSIX compliant if it does not allow
> POSIX semantics?  Here's the problem:
> 
> Even if the ReplaceIfExists member in the FILE_RENAME_INFORMATION
> structure is set to TRUE, the rename operation fails if 
> - the target has the R/O DOS attribute set, or

POSIX doesn't really specify R/O DOS attributes, so we could theoretically
do whatever we wanted here.  But as the main list had a report about svn
acting strangely because of its use of R/O attributes, I think we are
probably better off working around the attribute and doing the rename anyway.

> - the target is an existing directory, or

Sheer bug on Microsoft's part - I guess we have to work around it.

> - the target is a currently executing file.

POSIX describes this - you are allowed (although not required) to fail
with ETXTBSY.  In fact, I would recommend failing with ETXTBSY, even
though Linux does not do this, since otherwise it would be possible to
overwrite in-use .dlls, which is a no-no in the cygwin /bin directory.

> 
> "If the link named by the new argument exists, it shall be removed and
>  old renamed to new. In this case, a link named new shall remain visible
>  to other processes throughout the renaming operation and refer either to
>  the file referred to by new or old before the operation began."
> 
> which is impossible to implement with the given NT behaviour.  Grr.

Well, we already know of other operations that POSIX requires to be
atomic, but which Windows makes it impossible to implement atomically.  No
skin off my back; you are doing the best possible in spite of the lousy
semantics of the underlying OS.

> 
> This looks like a problem in path_conv.  I tried this in /tmp, and
> path_conv::check ("f/", PC_SYM_NOFOLLOW) creates a path_conv structure
> with fileattr == -1, error == 0, path = "C:\\cygwin\\tmp\\e".  The 
> path is the resolved path of the original symlink and there's no hint
> in the path_conv which identifies it as dangling symlink.
> 
> Chris, shouldn't path_conv return the same structure as if the incoming
> path name was "f", without trailing slash, given that PC_SYM_NOFOLLOW
> is set?

Seems like that might do 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]