This is the mail archive of the cygwin 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: Spam:Re: Find not working w/ Samba drive


On Apr 14 11:08, Corinna Vinschen wrote:
> On Apr 13 11:01, Shankar Unni wrote:
> > Corinna Vinschen wrote:
> > 
> > >Btw., I have hacked together a tiny testcase which lists a directory and
> > >evaluates the inode numbers using readdir and lstat.  I would be
> > >interested to see the output for some smaller directories on shares
> > >using pre-3.0 Samba versions. 
> > 
> > This is the output from a server running
> > 
> >    "Version Samba for GuardianOS v2.6.050.200310180953"
> > 
> > (this is a Snap Appliance file server, which seems to be a 2.4.19 linux 
> > kernel. Not sure if they've tweaked smbd in any way..):
> > 
> > % ./st //hq-share1
> >                Documents d: 000000000000000000, st: 018014724927011328
> >                   Backup d: 000000000000000000, st: 1495201458608421376
> >                   Builds d: 000000000000000000, st: 1297557616381147648
> >                        . d: 000000000000000000, st: 3313024975094127606
> >                       .. d: 000000000000000000, st: 000000000006035200
> > 
> > % % ./st //hq-share1/Backup   (names obfuscated..)
> >                        . d: 000000000000000000, st: 1495201458608421376
> >                       .. d: 000000000000000000, st: 3313024975094127606
> >                    xxxx1 d: 000000000000000000, st: 1531250493513284096
> 
> Sorry, no, that's impossible.  If the file system returns 0 for d_ino,
> or the file system is treated as unreliable, the Cygwin snapshots will
> always fake a non-0 inode number in d_ino.  It looks like you're using
> a non-matching 'struct dirent' definition.  Did you build the executable
> using the dirent.h file from the snapshot?

Anyway, I've finally set up my own stone age old Samba server (version
number 2.2.0) to test this behaviour.

I think I found a pretty simple solution.  It seems that we can differ
between just three types of remote file systems:

- File systems with the FILE_PERSISTENT_ACLS flag not set, for instance
  FAT, FAT32, etc.  Inode number?  Huh!  Here we must fake anyway.

- File systems with the FILE_PERSISTENT_ACLS set, but the returned
  inode numbers are <= UINT32_MAX, for instance NT4 NTFS, Samba < 3.0,
  resp. all remote file systems when running under NT4.  The inode numbers
  returned by these configurations seem to change between calls, so they
  are unreliable and have to be replaced by fake inode numbers.

- File systems with the FILE_PERSISTENT_ACLS set, returning inode numbers
  > UINT32_MAX.  These are the reliable ones, until further notice.

I've applied a patch to Cygwin which handles the remote file systems 
according to the above list now.  Please test the next developers
snapshot from http://cygwin.com/snapshots/


Corinna

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

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


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