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(*).
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
