Visible symlinks under Windows

[Corinna Vinschen]

On Feb 21 11:59, Volker Lendecke wrote:
> On Thu, Feb 21, 2008 at 11:37:07AM +0100, Corinna Vinschen wrote:
> > > Mulling about this problem, I stumbled over the NtQueryFullAttributesFile
> > > function, which is the NT function retrieving the NT equivalent of the
> > > SMB_FILE_NETWORK_OPEN_INFORMATION block.  It's the maximum amount of 
> > > information available to a Windows client without opening a file.  The
> > > structure consists of
> > > 
> > >   birthtime
> > >   atime
> > >   mtime
> > >   ctime
> > >   allocation_size
> > >   file_size
> > >   dos_attributes
> > > 
> > > Is it possible to sneak in the information that the file or dir is
> > > actually a symlink into the above structure?
> > > 
> > > Two members of this structure are not used by Win32 clients, ctime and
> > > allocation_size, because the Win32 equivalent of the
> > > NtQueryFullAttributesFile function, GetFileAttributesEx, does not expose
> > > them.  But ctime is retrieved by Cygwin as... ctime.
> 
> Are you 100% sure that no Windows code ever looks at this?

Sorry, no.  Even worse, starting with Windows Vista, many of the
existing NT internal file information structures are exposed to Win32
applications using the new GetFileInformationByHandleEx and
SetFileInformationByHandle calls.  These calls are also available for
download at Microsoft as "Win32 FileID API Library"; supported systems
are XP and 2003 Server.

> You would change our calculation of allocation_size for
> symlinks only? What do we return right now for them?
> (haven't looked at our code)

Right now, the allocation size is set to 0 in case of directories.  On
most systems filesize is derived from st_blocks, multiplied by the
systems blocksize.  The result is evetually rounded up to a multiple of
the value given in smb.conf's "allocation roundup size", if defined.

Yes, the idea would be to change the allocation size only for actual
symlinks.  Windows can handle allocation sizes < blocksize, given that
NTFS can allocate small files (<1K) in 8 byte chunks.

If that's considered too dangerous, what about utilizing the least
significant bit in the ctime member?  Timestamps are defined in 100ns
intervals.  The LSB could be set to 0 or 1 deliberately.  None of the
Win32 timestamp related functions know about the ctime


Maybe somebody else has another idea how to flag symlinks in a
non-intrusive way?


Corinna