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