This is the mail archive of the cygwin 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: [1.7] rename/renameat error

On Wed, Sep 09, 2009 at 04:36:39PM +0000, Eric Blake wrote:
>Eric Blake <ebb9 <at>> writes:
>>>>POSIX states that rename must fail with EINVAL if either argument ends
>>>>in '.' or '..' (after trailing slashes are stripped).  Cygwin 1.7 is
>>>>detecting this situation (which is a step up from 1.5 which did the
>>>>rename anyways), but sets errno to EBUSY instead of EINVAL.
>>>Thanks for catching.  Feel free to fix the rename function accordingly.
>>OK, I'll look into it (I don't know how large the patch will be, yet).
>And link("a","f/.") should not create "f" as a regular file, either.
>I'm still looking at where to patch things.

Argh.  That's a longstanding problem with brain-dead windows behavior.  It's
supposed to be handled in path_conv::check, IIRC.

>Also, we currently allow link("a","b") on FAT, but it might be nicer to fail 
>with EPERM on file systems where hard links are not supported, to match Linux 
>behavior (portable programs, like autoconf, already have fallbacks to perform 
>cp if linking fails, but the copy should be done by the caller, not by link() 

We've debated this over the years but I'm ok with not lying to the caller about
performing a link when we really didn't.


Problem reports:
Unsubscribe info:

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