This is the mail archive of the cygwin-patches@cygwin.com 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: [Patch]: Last path.cc



Corinna Vinschen wrote:
> 
> On Apr 12 19:29, Pierre A. Humblet wrote:
> > At 11:45 PM 4/10/2004 -0400, Christopher Faylor wrote:
> > >On Sat, Apr 10, 2004 at 11:37:07PM -0400, Pierre A. Humblet wrote:
> > >>This should take care of the issues I listed yesterday evening.
> > >>
> > >>I simply don't understand the logic in normalize_win32_path
> > >>well enough to touch it intelligently.
> > >>So I removed the final . in the dumbest way possible
> > >
> > >Why do we have to remove the final dot?
> > >
> > >How does that jive with the goal of munging windows paths as little
> > >as possible.
> >
> > Windows paths go through the symlink evaluation and path existence
> > loops as all others. Keeping the final /. causes abnormal behavior
> > with some symlinks (Cygwin looks for /..lnk).
> > Also the non-uniform normalization complicates other routines. For
> > example hash_path_name() contains special code to detect and remove
> > the final /.
> >
> > About the "normalized_path", I would still recommend replacing
> > get_name() by get_win32_name() in fchown32, fchmod, fstat64, facl32
>                                                       ???????
> 
> > and perhaps fhandler_disk_file::mmap. Otherwise making changes to the
> > mounts can cause calls on opened files to fail. It's also faster.
> 
> I think the better approach is to change all these functions to
> work on handles instead of filenames.  

I agree 100% with that. But in cases where it's not possible 
(fhandler_disk_file::mmap), and on 9X, it makes more sense
to use the win32_name, which is closer to hardware.
We already use it in the inode hash for the same reason.

About the reference to fstat64, I got carried away. 
Instead of recomputing the hash there, it would be better to call
get_namehash, the hash is always set in fhandler_base::set_name.
But doing that is also wasteful, it's not used when inodes are
available. Lazy evaluation seems indicated here:
get_namehash () { namehash? namehash : namehash = hash_path_name (0, pc.get_win32_name ())

Pierre


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