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: Seeking developer to assist with adding OpenAFS Reparse Tag Support to Cygwin


On 2/28/2013 4:03 AM, Corinna Vinschen wrote:

> The core routine is symlink_info::check_reparse_point in path.cc.
> 
> Actually, Cygwin always opens files with FILE_OPEN_REPARSE_POINT
> and then, if it *is* a reparse point, it reads the contents of the
> reparse point and expects it to be of type IO_REPARSE_TAG_SYMLINK
> or IO_REPARSE_TAG_MOUNT_POINT.  Those are handled as symlinks.
> Other types are not recognized and the FILE_ATTRIBUTE_REPARSE_POINT
> attribute is deleted from the DOS attributes.  The later file open
> call in fhandler.cc will omit the FILE_OPEN_REPARSE_POINT flag from
> the open flags, so it will open the file transparently via the
> reparse redirector.
> 
> But there's a chance that this doesn't happen in all circumstances as
> expected.  As a first cut, look for usage of FILE_OPEN_REPARSE_POINT and
> the usage of the path_conv::is_rep_symlink method thoughout fhandler*.cc
> and syscalls.cc.

Thank you Corinna.

In my initial e-mail I pointed to an MSDN document which describes the
inconsistent behavior of the Win32 API with regards to reparse points.
The key thing to take away from that is that regardless of what the
application (in this case Cygwin) wants, FILE_OPEN_REPARSE_POINT will be
included in the underlying CreateFile() call for operations such
as

  GetFileAttributes[Ex]
  GetFileSecurity
  Directory enumeration

I believe the rational is that these functions should be fast and should
not block if the reparse point target is located "far away"
or perhaps "offline" in a hierarchical storage management system.

One side effect of this for Cygwin is that reported sizes of objects in
the "ls -l" output is incorrect.  For example, ti.exe is a symlink to a
file stored in AFS.

  11/01/2012   0:27     <SYMLINK>    ti.exe
  [\afs\your-file-system.com\public\jaltman\TI_TAV_5.0_EN_Full.exe]

The actual size of the target object is:

  3/26/2012  20:32     103,103,720  TI_TAV_5.0_EN_Full.exe

but Cygwin lists it as:

  -rwxr-xr-x 1 jaltman None       63 Nov  1 01:27 ti.exe

where 63 bytes is the size of the reparse point data not the target.  If
Cygwin is going to discard FILE_ATTRIBUTE_REPARSE_POINT, then it must
also resolve the target attributes when collecting stat info.

This can be done by opening the file with CreateFile(path, no
FILE_OPEN_REPARSE_POINT) and then using GetFileInformationByHandle().

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364952%28v=vs.85%29.aspx

I don't know if this is a behavior that the Cygwin community wants to
alter.  It is certainly confusing to end users and potentially breaks
applications which believe a file is smaller than it is.  However,
resolving reparse targets can be very expensive in some cases.

Sincerely,

Jeffrey Altman






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