2013/6/19 Corinna Vinschen <vinsc...@redhat.com>
> On Jun 19 14:11, Ruben Van Boxem wrote:
> > 2013/6/19 LRN <lrn1...@gmail.com>
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > On 19.06.2013 15:54, Ruben Van Boxem wrote:
> > > > 2013/6/19 Corinna Vinschen <vinsc...@redhat.com>
> > > >
> > > >> 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?
>
> The POSIX calls are stateless. When the target of a symlink gets
> created, you don't even know if a symlink to the target has been created
> at all, let alone by the same process.
>
> > You can keep track as the symlink info is contained in the information
> > retrieved by GetFileAttributesEx.
>
> Not really. With GetFileAttributesEx you only get the fact if a file is
> a reparse point or not. If it's a symlink requires further checking.
> Even with the underlying native NtQueryInformationFile you can get all
> the hardlinks pointing to the same file (same file ID), but not all
> symlinks pointing to a file.
>
> > This setup might require bookkeeping though, not entirely well-versed in
> > this stuff.
>
> This kind of bookkeeping opens a can of worms. In theory you'd have to
> maintain a shared memory region of potentially indefinite size to keep
> track of dangling symlinks in calls to symlink(2). To utilize this
> shared mem region, *all* Cygwin processes calling open(2) or mkdir(2)
> would have to check if the path to the new file or directory is in the
> shared list of dangling symlinks and, if so, call a helper function
> which recreates the symlink with the correct type and remove the
> dangling symlink from the list.
>
> One problem here is the fact, that the shared memory region is only
> maintained as long as at least one Cygwin process is still running since
> shared mem regions disappear when the last handle to them is closed. If
> you start Cygwin tools from CMD like this
>
> C:\> C:\cygwin\bin\ln -s foo bar
> C:\> C:\cygwin\bin\mkdir bar
>
> then there's no Cygwin process running between the lifetime of ln and
> mkdir. So the shared mem region doesn't exist anymore when mkdir is
> called and the whole excerise is moot.
>
> And there's another problem with this approach. Unfortunately you can't
> overwrite symlinks atomically. You have to remove the old symlink and
> create a new one. In the time between removing and recreation, another
> process could have made a wrong decision based on the non-existence of
> the symlink. You could eliminate this problem by deleting and
> recreating the symlink in an NTFS transaction, but very, very
> unfortunately Microsoft has announced to drop NTFS transactions from
> future versions of NTFS(*).
>
Thanks for all the details. The interop between Windows and POSIX APIs has
always interested me somewhere deep down, and I too found Cygwin coming
short (no offense, I'm sure it was my fault and I wasn't patient enough or
had some wrong assumption).
An "alternative" to TxF is doing that in Kernel mode directly of course:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff565748%28v=vs.85%29.aspx
But that would mean a highly skilled developer would need to write a POSIX
kernel driver (or better: subsystem), and we'd have Interix all over again,
which is still an awesome thing, which failed due to its limited and
closed-source nature.
I'd very much welcome a usable Interix2. I think (and this is an uneducated
guess) that the newer Windows APIs (wrt threads) and newer OSes can provide
much improvement where the original Interix failed (I/O speed, threads,
...). And it might be able to work around some Win32 deficiencies for which
Cygwin needs to live with a compromise.
One can dream.
Ruben
>
> Corinna
>
>
> (*) This a an extrem pity, because transactions are necessary in some
> scenarios to overcome non-POSIXy behaviour of some system calls.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> 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
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
