Re: CYGWIN inode over Samba share not constructed from IndexNumber

Re: CYGWIN inode over Samba share not constructed from IndexNumber

[starlight.2012q2]

Here is the logic Samba uses for inode
determination, per Jermey Allison:



Ok, here's how we construct the 64-bit return
value for that field:

/********************************************************************
 Create a 64 bit FileIndex. If the file is on the same device as
 the root of the share, just return the 64-bit inode. If it isn't,
 mangle as we used to do.
********************************************************************/

uint64_t get_FileIndex(connection_struct *conn, const SMB_STRUCT_STAT *psbuf)
{
   uint64_t file_index;
   if (conn->base_share_dev == psbuf->st_ex_dev) {
      return (uint64_t)psbuf->st_ex_ino;
   }
   file_index = ((psbuf->st_ex_ino) & UINT32_MAX); /* FileIndexLow */
   file_index |= ((uint64_t)((psbuf->st_ex_dev) & UINT32_MAX)) << 32; /* FileIndexHigh */
   return file_index;
}


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: CYGWIN inode over Samba share not constructed from IndexNumber

[Corinna Vinschen]

On May 11 12:56, starlight.2012q2@binnacle.cx wrote:
> Here is the logic Samba uses for inode
> determination, per Jermey Allison:
> 
> 
> 
> Ok, here's how we construct the 64-bit return
> value for that field:
> 
> /********************************************************************
>  Create a 64 bit FileIndex. If the file is on the same device as
>  the root of the share, just return the 64-bit inode. If it isn't,
>  mangle as we used to do.
> ********************************************************************/
> 
> uint64_t get_FileIndex(connection_struct *conn, const SMB_STRUCT_STAT *psbuf)
> {
>    uint64_t file_index;
>    if (conn->base_share_dev == psbuf->st_ex_dev) {
>       return (uint64_t)psbuf->st_ex_ino;
>    }
>    file_index = ((psbuf->st_ex_ino) & UINT32_MAX); /* FileIndexLow */
>    file_index |= ((uint64_t)((psbuf->st_ex_dev) & UINT32_MAX)) << 32; /* FileIndexHigh */
>    return file_index;
> }

Which Samba version introduced this behaviour?  Originally, way back
when Samba 3.0.28 was new, the inode numbers were always mangled to be
64 bit numbers, AFAIK.  The code in Cygwin which doesn't trust 32 bit
inode numbers on remote drives is there for ages, at least since 2007.

Fortunately we have an interface which allows to fetch the Samba version
number from the server since Samba 3.0.28a.  So, if we know which Samba
version started to return the real 32 bit inode number, we can adapt.

Btw., https://lists.samba.org/archive/samba/2012-May/167383.html is a
bit of a disappointment.  There's nothing "oddball" in the decision not
to trust remote inode numbers <= 0xffffffff.

It all started with the fact that remote NT4 servers returned ephemeral
file IDs <= 0xfffffff.  And there was some problem with 2.x Samba shares
as well, which also returned weird file IDs, but I don't recall the
details.

This is old code, I grant you that, but we had our reason to do so at
the time.  Here's the code in question including comment:

inline bool
path_conv::isgood_inode (__ino64_t ino) const
{
  /* We can't trust remote inode numbers of only 32 bit.  That means,
     remote NT4 NTFS, as well as shares of Samba version < 3.0.
     The known exception are SFU NFS shares, which return the valid 32 bit
     inode number from the remote file system unchanged. */
  return hasgood_inode () && (ino > UINT32_MAX || !isremote () || fs_is_nfs ());
}


Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: CYGWIN inode over Samba share not constructed from IndexNumber

[starlight.2012q2]

At 07:58 PM 5/11/2012 +0200, Corinna Vinschen wrote:
>Which Samba version introduced this behaviour?

Don't know.

I'm stepping aside on this now.  Just
reported it since it came up and broke
a script we have.  I've worked around
the inode test by comparing 'sha1sum'
values for the files and re-hard-linking
the files when the sums differ.

I understand this stuff can be tricky,
but if it's at all possible it seems
reasonable to ask that the behavior of
CYGWIN+Samba parallel Linux native
behavior w/r/t apparent inode values being
the same when actual inode values match.

I like the idea that the true inode
values be represented by CYGWIN+Samba
whenever possible.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: CYGWIN inode over Samba share not constructed from IndexNumber

[Jeremy Allison]

On Fri, May 11, 2012 at 07:58:43PM +0200, Corinna Vinschen wrote:
> On May 11 12:56, starlight.2012q2@binnacle.cx wrote:
> > Here is the logic Samba uses for inode
> > determination, per Jermey Allison:
> > 
> > 
> > 
> > Ok, here's how we construct the 64-bit return
> > value for that field:
> > 
> > /********************************************************************
> >  Create a 64 bit FileIndex. If the file is on the same device as
> >  the root of the share, just return the 64-bit inode. If it isn't,
> >  mangle as we used to do.
> > ********************************************************************/
> > 
> > uint64_t get_FileIndex(connection_struct *conn, const SMB_STRUCT_STAT *psbuf)
> > {
> >    uint64_t file_index;
> >    if (conn->base_share_dev == psbuf->st_ex_dev) {
> >       return (uint64_t)psbuf->st_ex_ino;
> >    }
> >    file_index = ((psbuf->st_ex_ino) & UINT32_MAX); /* FileIndexLow */
> >    file_index |= ((uint64_t)((psbuf->st_ex_dev) & UINT32_MAX)) << 32; /* FileIndexHigh */
> >    return file_index;
> > }
> 
> Which Samba version introduced this behaviour?  Originally, way back
> when Samba 3.0.28 was new, the inode numbers were always mangled to be
> 64 bit numbers, AFAIK.  The code in Cygwin which doesn't trust 32 bit
> inode numbers on remote drives is there for ages, at least since 2007.
> 
> Fortunately we have an interface which allows to fetch the Samba version
> number from the server since Samba 3.0.28a.  So, if we know which Samba
> version started to return the real 32 bit inode number, we can adapt.
> 
> Btw., https://lists.samba.org/archive/samba/2012-May/167383.html is a
> bit of a disappointment.  There's nothing "oddball" in the decision not
> to trust remote inode numbers <= 0xffffffff.
> 
> It all started with the fact that remote NT4 servers returned ephemeral
> file IDs <= 0xfffffff.  And there was some problem with 2.x Samba shares
> as well, which also returned weird file IDs, but I don't recall the
> details.
> 
> This is old code, I grant you that, but we had our reason to do so at
> the time.  Here's the code in question including comment:
> 
> inline bool
> path_conv::isgood_inode (__ino64_t ino) const
> {
>   /* We can't trust remote inode numbers of only 32 bit.  That means,
>      remote NT4 NTFS, as well as shares of Samba version < 3.0.
>      The known exception are SFU NFS shares, which return the valid 32 bit
>      inode number from the remote file system unchanged. */
>   return hasgood_inode () && (ino > UINT32_MAX || !isremote () || fs_is_nfs ());
> }

The get_FileIndex() code has been there since at least 3.6.x, but
I'll try and track down when it was first introduced.

Jeremy.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: CYGWIN inode over Samba share not constructed from IndexNumber

[Corinna Vinschen]

Hi Jeremy,

On May 11 14:15, Jeremy Allison wrote:
> On Fri, May 11, 2012 at 07:58:43PM +0200, Corinna Vinschen wrote:
> > On May 11 12:56, starlight.2012q2@binnacle.cx wrote:
> > > /********************************************************************
> > >  Create a 64 bit FileIndex. If the file is on the same device as
> > >  the root of the share, just return the 64-bit inode. If it isn't,
> > >  mangle as we used to do.
> > > ********************************************************************/
> > > 
> > > uint64_t get_FileIndex(connection_struct *conn, const SMB_STRUCT_STAT *psbuf)
> > > {
> > >    uint64_t file_index;
> > >    if (conn->base_share_dev == psbuf->st_ex_dev) {
> > >       return (uint64_t)psbuf->st_ex_ino;
> > >    }
> > >    file_index = ((psbuf->st_ex_ino) & UINT32_MAX); /* FileIndexLow */
> > >    file_index |= ((uint64_t)((psbuf->st_ex_dev) & UINT32_MAX)) << 32; /* FileIndexHigh */
> > >    return file_index;
> > > }
> > 
> > Which Samba version introduced this behaviour?  Originally, way back
> > when Samba 3.0.28 was new, the inode numbers were always mangled to be
> > 64 bit numbers, AFAIK.  The code in Cygwin which doesn't trust 32 bit
> > inode numbers on remote drives is there for ages, at least since 2007.
> > 
> > Fortunately we have an interface which allows to fetch the Samba version
> > number from the server since Samba 3.0.28a.  So, if we know which Samba
> > version started to return the real 32 bit inode number, we can adapt.
> > [...]
> > inline bool
> > path_conv::isgood_inode (__ino64_t ino) const
> > {
> >   /* We can't trust remote inode numbers of only 32 bit.  That means,
> >      remote NT4 NTFS, as well as shares of Samba version < 3.0.
> >      The known exception are SFU NFS shares, which return the valid 32 bit
> >      inode number from the remote file system unchanged. */
> >   return hasgood_inode () && (ino > UINT32_MAX || !isremote () || fs_is_nfs ());
> > }
> 
> The get_FileIndex() code has been there since at least 3.6.x, but
> I'll try and track down when it was first introduced.

That would be nice.  For now, assuming the get_FileIndex has been
introduced with 3.6.0, I'd go with this new implementation, stretched
out and better comments for readability:

inline bool
path_conv::isgood_inode (__ino64_t ino) const
{ 
  /* If the FS doesn't support nonambiguous inode numbers anyway, bail out
     immediately. */
  if (!hasgood_inode ())
    return false;
  /* If the inode numbers are 64 bit numbers or if it's a local FS, they
     are to be trusted. */
  if (ino > UINT32_MAX || !isremote ())
    return true;
  /* The inode numbers returned from a remote NT4 NTFS are ephemeral
     32 bit numbers. */
  if (fs_is_ntfs ())
    return false;
  /* Samba versions since 3.x.x return the real inode numbers, unless the file
     is not on the same device as the root of the share, in which case Samba
     returns a mangled inode number which is a 64 bit number again.  See the
     get_FileIndex function in the Samba sources. */
  if (fs_is_samba () && fs.samba_version () >= 0x03060000)
    return true;
  /* SFU NFS just returns the actual inode number. */
  if (fs_is_nfs ())
    return true;
  /* Otherwise, don't trust the inode numbers. */
  return false;
} 


What do you say?

Thanks,
Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: CYGWIN inode over Samba share not constructed from IndexNumber

[Jeremy Allison]

On Sat, May 12, 2012 at 12:53:49PM +0200, Corinna Vinschen wrote:
> Hi Jeremy,
> 
> On May 11 14:15, Jeremy Allison wrote:
> > On Fri, May 11, 2012 at 07:58:43PM +0200, Corinna Vinschen wrote:
> > > On May 11 12:56, starlight.2012q2@binnacle.cx wrote:
> > > > /********************************************************************
> > > >  Create a 64 bit FileIndex. If the file is on the same device as
> > > >  the root of the share, just return the 64-bit inode. If it isn't,
> > > >  mangle as we used to do.
> > > > ********************************************************************/
> > > > 
> > > > uint64_t get_FileIndex(connection_struct *conn, const SMB_STRUCT_STAT *psbuf)
> > > > {
> > > >    uint64_t file_index;
> > > >    if (conn->base_share_dev == psbuf->st_ex_dev) {
> > > >       return (uint64_t)psbuf->st_ex_ino;
> > > >    }
> > > >    file_index = ((psbuf->st_ex_ino) & UINT32_MAX); /* FileIndexLow */
> > > >    file_index |= ((uint64_t)((psbuf->st_ex_dev) & UINT32_MAX)) << 32; /* FileIndexHigh */
> > > >    return file_index;
> > > > }
> > > 
> > > Which Samba version introduced this behaviour?  Originally, way back
> > > when Samba 3.0.28 was new, the inode numbers were always mangled to be
> > > 64 bit numbers, AFAIK.  The code in Cygwin which doesn't trust 32 bit
> > > inode numbers on remote drives is there for ages, at least since 2007.
> > > 
> > > Fortunately we have an interface which allows to fetch the Samba version
> > > number from the server since Samba 3.0.28a.  So, if we know which Samba
> > > version started to return the real 32 bit inode number, we can adapt.
> > > [...]
> > > inline bool
> > > path_conv::isgood_inode (__ino64_t ino) const
> > > {
> > >   /* We can't trust remote inode numbers of only 32 bit.  That means,
> > >      remote NT4 NTFS, as well as shares of Samba version < 3.0.
> > >      The known exception are SFU NFS shares, which return the valid 32 bit
> > >      inode number from the remote file system unchanged. */
> > >   return hasgood_inode () && (ino > UINT32_MAX || !isremote () || fs_is_nfs ());
> > > }
> > 
> > The get_FileIndex() code has been there since at least 3.6.x, but
> > I'll try and track down when it was first introduced.
> 
> That would be nice.  For now, assuming the get_FileIndex has been
> introduced with 3.6.0, I'd go with this new implementation, stretched
> out and better comments for readability:

get_FileIndex() is in 3.5.x (current code). It was added in
commit 920ffe49290cacd30d9bc582c1c3fee38308c260, which went
in on Thu May 20 11:36:47 2010, which means it went into
Samba 3.5.4.

Jeremy.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: CYGWIN inode over Samba share not constructed from IndexNumber

[Corinna Vinschen]

On May 14 10:33, Jeremy Allison wrote:
> On Sat, May 12, 2012 at 12:53:49PM +0200, Corinna Vinschen wrote:
> > On May 11 14:15, Jeremy Allison wrote:
> > > The get_FileIndex() code has been there since at least 3.6.x, but
> > > I'll try and track down when it was first introduced.
> > 
> > That would be nice.  For now, assuming the get_FileIndex has been
> > introduced with 3.6.0, I'd go with this new implementation, stretched
> > out and better comments for readability:
> 
> get_FileIndex() is in 3.5.x (current code). It was added in
> commit 920ffe49290cacd30d9bc582c1c3fee38308c260, which went
> in on Thu May 20 11:36:47 2010, which means it went into
> Samba 3.5.4.

Thank you!


Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

CYGWIN inode over Samba share not constructed from IndexNumber

[starlight.2012q2]

Hello,

Ran into a quirk that caused some trouble.

For some reason CYGWIN 1.7.5 (I know this is old)
is constructing inode values for files on
Samba (3.6.4) shares with a different algorithm
than is used for files on NTFS volumes.

This caused a script that checks for matching
hard-links to fail.

Confirmed that Samba is returning the actual
inode values in 'IndexNumber' with 'procmon'
while running the

   stat -c '%h %d %i' filename

command.  See https://lists.samba.org/archive/samba/2012-May/167381.html.

Is CYGWIN mistaking the Samba share for a FAT32
volume and using an inode-faking algo?  Or
is it something else?  Was this fixed in
a newer version of CYGWIN?  I did try a search
but came up with nothing.  With NTFS the
inode values reported do match the underlying
'IndexNumber' value.

Please CC me with any replies as I am not
subscribed to the list.

Thanks


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: CYGWIN inode over Samba share not constructed from IndexNumber

[Corinna Vinschen]

On May 11 11:42, starlight.2012q2@binnacle.cx wrote:
> Hello,
> 
> Ran into a quirk that caused some trouble.
> 
> For some reason CYGWIN 1.7.5 (I know this is old)

You should really update.

> is constructing inode values for files on
> Samba (3.6.4) shares with a different algorithm
> than is used for files on NTFS volumes.
> 
> This caused a script that checks for matching
> hard-links to fail.
> 
> Confirmed that Samba is returning the actual
> inode values in 'IndexNumber' with 'procmon'
> while running the
> 
>    stat -c '%h %d %i' filename
> 
> command.  See https://lists.samba.org/archive/samba/2012-May/167381.html.
> 
> Is CYGWIN mistaking the Samba share for a FAT32
> volume and using an inode-faking algo?  Or

It depends on what Samba returns as file system information.  Right now
Cygwin expects valid inode information only from filesystems which
return the FILE_PERSISTENT_ACLS flag, except for netapps (never) and nfs
(always).

Additionally, the returned file ID must be > 0xffffffff, otherwise we
don't trust the server to generate usefule file IDs.  This usually only
affects remote NT4 NTFS and Samba < 3.0.

Assuming your Samba drive is //server/share, please run

  /usr/lib/getVolInfo //server/share

and post the output as reply here.  As an example, this is what my
Samba shares return:

  $ /usr/lib/csih/getVolInfo.exe //server/share
  Device Type        : 7
  Characteristics    : 10
  Volume Name        : <corinna>
  Serial Number      : 2469776470
  Max Filenamelength : 255
  Filesystemname     : <NTFS>
  Flags              : 1002f
    FILE_CASE_SENSITIVE_SEARCH  : TRUE
    FILE_CASE_PRESERVED_NAMES   : TRUE
    FILE_UNICODE_ON_DISK        : TRUE
    FILE_PERSISTENT_ACLS        : TRUE		<- !!!
    FILE_FILE_COMPRESSION       : FALSE
    FILE_VOLUME_QUOTAS          : TRUE
    FILE_SUPPORTS_SPARSE_FILES  : FALSE
    FILE_SUPPORTS_REPARSE_POINTS: FALSE
    FILE_SUPPORTS_REMOTE_STORAGE: FALSE
    FILE_VOLUME_IS_COMPRESSED   : FALSE
    FILE_SUPPORTS_OBJECT_IDS    : TRUE
    FILE_SUPPORTS_ENCRYPTION    : FALSE
    FILE_NAMED_STREAMS          : FALSE
    FILE_READ_ONLY_VOLUME       : FALSE
    FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
    FILE_SUPPORTS_TRANSACTIONS  : FALSE

If your Samba doesn't set FILE_PERSISTENT_ACLS to TRUE, you have to
change your smb.conf file so that it does.  


Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: CYGWIN inode over Samba share not constructed from IndexNumber

[Corinna Vinschen]

[Sigh.  Resending with CC]

On May 11 11:42, starlight.2012q2@binnacle.cx wrote:
> Hello,
> 
> Ran into a quirk that caused some trouble.
> 
> For some reason CYGWIN 1.7.5 (I know this is old)

You should really update.

> is constructing inode values for files on
> Samba (3.6.4) shares with a different algorithm
> than is used for files on NTFS volumes.
> 
> This caused a script that checks for matching
> hard-links to fail.
> 
> Confirmed that Samba is returning the actual
> inode values in 'IndexNumber' with 'procmon'
> while running the
> 
>    stat -c '%h %d %i' filename
> 
> command.  See https://lists.samba.org/archive/samba/2012-May/167381.html.
> 
> Is CYGWIN mistaking the Samba share for a FAT32
> volume and using an inode-faking algo?  Or

It depends on what Samba returns as file system information.  Right now
Cygwin expects valid inode information only from filesystems which
return the FILE_PERSISTENT_ACLS flag, except for netapps (never) and nfs
(always).

Additionally, the returned file ID must be > 0xffffffff, otherwise we
don't trust the server to generate usefule file IDs.  This usually only
affects remote NT4 NTFS and Samba < 3.0.

Assuming your Samba drive is //server/share, please run

  /usr/lib/getVolInfo //server/share

and post the output as reply here.  As an example, this is what my
Samba shares return:

  $ /usr/lib/csih/getVolInfo.exe //server/share
  Device Type        : 7
  Characteristics    : 10
  Volume Name        : <corinna>
  Serial Number      : 2469776470
  Max Filenamelength : 255
  Filesystemname     : <NTFS>
  Flags              : 1002f
    FILE_CASE_SENSITIVE_SEARCH  : TRUE
    FILE_CASE_PRESERVED_NAMES   : TRUE
    FILE_UNICODE_ON_DISK        : TRUE
    FILE_PERSISTENT_ACLS        : TRUE		<- !!!
    FILE_FILE_COMPRESSION       : FALSE
    FILE_VOLUME_QUOTAS          : TRUE
    FILE_SUPPORTS_SPARSE_FILES  : FALSE
    FILE_SUPPORTS_REPARSE_POINTS: FALSE
    FILE_SUPPORTS_REMOTE_STORAGE: FALSE
    FILE_VOLUME_IS_COMPRESSED   : FALSE
    FILE_SUPPORTS_OBJECT_IDS    : TRUE
    FILE_SUPPORTS_ENCRYPTION    : FALSE
    FILE_NAMED_STREAMS          : FALSE
    FILE_READ_ONLY_VOLUME       : FALSE
    FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
    FILE_SUPPORTS_TRANSACTIONS  : FALSE

If your Samba doesn't set FILE_PERSISTENT_ACLS to TRUE, you have to
change your smb.conf file so that it does.  


Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: CYGWIN inode over Samba share not constructed from IndexNumber

[starlight.2012q2]

At 06:23 PM 5/11/2012 +0200, Corinna Vinschen wrote:
>Additionally, the returned file ID must be > 0xffffffff, 
>otherwise we don't trust the server to generate
>usefule file IDs.  This usually only affects remote
>NT4 NTFS and Samba < 3.0.

Running Samba 3.6.4 and it is returning

   IndexNumber: 0x81f

which is the actual inode value and the
Samba devs indicated this is the behavior
as designed.

Also

$ getVolInfo //siobhan/d | fgrep -i ACL
  FILE_PERSISTENT_ACLS        : TRUE

Thank you very much for your reply.




======
$ getVolInfo //siobhan/d
Device Type        : 7
Characteristics    : 10
Volume Name        : <d>
Serial Number      : 2717179013
Max Filenamelength : 255
Filesystemname     : <NTFS>
Flags              : 1002f
  FILE_CASE_SENSITIVE_SEARCH  : TRUE
  FILE_CASE_PRESERVED_NAMES   : TRUE
  FILE_UNICODE_ON_DISK        : TRUE
  FILE_PERSISTENT_ACLS        : TRUE
  FILE_FILE_COMPRESSION       : FALSE
  FILE_VOLUME_QUOTAS          : TRUE
  FILE_SUPPORTS_SPARSE_FILES  : FALSE
  FILE_SUPPORTS_REPARSE_POINTS: FALSE
  FILE_SUPPORTS_REMOTE_STORAGE: FALSE
  FILE_VOLUME_IS_COMPRESSED   : FALSE
  FILE_SUPPORTS_OBJECT_IDS    : TRUE
  FILE_SUPPORTS_ENCRYPTION    : FALSE
  FILE_NAMED_STREAMS          : FALSE
  FILE_READ_ONLY_VOLUME       : FALSE
  FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
  FILE_SUPPORTS_TRANSACTIONS  : FALSE


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple