Can't read lock file
Thu Nov 12 18:16:00 GMT 2009
On 11/11/2009 10:07, Corinna Vinschen wrote:
> On Nov 11 07:40, Fergus wrote:
>> Q1. Is it still the case that this problem is "not well understood"
>> as in this reference?
> Hardlinks don't work on FAT filesystems since FAT doesn't support them.
> Up to Cygwin 1.7.0-60, hardlinks on FAT were faked by copying the file.
> This has obvious downsides (unsecure, potential denial-of-service
> problems, portability), so we discussed and decided to remove this fake
> and to return an error instead when trying to create a hardlink on a FAT
> FS: http://cygwin.com/ml/cygwin/2009-09/msg00208.html
>> (My experiments with possible cause/ cure are confounded because on
>> Machine 1 I have NTFS filesystems but lack administrator rights and
>> on Machine 2 where I am Administrator, all filesystems are FAT32.)
> Which is bad since FAT32 has no security at all. Any process of any
> user on the machine can overwrite any file, even in the Windows folder.
> NTFS is much more secure and has a couple of features you never get with
> FAT32, and hardlinks are only one minor advantage. You should really
> update the filesystem to NTFS using the on-board convert.exe tool.
> As for X, it should have a fallback method if the /tmp filesystem
> doesn't support hardlinks.
Well, the fallback method is to use -nolock :-)
The only use of the lock file appears to be to stop people from doing things
like starting 'X :0 -nolisten inet -nolisten inet6' and 'X :0 -nolisten unix'
at the same time, so I'm kind of tempted just to make '-nolock' the default
and let people run with scissors if they want to :-)
However, since there does seem to be some code to grovel over the mount
options to try to detect if /tmp is textmode and warn about that for some
reason, perhaps I'll look at checking if it's FAT and turning off the lockfile
automatically in that case.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
More information about the Cygwin-xfree