Actually, since 2006 Windows does have a notion of symbolic links. It also has junctions (reparse points), which have been available since Win2k. While junctions only work for directories, symbolic links work for files or directories, including remote volumes and UNC paths. There are plenty of Windows tools to find and deal with junctions and symbolic links. CMD.exe will list them as well (well, at least it lists junctions).
Here are some discussions on symbolic links and junction points in Windows:
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, October 02, 2012 11:51
To: Midrange Systems Technical Discussion
Subject: Re: QOpenSys and the symbolic link issue
WRKSYSSTS should be smart enough to understand symlinks. It shouldn't be misreporting the disk space... If it is, I would report that as a bug to IBM, and they should fix it.
However, Windows tools are another matter. On IBM i or Unix systems, tools can easily tell whether a disk object is a symlink or an actual object. But, this is not true of Windows, which has no notion of symbolic links.
So... I wouldn't recommend using Windows tools for disk analysis on IBM i.
On 10/2/2012 1:31 PM, Matt Olson wrote:
I have been investigating the issue of QOpenSys issue as described here: http://www.itjungle.com/fhg/fhg062409-story03.html and the original article here: http://www.itjungle.com/fhg/fhg041509-story03.html and it appears to cause misreporting of the available free disk space when you run wrksyssts by precisely 15 times the amount of data in /QOpenSys due to the recursive symbolic link.
Has anyone else experienced this?
When running windows based tools against the IFS this also causes problems because it traverses every symbolic link upto the maximum depth (15) and you end up getting very inflated disk usage numbers. In our case 88GB of disk usage that isn't actually being used.