Mail Archives: cygwin/2010/01/07/07:42:20
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
- Raw text -