Re: ntdll.dll: mark dirlink as REPARSE_POINT

[Dimi Paun]

On Tue, 2005-05-31 at 00:00 +0200, Detlef Riekenberg wrote:
> -        if (S_ISDIR( st.st_mode ) && !show_dir_symlinks) return NULL;
> +        if (S_ISDIR( st.st_mode ))
> +       {
> +           if (!show_dir_symlinks)
> +           {
> +               return NULL;
> +           }else
> +           {
> +               name_is_link = FILE_ATTRIBUTE_REPARSE_POINT;
> +           }
> +       }

Minor point, but it would be more in the Wine style to code above as:

+        if (S_ISDIR( st.st_mode ))
+        {
+            if (!show_dir_symlinks) return NULL;
+            name_is_link = FILE_ATTRIBUTE_REPARSE_POINT;
+        }

-- 
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.

ntdll.dll: mark dirlink as REPARSE_POINT (v2)

[Detlef Riekenberg]

Changelog:
        Mark links to dir with "FILE_ATTRIBUTE_REPARSE_POINT", 
        so modern Applications can use this additional Information.
        Supported by ntdll.dll since win2000.

        (Application as Example: totalcmd.exe >6.50)



v2: Reformatted as suggested by Dimi Paun

-- 
By By ...
      ... Detlef

ntdll.dll: mark dirlink as REPARSE_POINT (v2)

[Dimi Paun]

On Tue, 2005-05-31 at 06:21 +0200, Detlef Riekenberg wrote:
> -        if (S_ISDIR( st.st_mode ) && !show_dir_symlinks) return NULL;
> +        if (S_ISDIR( st.st_mode ))
> +       {
> +           if (!show_dir_symlinks) return NULL;
> +           name_is_link = FILE_ATTRIBUTE_REPARSE_POINT;
> +       }
>      }

Hmm, thinking more about it, if windows has support for dir symlinks
(I'm sure they made sure there are no problems with that), should we
even bother having this show_dir_symlinks option? Maybe we should just
nuke it, and just have:

if (S_ISDIR( st.st_mode )) name_is_link = FILE_ATTRIBUTE_REPARSE_POINT;

On a different note, are the brackets above indented properly?

-- 
Dimi Paun <dimi(a)lattica.com>
Lattica, Inc.

ntdll.dll: mark dirlink as REPARSE_POINT (v2)

[Detlef Riekenberg]

Am Dienstag, den 31.05.2005, 00:35 -0400 schrieb Dimi Paun:
> On Tue, 2005-05-31 at 06:21 +0200, Detlef Riekenberg wrote:
> > -        if (S_ISDIR( st.st_mode ) && !show_dir_symlinks) return NULL;
> > +        if (S_ISDIR( st.st_mode ))
> > +       {
> > +           if (!show_dir_symlinks) return NULL;
> > +           name_is_link = FILE_ATTRIBUTE_REPARSE_POINT;
> > +       }
> >      }
>
> Hmm, thinking more about it, if windows has support for dir symlinks
> (I'm sure they made sure there are no problems with that), should we

Some Informations about a REPARSE_POINT:

1. A REPARSE_POINT is a Symlink or a Mountpoint
2. A REPARSE_POINT in win2000 is used for the "Remote Storrage Service"
   ans as a Volume Mountpoint (kill the Driveletter-Limit).
3. The Windows-Explorer does not copy the REPARSE_POINT but 
   the complete data, represented by the REPARSE_POINT.
4. The only tool in win2000, which is able convert a normal Directory
   into a REPARSE_POINT (mountpoint) is the Disk-Management Utility.
  a: According to "b", there is the "linkd"-app in the w2k-Reskit for
     creating junctions.
  b: With "Junction.exe" you can view REPARSE_POINTs and create/delete
     dir-symlinks ("http://www.sysinternals.com/files/jnctnsrc.zip")
     (Freeware with source)
  c: You can create Hardlinks for Files on an NTFS-Volume with ln.exe
     from "www.losoft.de/download/ls-tools.zip" (Freeware with source)
  d: Another Link-Tool for NTFS: "http://ashedel.chat.ru/source/"
     (GPL)
  e: A clone of ntifs.h with struct FILE_LINK_INFORMATION,
     struct _REPARSE_DATA_BUFFER and also "*CreateSymbolicLink*"
     "http://www.acc.umu.se/~bosse/ntifs.h" (GPL)
     (Also in the mingw-cvs)
> even bother having this show_dir_symlinks option? Maybe we should just
> nuke it, and just have:

I think, we should not do that, before the Rest of a "REPARSE_POINT" is
implemented in wine (Create/Info).
> On a different note, are the brackets above indented properly?

In v2, I used MC. The Tabsize is 8 instead of 4. 


-- 
By By ...
      ... Detlef

ntdll.dll: mark dirlink as REPARSE_POINT (v2)

[Francois Gouget]

On Tue, 31 May 2005, Detlef Riekenberg wrote:
[...]
> Some Informations about a REPARSE_POINT:
>
> 1. A REPARSE_POINT is a Symlink or a Mountpoint
> 2. A REPARSE_POINT in win2000 is used for the "Remote Storrage Service"
>   ans as a Volume Mountpoint (kill the Driveletter-Limit).
> 3. The Windows-Explorer does not copy the REPARSE_POINT but
>   the complete data, represented by the REPARSE_POINT.
> 4. The only tool in win2000, which is able convert a normal Directory
>   into a REPARSE_POINT (mountpoint) is the Disk-Management Utility.
>  a: According to "b", there is the "linkd"-app in the w2k-Reskit for
>     creating junctions.
>  b: With "Junction.exe" you can view REPARSE_POINTs and create/delete
>     dir-symlinks ("http://www.sysinternals.com/files/jnctnsrc.zip")
>     (Freeware with source)
>  c: You can create Hardlinks for Files on an NTFS-Volume with ln.exe
>     from "www.losoft.de/download/ls-tools.zip" (Freeware with source)
>  d: Another Link-Tool for NTFS: "http://ashedel.chat.ru/source/"
>     (GPL)
>  e: A clone of ntifs.h with struct FILE_LINK_INFORMATION,
>     struct _REPARSE_DATA_BUFFER and also "*CreateSymbolicLink*"
>     "http://www.acc.umu.se/~bosse/ntifs.h" (GPL)
>     (Also in the mingw-cvs)

How does Find{First,Next}File handle REPARSE_POINTs? Any chance we could 
use them to enable ShowSymdirLink without causing applications to go 
into infinite loops?

If yes that would be very cool.

-- 
Francois Gouget         fgouget(a)free.fr        http://fgouget.free.fr/
                      Avoid the Gates of Hell - use Linux.

ntdll.dll: mark dirlink as REPARSE_POINT (v2)

[Detlef Riekenberg]

Am Mittwoch, den 01.06.2005, 21:52 +0200 schrieb Francois Gouget:
> > Some Informations about a REPARSE_POINT:
> How does Find{First,Next}File handle REPARSE_POINTs?

Simple as a Directory with the additional Bit for
"FILE_ATTRIBUTE_REPARSE_POINT" set (0x0400).

The Patch is already in the CVS-Tree, so wine does the same.

But beware. The runtime-libraries of some C-Compiler does not handle
this bit in there implementation.

Example:
----- cut -----
While testing my Code with OpenWatcom 1.2b I have some Problems with
the 
"attrib" - Field of "_finddata_t" for _findfirst/_findnext:

Link's (0x0400) are not detected, because with OW1.2, the "attrib" - 
Field has always "0" in the highest 8 Bit's.

Full 16-Bit attrib with the same Source and the following compiler's:
-DigitalMars 8.33 / 8.37
-BCC 5.5.1
-MinGW 3.1 (gcc 3.2.3)
-Microsoft C/C++ 12.00 Authoring Edition

I don't have a different Watcom/Open Watcom version.

Using "C"-Source with wcl386, W2K sp3 and NTFS.

----- cut -----
That was my Mail in "news:openwatcom.users.c_cpp" in Nov/2003.

I switched to _WIN32_FIND_DATA after that.
Everything was ANSI and i need to change my source to use UNICODE.
> Any chance we could 
> use them to enable ShowSymdirLink without causing applications to go 
> into infinite loops?
> If yes that would be very cool.

The Explorer (w2k) does not copy the Link, it creates a Directory with
the Name of the Link an copy the complete Contents of the Link-Target.
Not very cool for the User.

We need some testcases to verify this behaviour on newer
Windows-Versions before we can implement Link-Creation in Wine.
(The Application-Part for the Creation of REPARSE_POINTs is in the
Sources, i mentioned before).

-- 
By By ...
      ... Detlef