Re: [GENERAL] pg_upgrade --link on Windows

On 06/09/2017 07:39 AM, Arnaud L. wrote:
> Le 9/06/2017 à 16:07, Bruce Momjian a écrit :
>> I was told junction points on Windows were hard links and no one has
>> ever complained about not being able to remove them.
>
> Sorry, I think my explanation was not very clear.
> You can remove the link, but the point is to remove the target (i.e. the
> old-data-dir).
> You can do this with a hard link (there still exists a hardlink pointing
> to the inode so it remains), but with a soft link you end up with a link
> to nothing.
> Deleting a junction target in Windows will work, but you'll have an
> error trying to access the junction directory (directory not found).
>
> See this page for more details :
> http://cects.com/overview-to-understanding-hard-links-junction-points-and-symbolic-links-in-windows/
>
>
> Under "Hard Link (Linking for individual files)" :
> "If the target is deleted, its content is still available through the
> hard link"
>
> Junction Point (Directory Hard Link):
> "If the target is moved, renamed or deleted, the Junction Point still
> exists, but points to a non-existing directory"
>
> BUT, when I try to "pg_upgrade --link --check" with old-data-dir and
> new-data-dir on different volumes, I get an error saying that both
> directories must be on the same volume if --link is used.
> So maybe pg_upgrade uses hard-links (i.e. to files), and only the
> documentation is wrong by calling them junctions (i.e. soft links to
> files) ?

Looks that way. In file.c in ~/src/bin/pg_upgrade I see:

#ifdef WIN32
  300 /* implementation of pg_link_file() on Windows */
  301 static int
  302 win32_pghardlink(const char *src, const char *dst)
  303 {
  304     /*
  305      * CreateHardLinkA returns zero for failure
  306      * http://msdn.microsoft.com/en-us/library/aa363860(VS.85).aspx
  307      */
  308     if (CreateHardLinkA(dst, src, NULL) == 0)
  309     {
  310         _dosmaperr(GetLastError());
  311         return -1;
  312     }
  313     else
  314         return 0;
  315 }
  316 #endif


>
> Regards
> --
> Arnaud
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com