2013/6/19 LRN <[email protected]>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 19.06.2013 15:54, Ruben Van Boxem wrote:
> > 2013/6/19 Corinna Vinschen <[email protected]>
> >
> >> On Jun 19 12:34, Corinna Vinschen wrote:
> >>> On Jun 19 14:28, LRN wrote:
> >>>> [...]
> >>>> and that you're using winsymlinks:nativestrict?
> >>>
> >>> No. I'm using any one of the other variations of symlinks.
> nativestrict
> >>> was a compromise with my fellow co-maintainer. The default symlinks
> >>> and winsymlinks:lnk always work, winsymlinks:native falls back to the
> >>> default symlinks if creating the native symlink doesn't work.
> >>>
> >>> winsymlinks:nativestrict is a special case, not the norm.
> >>
> >> As a sidenote:
> >>
> >> What's really sad is the fact that a native symlink contains the
> >> information if the target is a file or directory, and worse, that
> >> non-Cygwin tools fail if the file/directory information in the symlink
> >> is wrong. That alone disallows to create native symlinks to
> non-existing
> >> targets, since you never know whether the target will be file or dir.
> >> I'm totally baffled how a simple functionality like creating symlinks
> >> can be so screwed up, with no hope in sight.
> >>
> >
> > I'm sorry, but all documentation I can find about NTFS reparse points and
> > softlinks etc. say explicitely that you can create a softlink to a
> > nonexistent file:
> > http://msdn.microsoft.com/en-us/library/aa365460%28VS.85%29.aspx
> >
> > So either something is XP specific and not clearly showing on MSDN, or
> I'm
> > misunderstanding the problem.
> A file link to non-existing file - yes (mklink).
> A directory link to non-existing directory - yes (mklink /D).
> An untyped link to non-existing filesystem object - no, because NTFS
> doesn't support untyped symlinks.
> Cygwin emulates untyped linking (ln -s) by checking the type of the
> target and creating the link of the right type. If the target doesn't
> exist, you're screwed.
>
Call me naive, but why not create the link to non-existent ... thing (which
should possible, just choose file or directory; it doesn't matter because
its not there)... then when the actual thing is created, change the link to
conform to the new filesystem state?
You can keep track as the symlink info is contained in the information
retrieved by GetFileAttributesEx.
This setup might require bookkeeping though, not entirely well-versed in
this stuff.
Ruben
>
> - --
> O< ascii ribbon - stop html email! - www.asciiribbon.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (MingW32)
>
> iQEcBAEBAgAGBQJRwZ2TAAoJEOs4Jb6SI2Cw0wkH/RKnvQvxdw+CPt0Fxc5RXhFj
> ENOLaPOAvroTSPHaQPLozmjE/6pyqluQE48Z0qRpB2/hIEu/a1NbulZ3hfMXo9ke
> 6o+W7vEzqyRup/hxa97rETp7ThryTlaRr4/qbZ4PaccXAiEVge4SuOowQ454RgLj
> 4CdMsr5L/n4T2Bh8M6hkvy6O9a4yNUB4QNsDIgDpP5MPXMa3azYLCeId5OgaKwpZ
> ZQUSHEAcxp8K5db+wU8RBJDe3zJ0YdQwWasbGY3BLVCDqevWRXn6yRAbmeGbPO4Y
> /1ZL6wOq0v9BR8TLk99ZTex0LiOGXrWiHXAE9P8Q+KQ+zFwBJd7k9MEr5YIsURY=
> =NNHe
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Mingw-w64-public mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
