Re: [maybe-ITP] gamin

[Lapo Luchini <lapo at lapo dot it>]

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