[maybe-ITP] gamin

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[maybe-ITP] gamin

Lapo Luchini-2
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/
Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Christopher Faylor-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Yaakov (Cygwin/X)
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
Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Christopher Faylor-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Lapo Luchini-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Lapo Luchini
In reply to this post by Christopher Faylor-2
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

Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Lapo Luchini
In reply to this post by Yaakov (Cygwin/X)
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?
Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Yaakov (Cygwin/X)
-----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-----
Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Yaakov (Cygwin/X)
-----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-----
Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Corinna Vinschen-2
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
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Lapo Luchini
In reply to this post by Yaakov (Cygwin/X)
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Yaakov (Cygwin/X)
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
Reply | Threaded
Open this post in threaded view
|

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/
      |\      _,,,---,,_    [hidden email] | [hidden email]
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"
Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Christopher Faylor-2
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
Reply | Threaded
Open this post in threaded view
|

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/
      |\      _,,,---,,_    [hidden email] | [hidden email]
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"
Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Yaakov (Cygwin/X)
In reply to this post by Christopher Faylor-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Yaakov (Cygwin/X)
In reply to this post by Igor Peshansky
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
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: [maybe-ITP] gamin

Yaakov (Cygwin/X)
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
12