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: rename(2) using NTFS transactions on Vista/2008


On May 19 20:04, Eric Blake wrote:
> According to Corinna Vinschen on 5/19/2008 1:21 PM:
>>> cygwin-1.7.0-9 had problems with rename("file","link") returning a 
>>> spurious ENOENT.  But I haven't been able to test 1.7.0-10 yet, to see if 
>>> it has been fixed.
>> Probably not.  How to reproduce?
>[...]
> Should succeed silently (and did in 1.5.x). I haven't tested whether your 
> latest patch fixes it; I also noticed that while it failed for 

It should.  The problem was a wrong test for the R/O bit and the
desperate, but incorrect try to remove the bit from the destination
file in this special case.

> I also noticed today a behavior where 'cp -p old new' was setting the 
> system bit on the new file, as if by 'attrib +S new', but haven't had time 
> to look into it further.

Did the new file exist before the copy?  Did it have the S bit set?  If
so, then that's natural.  The problem is that Windows since W2K
disallows to overwrite files which have the SYSTEM and/or HIDDEN bits
set, if you don't specify the same flags in the NtCreateFile call.
See fhandler_base::open for the comment describing that.

Since the open() call doesn't know that the new file is supposed to
be replaced by another already existing file, there's no way to tell
that the S and H bits can be deleted afterwards.

>>> Meanwhile, while looking at the code, is it really a good idea to have 3 
>>> stack-allocated path_conv variables, each 32k in size?  That sounds like 
>>> a 
>> They are not necessarily 32K but you're right, they could be in the
>> worst case.
>
> I saw what you fixed with alloca usage, and it is an improvement.  But I 
> was talking about path_conv, which is still broken.  sizeof(path_conv) > 
> 32k at the moment, because of path_conv.path[], even when the two file 
> names are 1 byte each.  It looks like it could still be useful to keep the 
> path[] member to reduce pressure on cmalloc in the common case, but with a 
> much smaller size than NT_MAX_PATH (maybe 1k bytes, so that a method like 
> rename(2) can still have three instances of a stack-allocated path_conv 
> without overflowing a 4k guard) where both the original name and the 
> normalized_path can fit into that area, while leaving larger paths (both 
> original and normalized, rather than the current approach of just 
> normalized) under cmalloc management.

path_conv still has to be changed a lot.  I see your point but I really
don't want to make big changes to the path_conv core unless cgf is ok
with that.

FWIW, I'm going to eliminate a couple more alloca's and replace them by
using the tmp_pathbuf.  That should already help a lot.


Corinna

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


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