On Jan 1 15:56, Linda Walsh wrote: > Some time ago, my daily updatedb stopped working and I just got > around to figuring out why -- it was dying with (I wish I had the > message, > but I lost it) an internal error in 'find' which would then exit and > updatedb would overwrite the old file with a new empty file. > > But the place where it died was where, in the root dir, I had a symlinkD > pointing to a no-longer existing drive. > > Used to have a network drive L:, in order for updatedb to index it > (reliably), I created a windows symlink to it in root: "l <==> L:". > Later the network drive > was no longer needed at L and was removed, but the symlink was left behind. > > find really didn't like that dangling symlink. Removed it (using windows, as > cygwin doesn't seem able to remove symlinkD's). I think that thought > cygwin understands windows symlinks as symlinks, it doesn't 'grok' the > 'symlinkD' > type links to directories (that explorer 'needs' to see them as a directory).
I can't reproduce any of this. Cygwin understands NTFS6 symlinks, no matter if the FILE_ATTRIBUTE_DIRECTORY flag is set, as well as NTFS5 directory junctions and volume mount points. Only volume mount points are not treated as symlinks. I tried to reproduce a find crash on a dangling NTFS6 symlink and a dangling NTFS5 directory junction, to no avail. > I'm not sure, but I think symlinkD's are real directories with a file in them > that points to the target. Nope. All of the aforementioned Windows objects are reparse points. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
