* Re: CYGWIN inode over Samba share not constructed from IndexNumber
@ 2012-05-11 16:58 starlight.2012q2
2012-05-11 17:59 ` Corinna Vinschen
0 siblings, 1 reply; 11+ messages in thread
From: starlight.2012q2 @ 2012-05-11 16:58 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: CYGWIN inode over Samba share not constructed from IndexNumber
2012-05-11 16:58 CYGWIN inode over Samba share not constructed from IndexNumber starlight.2012q2
@ 2012-05-11 17:59 ` Corinna Vinschen
2012-05-11 19:49 ` starlight.2012q2
2012-05-11 21:15 ` Jeremy Allison
0 siblings, 2 replies; 11+ messages in thread
From: Corinna Vinschen @ 2012-05-11 17:59 UTC (permalink / raw)
To: cygwin; +Cc: starlight.2012q2, jra
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: CYGWIN inode over Samba share not constructed from IndexNumber
2012-05-11 17:59 ` Corinna Vinschen
@ 2012-05-11 19:49 ` starlight.2012q2
2012-05-11 21:15 ` Jeremy Allison
1 sibling, 0 replies; 11+ messages in thread
From: starlight.2012q2 @ 2012-05-11 19:49 UTC (permalink / raw)
To: cygwin, jra
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: CYGWIN inode over Samba share not constructed from IndexNumber
2012-05-11 17:59 ` Corinna Vinschen
2012-05-11 19:49 ` starlight.2012q2
@ 2012-05-11 21:15 ` Jeremy Allison
2012-05-12 10:54 ` Corinna Vinschen
1 sibling, 1 reply; 11+ messages in thread
From: Jeremy Allison @ 2012-05-11 21:15 UTC (permalink / raw)
To: cygwin, starlight.2012q2, jra
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: CYGWIN inode over Samba share not constructed from IndexNumber
2012-05-11 21:15 ` Jeremy Allison
@ 2012-05-12 10:54 ` Corinna Vinschen
2012-05-14 17:33 ` Jeremy Allison
0 siblings, 1 reply; 11+ messages in thread
From: Corinna Vinschen @ 2012-05-12 10:54 UTC (permalink / raw)
To: cygwin, Jeremy Allison; +Cc: starlight.2012q2
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: CYGWIN inode over Samba share not constructed from IndexNumber
2012-05-12 10:54 ` Corinna Vinschen
@ 2012-05-14 17:33 ` Jeremy Allison
2012-05-21 10:49 ` Corinna Vinschen
0 siblings, 1 reply; 11+ messages in thread
From: Jeremy Allison @ 2012-05-14 17:33 UTC (permalink / raw)
To: cygwin, Jeremy Allison, starlight.2012q2
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: CYGWIN inode over Samba share not constructed from IndexNumber
2012-05-14 17:33 ` Jeremy Allison
@ 2012-05-21 10:49 ` Corinna Vinschen
0 siblings, 0 replies; 11+ messages in thread
From: Corinna Vinschen @ 2012-05-21 10:49 UTC (permalink / raw)
To: cygwin, Jeremy Allison
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: CYGWIN inode over Samba share not constructed from IndexNumber
2012-05-11 16:24 ` Corinna Vinschen
@ 2012-05-11 16:38 ` starlight.2012q2
0 siblings, 0 replies; 11+ messages in thread
From: starlight.2012q2 @ 2012-05-11 16:38 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: CYGWIN inode over Samba share not constructed from IndexNumber
2012-05-11 15:53 starlight.2012q2
2012-05-11 16:22 ` Corinna Vinschen
@ 2012-05-11 16:24 ` Corinna Vinschen
2012-05-11 16:38 ` starlight.2012q2
1 sibling, 1 reply; 11+ messages in thread
From: Corinna Vinschen @ 2012-05-11 16:24 UTC (permalink / raw)
To: cygwin; +Cc: starlight.2012q2
[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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: CYGWIN inode over Samba share not constructed from IndexNumber
2012-05-11 15:53 starlight.2012q2
@ 2012-05-11 16:22 ` Corinna Vinschen
2012-05-11 16:24 ` Corinna Vinschen
1 sibling, 0 replies; 11+ messages in thread
From: Corinna Vinschen @ 2012-05-11 16:22 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* CYGWIN inode over Samba share not constructed from IndexNumber
@ 2012-05-11 15:53 starlight.2012q2
2012-05-11 16:22 ` Corinna Vinschen
2012-05-11 16:24 ` Corinna Vinschen
0 siblings, 2 replies; 11+ messages in thread
From: starlight.2012q2 @ 2012-05-11 15:53 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-05-21 10:49 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-11 16:58 CYGWIN inode over Samba share not constructed from IndexNumber starlight.2012q2
2012-05-11 17:59 ` Corinna Vinschen
2012-05-11 19:49 ` starlight.2012q2
2012-05-11 21:15 ` Jeremy Allison
2012-05-12 10:54 ` Corinna Vinschen
2012-05-14 17:33 ` Jeremy Allison
2012-05-21 10:49 ` Corinna Vinschen
-- strict thread matches above, loose matches on Subject: below --
2012-05-11 15:53 starlight.2012q2
2012-05-11 16:22 ` Corinna Vinschen
2012-05-11 16:24 ` Corinna Vinschen
2012-05-11 16:38 ` starlight.2012q2
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).