[maybe-ITP] gamin

[maybe-ITP] gamin

[Yaakov S (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lapo,

Thanks for the patch.  Please test 0.1.7:

ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-0.1.7-1-src.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-0.1.7-1.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-devel/gamin-devel-0.1.7-1.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-devel/setup.hint
ftp://sunsite.dk/projects/cygwinports/release/gamin/pygamin/pygamin-0.1.7-1.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/gamin/pygamin/setup.hint
ftp://sunsite.dk/projects/cygwinports/release/gamin/setup.hint

I've changed gamin_check_not_fat to handle the lack of GetVolumePathName
on some versions (I hope); but I'm not sure how to handle NT4 on FAT.

#ifdef __CYGWIN__

#include <sys/cygwin.h>
/* FIXME: #define WIN32_LEAN_AND_MEAN ?? */
#define _WIN32_WINNT 0x0500
#include <windows.h>

#endif  /* __CYGWIN__ */

/**
 * gamin_check_not_fat:
 *
 * On Cygwin, check if socket dir is on not a FAT drive.  This is
 * necessary because gamin_check_secure_{dir,path} check permissions,
 * and FAT drives do not have a permissions model; everything is 755.
 *
 * On other platforms, we assume that the socket dir is not on FAT.
 *
 * Returns 1 if <b>not</b> on a FAT drive, 0 if on FAT, -1 in case of error.
 */
static int
gamin_check_not_fat (void)
{
#ifdef __CYGWIN__
  OSVERSIONINFO osvi;
  const char *cygpath;
  char winpath[256];
  char rootdir[256];
  char volname[256];
  char fsname[256];
  DWORD sernum = 0;
  DWORD maxlen = 0;
  DWORD flags = 0;

  osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
  GetVersionEx(&osvi);

  if (osvi.dwPlatformId == 1)   /* VER_PLATFORM_WIN32_WINDOWS */
    {
      return 0;      /* Win9x/Me, must be FAT */
    }

  cygpath = gamin_get_socket_dir();

  cygwin_conv_to_full_win32_path (cygpath, winpath);
  if (!GetVolumePathName(winpath, rootdir, 256))
    {
      fprintf (stderr, "GetVolumePathName: %d\n", GetLastError ());
      return -1;
    }
  if (!GetVolumeInformation (rootdir, volname, 256, &sernum,
                             &maxlen, &flags, fsname, 256))
    {
      fprintf (stderr, "GetVolumeInformation: %d\n", GetLastError ());
      return -1;
    }
  if (strncmp(fsname, "FAT", 3) == 0)
    {
      return 0;
    }
#endif  /* __CYGWIN__ */
  return 1;
}


Yaakov

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD/kzjpiWmPGlmQSMRApKfAJ42267wRhgRRAXNLoD6OFXyZVeWJQCgykY0
ZmxIPEyzVua/Xzy8HdfY9iE=
=87zX
-----END PGP SIGNATURE-----

Re: [maybe-ITP] gamin

[Lapo Luchini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yaakov S (Cygwin Ports) wrote:
> Lapo,
>
> Thanks for the patch.  Please test 0.1.7:
I and Alex tried that against our application and seems to work ok, so
I guess the package is ready for the public ;-)

    Lapo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJECG2qAAoJEJLw0EUVBG94ky4P/A2qvmfQLNWdCFOZuyHUHLHx
etdta3ZYaqA+4e+rnmsfDYgHBpbPlR92Ql8GfgncpJJjlVbcZnIrdIbtlD2g9pZH
tziEL2V8V2uJhZ0SHk7oEEjAejHsOzklbY9aTGixnvfw7CtmPYHXFN8LGTqVB9ri
eZJJCgkviJhDATZpJriloTvn0kk2LgdVtDG6ElyDO9us09t7RRir2WETBShAWZtr
TOMojXoREVDcga4ddmznR6V3IQ5RxhTGlwzBrwwSUsqvwZc1Q4RttcwXJ614RDnj
UeF2ApmrtKWUQvdhtHRuCRfIh0ope+/Uf0INP6GavnZlLK/5NYkjb9oIBoVThio7
eCFGDo7Oq+dsjbSOt5AyK3Wbm0bCI6/g6JgvPqfhWaGkyBiWqfltzo2UGSNhGcED
u2ZneXyZpf60F5Cx8F2O9c0D8dbd6Vjl/U553Sz0Vnx6AEbw/AI1T0SCx28qLT3E
HIzVqt9NyuUnxzEMNohkPN+aWg+C3SaTo3Ubb1rj89PPZdeBaCjvB/RuVTZB8gjb
c4Y4clf6Tod+Y7a/+7u2Wx70VVT12hdu0aYhRC71zGOpZiUcwXdpXlDjEi63hprQ
fvjOPJ+/E9PYPAdQv3W8/PlZl0cnvJVLGmbUOqTpi7Pjr00rnuAESaS7qpA+5LNA
GoR1FswiQeY3ByXQpjRU
=oyMR
-----END PGP SIGNATURE-----

Re: [maybe-ITP] gamin

[Yaakov S (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lapo Luchini wrote:
> I and Alex tried that against our application and seems to work ok, so
> I guess the package is ready for the public ;-)

OK, thanks.  Sorry for the delay; I was just about to ping you when I
saw your response, which I obviously missed before.

Do you have any ideas about how to deal with FAT on NT4?


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEEL30piWmPGlmQSMRAvXeAJ9YNGkxpcpr6jRUyD/0hGKUHUPIWACeP7FO
8G1SxUGY19kX0jG8YC9LweY=
=FEGB
-----END PGP SIGNATURE-----

Re: [maybe-ITP] gamin

[Lapo Luchini]

Yaakov S (Cygwin Ports) wrote:
> OK, thanks.  Sorry for the delay; I was just about to ping you when I
> saw your response, which I obviously missed before.
Eheh =)
Then the package seems to be ready for prime time? (aka upload)
> Do you have any ideas about how to deal with FAT on NT4?
As soon as I have some time I'll try installing NT4 in a virtual machine
and try a bit... but I can't say this is high on my TODO list...
I wonder how many people still use NT4? ^_^"""
Those few might as well use NTFS "as it were FAT", e.g. with less
permissions checks.

   Lapo

Re: [maybe-ITP] gamin

[Yaakov S (Cygwin Ports)]

Lapo Luchini wrote:
> Eheh =)
> Then the package seems to be ready for prime time? (aka upload)

I think so, could you build from source for a GTG review?

> As soon as I have some time I'll try installing NT4 in a virtual machine
> and try a bit... but I can't say this is high on my TODO list...
> I wonder how many people still use NT4? ^_^"""
> Those few might as well use NTFS "as it were FAT", e.g. with less
> permissions checks.

OK, it's not a showstopper.


Yaakov

Re: [maybe-ITP] gamin

[Corinna Vinschen]

On Mar 13 20:11, Yaakov S (Cygwin Ports) wrote:
> Lapo Luchini wrote:
> >Eheh =)
> >Then the package seems to be ready for prime time? (aka upload)
> 
> I think so, could you build from source for a GTG review?
> 
> >As soon as I have some time I'll try installing NT4 in a virtual machine
> >and try a bit... but I can't say this is high on my TODO list...
> >I wonder how many people still use NT4? ^_^"""
> >Those few might as well use NTFS "as it were FAT", e.g. with less
> >permissions checks.
> 
> OK, it's not a showstopper.

I'm a bit irritated about that.  The only thing to do is to load
the GetVolumePathName function dynamically and if that doesn't
work, use a simple string function which cuts the path after either
X:\ or \\server\share.  Just to dismiss NT4 instead of implementing
these 10 lines of code is a bit strange, isn't it?


Corinna

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

Re: [maybe-ITP] gamin

[Lapo Luchini]

Corinna Vinschen wrote:
> Just to dismiss NT4 instead of implementing
> these 10 lines of code is a bit strange, isn't it?
>   
I hardly call this 10 lines of code, it was more than 1 hour worth of
work, emulating that pesky function ;-)
(of course I completely ignored UNC paths and the very idea that
"C:\mnt\driveC" can be a mount point)

Anyway, I wrote something "close enough".
Unfortunately I am well over the free time I had so I have to GTG Yakoov
package another evening =(

% wc -l GVPN.c
88 GVPN.c
% cat GVPN.c
#include <windows.h>
#include <string.h>

BOOL EmGetVolumePathName(
LPCTSTR lpszFileName,
LPTSTR lpszVolumePathName,
DWORD cchBufferLength
)
{
if (cchBufferLength < 4)
return 0;
if (isalpha(lpszFileName[0])) {
lpszVolumePathName[0] = lpszFileName[1] == ':' ? lpszFileName[0] : 'C';
lpszVolumePathName[1] = ':';
lpszVolumePathName[2] = '\\';
lpszVolumePathName[3] = 0;
return 1;
}
if (lpszFileName[0] == '\\' && lpszFileName[1] == '\\' &&
isalpha(lpszFileName[2])) {
int slash = 0;
while (*lpszFileName != 0 && slash < 4) {
if (*lpszFileName == '\\')
++slash;
if (cchBufferLength-- > 1)
*lpszVolumePathName++ = *lpszFileName++;
else
return 0;
}
if (slash == 2)
return 0;
else if (slash == 3) {
if (cchBufferLength-- > 1)
*lpszVolumePathName++ = '\\';
else
return 0;
}
*lpszVolumePathName = 0;
return 1;
}
return 0;
}

BOOL MyGetVolumePathName(
LPCTSTR lpszFileName,
LPTSTR lpszVolumePathName,
DWORD cchBufferLength
)
{
HINSTANCE hinstLib = LoadLibrary("Kernel32");
if (hinstLib != NULL) {
BOOL (*fun)(LPCTSTR, LPTSTR, DWORD) = (BOOL (*)(LPCTSTR, LPTSTR, DWORD))
GetProcAddress(hinstLib, "GetVolumePathNameA");
// If the function address is valid, call the function.
if (fun != NULL) {
BOOL ret = fun(lpszFileName, lpszVolumePathName, cchBufferLength);
FreeLibrary(hinstLib);
return ret;
}
FreeLibrary(hinstLib);
}
return EmGetVolumePathName(lpszFileName, lpszVolumePathName,
cchBufferLength);
}

main() {
char try[][80] = {
"Z",
"Z:",
"Z:\\ciao",
"\\\\cyberone",
"\\\\cyberone\\Musica",
"\\\\cyberone\\Musica\\ciao",
"\\\\cyberone\\Musica-ciao-too-much--way-too-much",
"\\\\\\cyberone"
};
char root[40];
int i;
BOOL b;
for (i = 0; i < sizeof(try) / sizeof(try[0]); ++i) {
printf("Orig = %s\n", try[i]);
strcpy(root, "--------------------");
b = MyGetVolumePathName(try[i], root, 40);
printf("Real = %d %s\n", b, root);
strcpy(root, "--------------------");
b = EmGetVolumePathName(try[i], root, 40);
printf("Emul = %d %s\n", b, root);
putchar('\n');
}
}
% gcc -o GVPN.exe GVPN.c && ./GVPN.exe
Orig = Z
Real = 1 C:\
Emul = 1 C:\

Orig = Z:
Real = 1 Z:\
Emul = 1 Z:\

Orig = Z:\ciao
Real = 1 Z:\
Emul = 1 Z:\

Orig = \\cyberone
Real = 0 --------------------
Emul = 0 \\cyberone----------

Orig = \\cyberone\Musica
Real = 1 \\cyberone\Musica\
Emul = 1 \\cyberone\Musica\

Orig = \\cyberone\Musica\ciao
Real = 1 \\cyberone\Musica\
Emul = 1 \\cyberone\Musica\

Orig = \\cyberone\Musica-ciao-too-much--way-too-much
[some seconds delay, as this share doesn't actually exist]
Real = 0 --------------------
Emul = 0 \\cyberone\Musica-ciao-too-much--way-to

Orig = \\\cyberone
Real = 0 --------------------
Emul = 0 --------------------

Re: [maybe-ITP] gamin

[Lapo Luchini]

[-- Attachment #1: Type: text/plain, Size: 167 bytes --]

Lapo Luchini wrote:
> if (cchBufferLength < 4)
> return 0;
>   
Before being included in the mail this code was better indented, of
course.. let's try with an attach.

[-- Attachment #2: GVPN.c --]
[-- Type: text/plain, Size: 2239 bytes --]

#include <windows.h>
#include <string.h>

BOOL EmGetVolumePathName(
  LPCTSTR lpszFileName,
  LPTSTR lpszVolumePathName,
  DWORD cchBufferLength
)
{
  if (cchBufferLength < 4)
    return 0;
  if (isalpha(lpszFileName[0])) {
    lpszVolumePathName[0] = lpszFileName[1] == ':' ? lpszFileName[0] : 'C';
    lpszVolumePathName[1] = ':';
    lpszVolumePathName[2] = '\\';
    lpszVolumePathName[3] = 0;
    return 1;
  }
  if (lpszFileName[0] == '\\' && lpszFileName[1] == '\\' && isalpha(lpszFileName[2])) {
    int slash = 0;
    while (*lpszFileName != 0 && slash < 4) {
      if (*lpszFileName == '\\')
        ++slash;
      if (cchBufferLength-- > 1)
        *lpszVolumePathName++ = *lpszFileName++;
      else
        return 0;
    }
    if (slash == 2)
      return 0;
    else if (slash == 3) {
      if (cchBufferLength-- > 1)
        *lpszVolumePathName++ = '\\';
      else
        return 0;
    }
    *lpszVolumePathName = 0;
    return 1;
  }
  return 0;
}

BOOL MyGetVolumePathName(
  LPCTSTR lpszFileName,
  LPTSTR lpszVolumePathName,
  DWORD cchBufferLength
)
{
  HINSTANCE hinstLib = LoadLibrary("Kernel32");
  if (hinstLib != NULL) {
    BOOL (*fun)(LPCTSTR, LPTSTR, DWORD) = (BOOL (*)(LPCTSTR, LPTSTR, DWORD))
      GetProcAddress(hinstLib, "GetVolumePathNameA");
    // If the function address is valid, call the function.
    if (fun != NULL) {
      BOOL ret = fun(lpszFileName, lpszVolumePathName, cchBufferLength);
      FreeLibrary(hinstLib);
      return ret;
    }
    FreeLibrary(hinstLib);
  }
  return EmGetVolumePathName(lpszFileName, lpszVolumePathName, cchBufferLength);
}

main() {
  char try[][80] = {
    "Z",
    "Z:",
    "Z:\\ciao",
    "\\\\cyberone",
    "\\\\cyberone\\Musica",
    "\\\\cyberone\\Musica\\ciao",
    "\\\\cyberone\\Musica-ciao-too-much--way-too-much",
    "\\\\\\cyberone"
  };
  char root[40];
  int i;
  BOOL b;
  for (i = 0; i < sizeof(try) / sizeof(try[0]); ++i) {
    printf("Orig = %s\n", try[i]);
    strcpy(root, "--------------------");
    b = MyGetVolumePathName(try[i], root, 40);
    printf("Real = %d %s\n", b, root);
    strcpy(root, "--------------------");
    b = EmGetVolumePathName(try[i], root, 40);
    printf("Emul = %d %s\n", b, root);
    putchar('\n');
  }
}

Re: [maybe-ITP] gamin

[Corinna Vinschen]

On Mar 14 21:58, Lapo Luchini wrote:
> Corinna Vinschen wrote:
> > Just to dismiss NT4 instead of implementing
> > these 10 lines of code is a bit strange, isn't it?
> >   
> I hardly call this 10 lines of code, it was more than 1 hour worth of
> work, emulating that pesky function ;-)
> (of course I completely ignored UNC paths and the very idea that
> "C:\mnt\driveC" can be a mount point)

That's fine since the existance of reparse points corresponds with the
existance of the GetVolumePathName function.  In other words, if you
have to emulate the function, no other volume mount points besides X:\
and \\server\share can exist.

May I suggest to use GetFullPathName on the incoming path first?
Then you can savely remove the "if (isalpha(lpszFileName[0])) {" part.


Corinna

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

Re: [maybe-ITP] gamin

[Lapo Luchini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Corinna Vinschen wrote:
> That's fine since the existance of reparse points corresponds with
> the existance of the GetVolumePathName function.  In other words,
> if you have to emulate the function, no other volume mount points
> besides X:\ and \\server\share can exist.

That's what I supposed, but thanks for the confirmation.

> May I suggest to use GetFullPathName on the incoming path first?
> Then you can savely remove the "if (isalpha(lpszFileName[0])) {"
> part.

OK, will modify it ASAP (which can be a while, graduation thesis
deadline in less than 2 weeks...).

BTW: would this only be useful to gamin or could be useful enough to
be included in cygwin1.dll?
After all knowing the "possibilities" (i.e. the presence of
permissions, the granularity of mtime) of a mount can be useful elsewhere?
In that case just let me know and I will adapt the patch to apply
there and change the one to gamin (I already have done the copyright
assignment).

    Lapo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJEHBWIAAoJELBiMTth2oCDNtoP/0Kc6E0s6HCkLOfF5CLzVlJx
BFlA6iDeQfpYsW+BbTONt5qMLZlR6e+DF44V8jBVin94q/WTM/GWt7ulCOZ7SwWS
/hBh5TR9xwrFveAEIleG7aL8Yo8S42s4pvOSTh8kaXCI7YgV7RJDb8YwgiBLFnU0
FNmp0wbadILVZyK+zGm1zQayCTN7pX3dCsfcugi7vkRCKN8pd+albvHI3K4zaUhJ
fsXvSOMQahq1fGOWZ9qukrh1fx1MK6kSMX5MtuBt3mHQosN7FuX3iwfK9Y6DM557
y7LYU89CSTyVYGquuNGF17VUlBhbWwHE0jc+WWPGr4JtLgQTrowzqfNx6iNW048y
yDGu9tyAu7ET87S87jywkxqihYAdEnE7JqVFu4NTn/KNNSa2r91f5SpihLer3xWL
SlSeC3G1abIXZh2PaFVRHoKS4X4qmSwP6TlGXdZM7+tRo0E54DeYVA5QG4dQuko4
9jJZ7jZZGS/Qjpg35Hm+YvWC+YzOxNtYZtpFGWonWrWGesi5UZvbVnlh6znspCDY
sGVYTwt6drqbuJ3eyin8f3rAnQIRRbYeKx/5ed/pQSNVtifJK5tKzKRbLwNTumXB
25OnLA4TyduAREqiuK4GlF0fYituhw9xPtE7Kcga6CLPsTRwf+prXM+dgZU991Le
jd39JX1oFve1DmdT0vqv
=T4Zf
-----END PGP SIGNATURE-----

Re: [maybe-ITP] gamin

[Corinna Vinschen]

On Mar 18 15:13, Lapo Luchini wrote:
> > May I suggest to use GetFullPathName on the incoming path first?
> > Then you can savely remove the "if (isalpha(lpszFileName[0])) {"
> > part.
> 
> OK, will modify it ASAP (which can be a while, graduation thesis
> deadline in less than 2 weeks...).
> 
> BTW: would this only be useful to gamin or could be useful enough to
> be included in cygwin1.dll?

Thanks for your offer, but I think Cygwin will not need it.

First of all, calling GetVolumePathName is *incredibly* slow.  Since the
root directory is evaluated on each path handling right now, the cost of
using GetVolumePathName is unbearable.

The next problem is that the Cygwin function requesting volume
information uses the Win32 function GetVolumeInformation, which needs
the path to the root directory, unfortunately.  This is still required
as long as we support 9x (blerch), but on NT, the underlying native
volume information function ZwQueryVolumeInformationFile doesn't need
the root path at all.  A handle to any file or directory on the volume
is sufficient, so in turn there's no need to know the Win32 root
directory anymore to request information when using this function.

Consequentially I'm planning to change the volume handling in Cygwin in
the near future (for 1.5.21), so that evaluating the volume root
directory will only be required on 9x.


Corinna

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

Re: [maybe-ITP] gamin

[Yaakov S (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lapo Luchini wrote:
> Corinna Vinschen wrote:
>>> That's fine since the existance of reparse points corresponds with
>>> the existance of the GetVolumePathName function.  In other words,
>>> if you have to emulate the function, no other volume mount points
>>> besides X:\ and \\server\share can exist.
> 
> That's what I supposed, but thanks for the confirmation.
> 
>>> May I suggest to use GetFullPathName on the incoming path first?
>>> Then you can savely remove the "if (isalpha(lpszFileName[0])) {"
>>> part.
> 
> OK, will modify it ASAP (which can be a while, graduation thesis
> deadline in less than 2 weeks...).

Hmmm, this has seemingly stalled for about two months now.  Where are we
holding with gamin now?


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEc4hYpiWmPGlmQSMRApp9AKD1lh3flrTYs1GLXnjl3S3F9ECPLACgv1PX
kke4KrLVoRGQ22uqKbOuy5U=
=Gd9h
-----END PGP SIGNATURE-----

Re: [maybe-ITP] gamin

[Lapo Luchini]

Yaakov S (Cygwin Ports) wrote:
> Lapo Luchini wrote:
> >> Corinna Vinschen wrote:
> >>>> That's fine since the existance of reparse points corresponds with
> >>>> the existance of the GetVolumePathName function.  In other words,
> >>>> if you have to emulate the function, no other volume mount points
> >>>> besides X:\ and \\server\share can exist.
> >> That's what I supposed, but thanks for the confirmation.
> >>
> >>>> May I suggest to use GetFullPathName on the incoming path first?
> >>>> Then you can savely remove the "if (isalpha(lpszFileName[0])) {"
> >>>> part.
> >> OK, will modify it ASAP (which can be a while, graduation thesis
> >> deadline in less than 2 weeks...).
>
> Hmmm, this has seemingly stalled for about two months now.  Where are we
> holding with gamin now?
Apparently the size of the object "writing thesis + defending it" pushed
it in the swap file and was then forgotten there.
Thanks for having remembered it to me, I'll take a look at it ASAP
(really, this time) ;-)
(same goes for the package I didn't yet update yet, such as rsync)

    Lapo

Re: [maybe-ITP] gamin

[Lapo Luchini]

Yaakov S (Cygwin Ports) wrote:
> Lapo Luchini wrote:
> >> I guess you did try with latest version, 0.1.7..?
> >> Both under FreeBSD and Cygwin we didn't manage to have a working
> >> gamin-0.1.7.
> >> But gamin-0.1.5 works perfectly, it seems. (Using polling, of course.)
>
> Actually, neither 0.1.6 (which was current when I first tried) nor 0.1.7
> worked.
Today Alex managed to fix a couple nasty bugs in Gamin 0.1.7 and now on
Debian polling is working (yes, it seems that 0.1.6 and 0.1.7 were
released without even a single test of the polling back-end).
I see no reason why it shouldn't work on FreeBSD and Cygwin also, but we
will test that tomorrow morning.
After it is tested, expect a patch in your inbox anytime soon ;-)

    Lapo

Re: [maybe-ITP] gamin

[Corinna Vinschen]

On Feb  3 11:11, Lapo Luchini wrote:
> Corinna Vinschen wrote:
> > Careful.  GetVolumePathName is not available on 9x/Me and NT4.  In those
> > cases you better use a simple string algorithm which shortens the path
> > to X:\ or \\server\share.
> >   
> Does it have sense to check if a network share "is FAT or not"?

Yes.


Corinna

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

Re: [maybe-ITP] gamin

[Lapo Luchini]

Corinna Vinschen wrote:
> Careful.  GetVolumePathName is not available on 9x/Me and NT4.  In those
> cases you better use a simple string algorithm which shortens the path
> to X:\ or \\server\share.
>   
Does it have sense to check if a network share "is FAT or not"?

Re: [maybe-ITP] gamin

[Lapo Luchini]

Yaakov S (Cygwin Ports) wrote:
> How about this; gamin_check_not_fat() can be an additional condition
> to the "wrong permissions" errors.
Seems to be the best solution to me.
If the disk is FAT there's not point being picky about permissions, as
the files of the user will be readable to every other user anyway, so if
the socket is readable is not a problem.
> (Believe it or not, my C programming isn't that strong.  So please
> check this over, although this was mostly borrowed from Corinna.)
Also my "mad C skills" are a bit weakened after years of Java and C++
OOP, but that code seems reasonable to me.
> And it looks like FreeBSD has yet to figure it out themselves either,
> so at least we have good company. :-)
Eh eh, yes; anyway Alex is a FreeBSD committer so if we find the issue
it will probably be solved at once on both platforms.

    Lapo

Re: [maybe-ITP] gamin

[Corinna Vinschen]

On Feb  1 20:22, Yaakov S (Cygwin Ports) wrote:
>   cygwin_conv_to_full_win32_path (cygpath, winpath);
>   if (!GetVolumePathName(winpath, rootdir, 256))

Careful.  GetVolumePathName is not available on 9x/Me and NT4.  In those
cases you better use a simple string algorithm which shortens the path
to X:\ or \\server\share.


Corinna

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

Re: [maybe-ITP] gamin

[Yaakov S (Cygwin Ports)]

Lapo Luchini wrote:
> Yes, probably checking dinamically if the disk is FAT and ignore
> permission issues in that case is the best solution.

How about this; gamin_check_not_fat() can be an additional condition to 
the "wrong permissions" errors.

(Believe it or not, my C programming isn't that strong.  So please check 
this over, although this was mostly borrowed from Corinna.)

#ifdef __CYGWIN__

/* Code adapted from Corinna Vinschen's getvolumeinfo.c:
    http://www.cygwin.com/ml/cygwin/2006-01/msg00818.html */

#include <stdio.h>
#include <string.h>
#include <sys/cygwin.h>
#define _WIN32_WINNT 0x0500
#include <windows.h>

#ifndef FILE_READ_ONLY_VOLUME
#define FILE_READ_ONLY_VOLUME 0x80000
#endif

#endif  /* __CYGWIN__ */

/**
  * gamin_check_not_fat:
  *
  * On Cygwin, check if socket dir is on not a FAT drive.  This is
  * necessary because gamin_check_secure_{dir,path} check permissions,
  * and FAT drives do not have a permissions model; everything is 755.
  *
  * On other platforms, we assume that the socket dir is not on FAT.
  *
  * Returns 1 if NOT on a FAT drive, 0 if on FAT, -1 in case of error.
  */
static int
gamin_check_not_fat (void)
{
#ifdef __CYGWIN__
   const char *cygpath;
   char winpath[256];
   char rootdir[256];
   char volname[256];
   char fsname[256];
   DWORD sernum = 0;
   DWORD maxlen = 0;
   DWORD flags = 0;

   cygpath = gamin_get_socket_dir();

   cygwin_conv_to_full_win32_path (cygpath, winpath);
   if (!GetVolumePathName(winpath, rootdir, 256))
     {
       fprintf (stderr, "GetVolumePathName: %d\n", GetLastError ());
       return -1;
     }
   if (!GetVolumeInformation (rootdir, volname, 256, &sernum,
                              &maxlen, &flags, fsname, 256))
     {
       fprintf (stderr, "GetVolumeInformation: %d\n", GetLastError ());
       return -1;
     }
   if (strcmp(fsname, "FAT") == 0)
     {
       return 0;
     }
#endif  /* __CYGWIN__ */
   return 1;
}

> If you mean "no one else will do that for you" I do perfectly agree, my
> message was maybe a bit unclear about that, but I wasn't asking anyone
> actually ;-)

Exactly.

> Alex already ported the patches to 0.1.7 but it seems that 0.1.7 breaks
> polling itself, probably because there are no more linuxes without
> dnotify or inotify around, so the author didn't notice. We are
> investigating this problem, anyway.

And it looks like FreeBSD has yet to figure it out themselves either, so 
at least we have good company. :-)


Yaakov

Re: [maybe-ITP] gamin

[Lapo Luchini]

Yaakov S (Cygwin Ports) wrote:
> For the archives (and my own reference), that's:
> http://www.cygwin.com/ml/cygwin/2006-01/msg00818.html
I'll take a look, but I wonder...
>> Exactly, and so can NT.  Better to find out what disk we're working
>> with.
> Which again would imply that working with FAT drives is broken on
> gamin in general, not just on Windows.
...I wonder if the "best" solution isn't simply to warn the user to use
NTFS in the first place.
Either that or we could simply add an environment variable like
GAMIN_PERMS_IGNORE or something like that.
That way, the user would need to be aware of the security problem and
actively "avoid" it.

But again if the full disk is FAT every user gets access to every file
anyway, so there's no point in trying to enforce any different security
policy.

Yes, probably checking dinamically if the disk is FAT and ignore
permission issues in that case is the best solution.
>> Floppies are usually FAT.  How about using one? :-)
> What an idea. :-)  I'll see what I can do tomorrow.
Either that or a virtual drive.

PS: I noticed the problem because the WinXP we have got here in the
office happens to use FAT32, in fact ;-)
(but I was thinking about "converting" it anyway soon)

> > About possibly implementing an NT backend (using
> > http://tinyurl.com/c27fn probably), well, I guess it is feasible but
> > with 1300+ lines of code for all but the simplest backend (dnotify)
>
> You understand, of course, that this will be up to you to write.  I 
> would like to see these FreeBSD changes ported to 0.1.7, which should be 
> easier than writing a new backend (?).
If you mean "no one else will do that for you" I do perfectly agree, my
message was maybe a bit unclear about that, but I wasn't asking anyone
actually ;-)
If you, instead, were meaning "you /have/ to do it anyway" I'm not quite
sure I do agree: it's not a very simple task and polling gives decent
performance/functionality already, so I (nor Alex) have a strong
work-related reason to code that backend very soon (but probably will do
that anyway, eventually, as the time permits).

Alex already ported the patches to 0.1.7 but it seems that 0.1.7 breaks
polling itself, probably because there are no more linuxes without
dnotify or inotify around, so the author didn't notice. We are
investigating this problem, anyway.

> > What did you mean exactly with "vary each time"?
>
> Sometimes C test 4 failed and sometimes not; some of the python tests 
> would fail but either different ones or in different ways.
I also had test 4 crash, but it all resolved to a "killall" script I
wrote that working nothing like the real killall, once I renamed that to
my_killall test 4 began to work flawlessly. Test 4 is the only one that
tries to kill the server, so I guess it may be a problem of process
killing or the such. I'll try that test a bit more times.

I didn't take a close look at the python tests.

    Lapo

Re: [maybe-ITP] gamin

[Yaakov S (Cygwin Ports)]

Igor Peshansky wrote:
> I'm sure there is -- Corinna posted a test program to cygwin@ earlier this
> month that prints various attributes of the drives.  It was meant for
> shares, but I'm sure it also applies to local drives.  Besides, cygcheck
> prints out what kind of drive it is, so you can get some code from there
> too.

For the archives (and my own reference), that's:

http://www.cygwin.com/ml/cygwin/2006-01/msg00818.html

> Umm, you don't want to assume that any disk is NTFS on NT...  See below.

I agree that it wasn't a perfect assumption.

> Exactly, and so can NT.  Better to find out what disk we're working with.

Which again would imply that working with FAT drives is broken on gamin 
in general, not just on Windows.

> Floppies are usually FAT.  How about using one? :-)

What an idea. :-)  I'll see what I can do tomorrow.


Yaakov

Re: [maybe-ITP] gamin

[Yaakov S (Cygwin Ports)]

Christopher Faylor wrote:
> FAT but not FAT32.  There can be differences.

AFAIK, we're only concerned with the permissions issue, which IIRC is 
the same for both.

> Can you format a floppy as FAT32?

Not on Windows.  A FAT32 volume must have a minimum of 65,527 clusters, 
with a minimum cluster size of 512 bytes, which adds up to be a lot more 
than a floppy.

http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prkc_fil_lxty.asp
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/prkc_fil_tdrn.asp


Yaakov

Re: [maybe-ITP] gamin

[Igor Peshansky]

On Mon, 30 Jan 2006, Christopher Faylor wrote:

> On Mon, Jan 30, 2006 at 08:29:05PM -0500, Igor Peshansky wrote:
> >On Mon, 30 Jan 2006, Yaakov S (Cygwin Ports) wrote:
> >>Possibly, but I only have NTFS drives at my disposal.
> >
> >Floppies are usually FAT.  How about using one?  :-)
>
> FAT but not FAT32.  There can be differences.

Good point.

> Can you format a floppy as FAT32?

According to <http://support.microsoft.com/?kbid=253774>, no:

	Floppy disks are formatted as FAT12, even if you have formatted
	your hard disk to FAT32. The utility, Format.com is prohibited
	from making a FAT32 file system on a floppy disk.

It should be possible to create a small partition for testing, but it's
probably much easier to do in VMware...
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

Re: [maybe-ITP] gamin

[Christopher Faylor]

On Mon, Jan 30, 2006 at 08:29:05PM -0500, Igor Peshansky wrote:
>On Mon, 30 Jan 2006, Yaakov S (Cygwin Ports) wrote:
>>Possibly, but I only have NTFS drives at my disposal.
>
>Floppies are usually FAT.  How about using one?  :-)

FAT but not FAT32.  There can be differences.

Can you format a floppy as FAT32?

cgf

Re: [maybe-ITP] gamin

[Igor Peshansky]

On Mon, 30 Jan 2006, Yaakov S (Cygwin Ports) wrote:

> Lapo Luchini wrote:
> > I needed this patch in order to have it working on FAT32 disks, but
> > both on FAT and NTFS the test results seem quite consistent to me: all
> > is good on NTFS and all-but-test-9 on FAT.
>
> I'd rather not outright #ifndef __CYGWIN__ these if there's a better
> solution.
>
> I don't know if there's a way to determine if the drive is FAT or NTFS,

I'm sure there is -- Corinna posted a test program to cygwin@ earlier this
month that prints various attributes of the drives.  It was meant for
shares, but I'm sure it also applies to local drives.  Besides, cygcheck
prints out what kind of drive it is, so you can get some code from there
too.

> but AFAICS there is a way to determine if Windows is NT or not (and
> presume that NT is running on NTFS and not FAT, which should be the
> norm), for example:

Umm, you don't want to assume that any disk is NTFS on NT...  See below.

> http://cygnome2.sourceforge.net/install/release/nautilus/nautilus-2.4.2-cygwin.patch
>
> Although this raises an interesting question: Linux can also use FAT
> disks, so what happens then??

Exactly, and so can NT.  Better to find out what disk we're working with.

> > Test 9 checks if a directory mtime gets modified when you write a file
> > in it and I guess FAT just doesn't work that way.
>
> Possibly, but I only have NTFS drives at my disposal.

Floppies are usually FAT.  How about using one? :-)

HTH,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

Re: [maybe-ITP] gamin

[Yaakov S (Cygwin Ports)]

Lapo Luchini wrote:
> I needed this patch in order to have it working on FAT32 disks, but
> both on FAT and NTFS the test results seem quite consistent to me: all
> is good on NTFS and all-but-test-9 on FAT.

I'd rather not outright #ifndef __CYGWIN__ these if there's a better 
solution.

I don't know if there's a way to determine if the drive is FAT or NTFS, 
but AFAICS there is a way to determine if Windows is NT or not (and 
presume that NT is running on NTFS and not FAT, which should be the 
norm), for example:

http://cygnome2.sourceforge.net/install/release/nautilus/nautilus-2.4.2-cygwin.patch

Although this raises an interesting question: Linux can also use FAT 
disks, so what happens then??

> Test 9 checks if a directory mtime gets modified when you write a file
> in it and I guess FAT just doesn't work that way.

Possibly, but I only have NTFS drives at my disposal.

> What did you mean exactly with "vary each time"?

Sometimes C test 4 failed and sometimes not; some of the python tests 
would fail but either different ones or in different ways.

> Reading that file, me and Alex have a doubt: is it normal that only 2
> out of 3 times defined(__FreeBSD__) is added in the FreeBSD patch set
> you added a corresponding defined(__CYGWIN__)?
> I don't quite get that part, so I guess that you did either the right
> thing or did forget about the last case ;-)

Hmmm, probably missed that one.  I'll try to take a look at this, as 
well as the FAT patch, tomorrow.

> About possibly implementing an NT backend (using
> http://tinyurl.com/c27fn probably), well, I guess it is feasible but
> with 1300+ lines of code for all but the simplest backend (dnotify)
> we're a bit scared about that, and moreover efficiency is not a really
> big issue in our case.
> "Not in the short time period", that's for sure.

You understand, of course, that this will be up to you to write.  I 
would like to see these FreeBSD changes ported to 0.1.7, which should be 
easier than writing a new backend (?).


Yaakov

Re: [maybe-ITP] gamin

[Lapo Luchini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yaakov S (Cygwin Ports) wrote:
> OK, I have it built; but test results are sporadic (they vary each
> time I run the tests).
I needed this patch in order to have it working on FAT32 disks, but
both on FAT and NTFS the test results seem quite consistent to me: all
is good on NTFS and all-but-test-9 on FAT.
Test 9 checks if a directory mtime gets modified when you write a file
in it and I guess FAT just doesn't work that way.

What did you mean exactly with "vary each time"?

- --- gamin-0.1.5-orig/libgamin/gam_api.c 2005-08-06 00:31:46.000000000
+0200
+++ gamin-0.1.5/libgamin/gam_api.c      2006-01-30 13:17:14.000000000
+0100
@@ -228,12 +229,15 @@
                  dir);
        goto unsafe;
     }
+#ifndef __CYGWIN__
+    // this can't work on FAT disks, that have no permissions
     if (st.st_mode & (S_IRWXG|S_IRWXO)) {
        gam_error(DEBUG_INFO,
                  "Socket directory %s has wrong permissions\n",
                  dir);
        goto unsafe;
     }
+#endif
     if (((st.st_mode & (S_IRWXU)) != S_IRWXU)) {
        gam_error(DEBUG_INFO,
                  "Socket directory %s has wrong permissions\n",
@@ -307,12 +311,15 @@
        goto cleanup;
     }
 #endif
+#ifndef __CYGWIN__
+    // this can't work on FAT disks, that have no permissions
     if (st.st_mode & (S_IRWXG|S_IRWXO)) {
        gam_error(DEBUG_INFO,
                  "Socket %s has wrong permissions\n",
                  path);
        goto cleanup;
     }
+#endif
     /*
      * Looks good though binding may fail due to an existing server
      */

Reading that file, me and Alex have a doubt: is it normal that only 2
out of 3 times defined(__FreeBSD__) is added in the FreeBSD patch set
you added a corresponding defined(__CYGWIN__)?
I don't quite get that part, so I guess that you did either the right
thing or did forget about the last case ;-)

About possibly implementing an NT backend (using
http://tinyurl.com/c27fn probably), well, I guess it is feasible but
with 1300+ lines of code for all but the simplest backend (dnotify)
we're a bit scared about that, and moreover efficiency is not a really
big issue in our case.
"Not in the short time period", that's for sure.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJD3iRJAAoJEJLw0EUVBG94d18QAKugLtFSL51ExnjXNW39hpHY
PSJ6HvJxpQDDe9/Cx0JHIrvADvgWGS3Yfl19N4p1Vq/pYTWbuh4DgXyHhQyCik+W
biawt3ocFk7xRzcy/1hRt5KqXPYhY5EspuZTekv9qTVh59rTb/MWkSGCAIAsadxO
vbnyLP13yergGLgmrHeDoR2UIqOqL2BpVsjfMsWhsQxyPiZNMRoD0ggt2/AsvKQg
OJ3exomeN93OweNw11ETZazz/HzZVCgslNz2kPbgy8JpZDphA22XLFieijDJdQwg
bixfhsEBLiN8qQDhQi5b9wh3EsnfDSRoo1OW2FoO0hAOHHemOcTc1/nC2jP5hMUe
Xzj+BXAVz01BrvrsRqcQ7tcjcAV5tXLZum8FdxnBGcWONcpq+7UnbcvOC9svvTMA
h4adUv577R5ciE6xwNcMsISjk+aHoV3oAliYe9RCnH7Lx9fKV7EC4SZFDbOCwMkd
erqkpJMwGRfksjTLBncX9ctazo0WPi0GeyU0sO7BkRb75Gq2fE84X5+Ny+kbhihW
TzSKbphJhCzFoyM1QG/sRa/dMN3X0rqjeoiPsq2MZIG39zMy8N9b95xIn8tb2yMI
6wcE6i////PC8mzxJBqRc/aXnx3dFhlZrVjIrnhYAhwiVvznwSZQUNq+wNVb9taE
5v5LUSzA6zijAAvi7nbW
=mC7m
-----END PGP SIGNATURE-----

Re: [maybe-ITP] gamin

[Lapo Luchini]

Corinna Vinschen wrote:
> On Jan 26 17:05, Yaakov S (Cygwin Ports) wrote:
>   
>> Try these:
>>
>> ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-0.1.5-1-src.tar.bz2
>> ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-0.1.5-1.tar.bz2
>> ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-devel/gamin-devel-0.1.5-1.tar.bz2
>> ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-devel/setup.hint
>> ftp://sunsite.dk/projects/cygwinports/release/gamin/pygamin/pygamin-0.1.5-1.tar.bz2
>> ftp://sunsite.dk/projects/cygwinports/release/gamin/pygamin/setup.hint
>> ftp://sunsite.dk/projects/cygwinports/release/gamin/setup.hint
>>     
>
> Lapo, you asked for it, how about actually reviewing it?
>   
Yes of course, just the time to actually get in the office, this is work ;-)

At a first look it seems to have a bug we discovered Thursday after the
mail exchange with Yaakov:
  Socket directory /tmp/fam-lapo has wrong permissions
This is probably caused by the fact that on FAT permissions are always
755, no matter what.

I and Alex will now inspect his source package and patches more
specifically and propose further patches, like one to ignore the
permission actually (I wonder if there is a "better" solution to it).

    Lapo

Re: [maybe-ITP] gamin

[Corinna Vinschen]

On Jan 26 17:05, Yaakov S (Cygwin Ports) wrote:
> Try these:
> 
> ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-0.1.5-1-src.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-0.1.5-1.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-devel/gamin-devel-0.1.5-1.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-devel/setup.hint
> ftp://sunsite.dk/projects/cygwinports/release/gamin/pygamin/pygamin-0.1.5-1.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/gamin/pygamin/setup.hint
> ftp://sunsite.dk/projects/cygwinports/release/gamin/setup.hint

Lapo, you asked for it, how about actually reviewing it?


Corinna

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

Re: [maybe-ITP] gamin

[Yaakov S (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yaakov S (Cygwin Ports) wrote:
> Now that I have an existing patchset, then it's a different story
> entirely.  This does affect me as well, so let me see what I can do.
> I'm building 0.1.5 with these patches now.

OK, I have it built; but test results are sporadic (they vary each time
I run the tests).

Try these:

ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-0.1.5-1-src.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-0.1.5-1.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-devel/gamin-devel-0.1.5-1.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/gamin/gamin-devel/setup.hint
ftp://sunsite.dk/projects/cygwinports/release/gamin/pygamin/pygamin-0.1.5-1.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/gamin/pygamin/setup.hint
ftp://sunsite.dk/projects/cygwinports/release/gamin/setup.hint


Yaakov

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD2VW/piWmPGlmQSMRAmbvAJ9BVzGg9muaA3ilY8EpsAl65rgSagCg0v5p
bR/QRO6KfdHIjviNR+Teg/I=
=veZa
-----END PGP SIGNATURE-----

Re: [maybe-ITP] gamin

[Yaakov S (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lapo Luchini wrote:
> I guess you did try with latest version, 0.1.7..?
> Both under FreeBSD and Cygwin we didn't manage to have a working
> gamin-0.1.7.
> But gamin-0.1.5 works perfectly, it seems. (Using polling, of course.)

Actually, neither 0.1.6 (which was current when I first tried) nor 0.1.7
worked.

> Yes, and most of the patches that some FreeBSD folk did some time ago
> for version 0.1.5 were in fact included upstream. Unfortunately 0.1.7
> seems to have added some /other/ Linux-tiedness, as it doesn't work,
> even "porting" those patches not included from 0.1.5 to 0.1.7.

I presume these are the patches to which you're referring?

http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/gamin/files/

> Well, then.
> Me and Alessandro are willing to manage the package, as we need it at
> work anyway, and having it available thru setup.exe certainly eases things.
> (well of course if you insist to package it yourself, we won't complain ^_^)

Now that I have an existing patchset, then it's a different story
entirely.  This does affect me as well, so let me see what I can do.
I'm building 0.1.5 with these patches now.

> a. we do not need latest version (which seems to be quite changed)
> enough to justify devoting the necessary resources to make it working,
> or at least not soon

Agreed, considering the circumstances.

> b. we would produce a non-threaded library (see "Java and Cygwin: a
> difficult relation", a few minutes ago on cygwin@): does gnome-vfs2 or
> Gnome in general need the threaded library or not?

Not AFAIK.  In fact, gnome-vfs2 just looks for fam.h and libfam, which
could be provided by either FAM or Gamin; I don't think it actually
affects the gamin API either way, just the functionality.

> is there a way to produce two different but non clashing packages,
> in case of need?

No, but it shouldn't be necessary.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFD2UJtpiWmPGlmQSMRAtMkAJ4iBxzGjbCSTjugtwm4b5LMw2DS0wCg5fdw
nmGh4GnTBJHUjb8NjqM+Meo=
=9J8i
-----END PGP SIGNATURE-----

Re: [maybe-ITP] gamin

[Lapo Luchini]

Yaakov S (Cygwin Ports) wrote:
> AFAIK it doesn't.  (Otherwise I would have included it in Cygwin Ports
> a while ago, or even the distro, as gnome-vfs2 can use it.)  It does
> compile easily, as do the python bindings, but while the server
> launches, the test suite fails horribly, seemingly because it can't
> pick up any FS changes.
I guess you did try with latest version, 0.1.7..?
Both under FreeBSD and Cygwin we didn't manage to have a working
gamin-0.1.7.
But gamin-0.1.5 works perfectly, it seems. (Using polling, of course.)
> At this point Gamin is fairly tied to Linux, portability is not a
> primary goal at this stage but if you have portability patches they
> are welcome.
Yes, and most of the patches that some FreeBSD folk did some time ago
for version 0.1.5 were in fact included upstream. Unfortunately 0.1.7
seems to have added some /other/ Linux-tiedness, as it doesn't work,
even "porting" those patches not included from 0.1.5 to 0.1.7.
> Sounds like this is a case of PTC.  I don't have the resources to
> devote to getting this working, but if someone else does, I will
> happily built  and test this.
Well, then.
Me and Alessandro are willing to manage the package, as we need it at
work anyway, and having it available thru setup.exe certainly eases things.
(well of course if you insist to package it yourself, we won't complain ^_^)

Only catch would be that:
a. we do not need latest version (which seems to be quite changed)
enough to justify devoting the necessary resources to make it working,
or at least not soon
b. we would produce a non-threaded library (see "Java and Cygwin: a
difficult relation", a few minutes ago on cygwin@): does gnome-vfs2 or
Gnome in general need the threaded library or not? is there a way to
produce two different but non clashing packages, in case of need?

Re: [maybe-ITP] gamin

[Lapo Luchini]

I hereby forward the answer of the friend of mine, that is not
subscribed here.
I also add that probably http://tinyurl.com/c27fn or the cited "change
journals" is the way to go.

=================

Christopher Faylor <cgf-no-personal-reply-please@...> writes:

> >>This really works on cygwin? 

It seems so, why stat'ing files shouldn't work on cygwin?

> >AFAIK it doesn't.  (Otherwise I would have included it in Cygwin Ports a 
> >while ago, or even the distro, as gnome-vfs2 can use it.)  It does 
> >compile easily, as do the python bindings, but while the server 
> >launches, the test suite fails horribly, seemingly because it can't pick 
> >up any FS changes.

Indeed the tests run fine here.

> >At this point Gamin is fairly tied to Linux, portability is not a 
> >primary goal at this stage but if you have portability patches they are 
> >welcome.

This is very true, out of the box gamin compiles only with Linux (and the latest
release doesn't work with polling), but with a bunch of patches it works on
FreeBSD and cygwin, too.

> >[1] http://www.gnome.org/~veillard/gamin/overview.html
> Windows has some capabilities for this sort of thing.  Does someone want
> to research what gamin is using on linux and present it to the cygwin
> list?  Maybe Corinna or I can implement something based on that.

On Linux it can use the old dnotify interface and the new Inotify. On FreeBSD it
uses the kqueue backend. The backend is kernel specific, I don't think it's very
useful to know what is used on other OSes, but what Windows kernel can do to
notify the gam_server events like "FileCreated", "FileModified", "FileDeleted",
"FileExecuted", etc. In any case the general polling backend seems to work
already. If you like to implement a windows kernel backed, well, that would be
great.

--
Alex Dupre

Re: [maybe-ITP] gamin

[Lapo Luchini]

Christopher Faylor wrote:
>> Gamin can use any of several backends, most of which are kernel-based, 
>> but the only one that can build on Cygwin is polling.
>>     
At least initially we are trying just that: the polling backend.
Using release 0.1.5 and some of the FreeBSD patches (they seem to be
more "not-Linux patches" more than "FreeBSD-specific" patches, except,
of course, the one that implement the kqueue backend) yesterday we
managed to get a succesful "make tests" result. Except test #4.
> Windows has some capabilities for this sort of thing.  Does someone want
> to research what gamin is using on linux and present it to the cygwin
> list?  Maybe Corinna or I can implement something based on that.
>   
If we really will have to support it on Windows for an internal product,
efficiency can become quite an issue, and supporting the
Windows-specific mode of listening for "changed files events" could be
quite important.
We will take at least a look as it to evaluate feasibility and, in case
it is, maybe implement it altogether.

    Lapo

Re: [maybe-ITP] gamin

[Christopher Faylor]

On Wed, Jan 25, 2006 at 06:36:36PM -0600, Yaakov S (Cygwin Ports) wrote:
>Christopher Faylor wrote:
>>This really works on cygwin? 
>
>AFAIK it doesn't.  (Otherwise I would have included it in Cygwin Ports a 
>while ago, or even the distro, as gnome-vfs2 can use it.)  It does 
>compile easily, as do the python bindings, but while the server 
>launches, the test suite fails horribly, seemingly because it can't pick 
>up any FS changes.
>
>> I would have thought that there were operating system hooks needed.
>> Or does it just poll files?
>
>Gamin can use any of several backends, most of which are kernel-based, 
>but the only one that can build on Cygwin is polling.
>
>Quoting from their website[1]:
>
>At this point Gamin is fairly tied to Linux, portability is not a 
>primary goal at this stage but if you have portability patches they are 
>welcome.
>
>[1] http://www.gnome.org/~veillard/gamin/overview.html
>
>Sounds like this is a case of PTC.  I don't have the resources to devote 
>to getting this working, but if someone else does, I will happily built 
> and test this.

Windows has some capabilities for this sort of thing.  Does someone want
to research what gamin is using on linux and present it to the cygwin
list?  Maybe Corinna or I can implement something based on that.

cgf

Re: [maybe-ITP] gamin

[Yaakov S (Cygwin Ports)]

Christopher Faylor wrote:
> This really works on cygwin? 

AFAIK it doesn't.  (Otherwise I would have included it in Cygwin Ports a 
while ago, or even the distro, as gnome-vfs2 can use it.)  It does 
compile easily, as do the python bindings, but while the server 
launches, the test suite fails horribly, seemingly because it can't pick 
up any FS changes.

 > I would have thought that there were operating system hooks needed.
 > Or does it just poll files?

Gamin can use any of several backends, most of which are kernel-based, 
but the only one that can build on Cygwin is polling.

Quoting from their website[1]:

At this point Gamin is fairly tied to Linux, portability is not a 
primary goal at this stage but if you have portability patches they are 
welcome.

[1] http://www.gnome.org/~veillard/gamin/overview.html

Sounds like this is a case of PTC.  I don't have the resources to devote 
to getting this working, but if someone else does, I will happily built 
  and test this.


Yaakov

Re: [maybe-ITP] gamin

[Christopher Faylor]

On Thu, Jan 26, 2006 at 12:07:36AM +0100, Lapo Luchini wrote:
>A friend and a colleague of mine would need a working file alteration
>monitor on Windows.
>It seems that gamin[1] compiles fairly well with only a few patches.
>Being it part of Gnome I was wondering if (and why) it wasn't already
>packaged by the cygwin-gnome project, else we could think about
>proposing to mantain the package (as we would need to produce it anyway,
>in order to easily install it).
>Any comment? Do you think it would be a generally useful package?

This really works on cygwin?  I would have thought that there were operating
system hooks needed.  Or does it just poll files?

cgf

[maybe-ITP] gamin

[Lapo Luchini]

A friend and a colleague of mine would need a working file alteration
monitor on Windows.
It seems that gamin[1] compiles fairly well with only a few patches.
Being it part of Gnome I was wondering if (and why) it wasn't already
packaged by the cygwin-gnome project, else we could think about
proposing to mantain the package (as we would need to produce it anyway,
in order to easily install it).
Any comment? Do you think it would be a generally useful package?

Links:
1. http://www.gnome.org/~veillard/gamin/