Re: open item: tablespace handing in pg_dump/pg_restore

Bruce Momjian schrieb:
> Greg Stark wrote:
>>Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>>>OK, I have applied the following patch that uses Cygwin native symlink()
>>>instead of the Win32 junctions. The reason for this is that Cygwin
>>>symlinks work on Win95/98/ME where junction points do not
>>
>>Is this really a Win95/98/ME vs NT distinction or a FAT32 vs NTFS distinction?
>>In which case does an NT machine that happens to be using a FAT32 file system
>>have the same problem?
>
> I believe it is OS, not file system.

Both:
On Win95 family systems you cannot do junctions at all.
(must use cygwin instead)

Up to NT4 and NTFS4 you can junction across the same harddrive.
With FAT, FAT32, VFAT not. ("convert")
(directory mount points)

Since W2k and NTFS5 you can junction across all local volumes.
With W2k and NTFS4 or FAT32 not. ("convert")
(volume mount points. implemented by NTFS5 "reparse points")
This also works with the new EFS (encrypted filesystem).
Don't know how the new WinFS will handle that, but it should
not break it.

I'm not sure about network drives though.
Reparse points don't seem to support network drives. (for now).
They do work with simple cygwin symlinks. But Samba and novell shares
will need some security tweaks. Esp. when run as service.

>>Is there a reason to make this a compile-time decision? Can't it just try to
>>make a junction and if it fails then use the Cygwin symlink?
>
> Yes, if we feel like probing for the Windows OS during runtime. I don't
> think it is worth it.

Agreed. Speed is not a matter for cygwin.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/