-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19.06.2013 16:11, Ruben Van Boxem wrote: > 2013/6/19 LRN <[email protected]> > > 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
I was thinking along the same lines some minute ago. Sadly, that isn't really an option for me, since i need this to work for W32 apps, and they don't have access that bookkeeping code. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRwaItAAoJEOs4Jb6SI2CwycAIAOCBYUCPLcKnD2ZW3tLfRlFQ 0wV84vBcFtkKuhY++zmdKQXKEWjxfXyerkgU9N92GvGR8lyVNaLF/uvV5IoMhcJR er9oG+L0UAIYTvxveAcbRhiODii21Jsahw3LK+hIjc3+IBBCfGTbMGNbnOVuRm5u bpUMWzF/vcTAyT0oh8vixWURAGzg63bDE8X2kKoHVbp4akzLRvdlJ17MmL+y+zQi LNBjpS1B4B1IzUFPXpC/ipi2SU+Avv8srGFWogufG3HrVqiuyH2oaPICZCktl23j XfJ7nvVTrzc0P0/9MoKk4lojdGm6NXMzOxcC59IRNJunt2/kG+eQdH01NKc8pmg= =GwQF -----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
