Finding junction points in cygwin

[aputerguy]

Does cygwin have any ability to find/identify NTFS junction points?
This would be useful so that you don't inadvertently mistreat them thinking
they are regular files or directories.

Also, is there any native cygwin utilities with functionality similar to
junction.exe allowing you to make or delete junction points? (I know that
cygwin doesn't like them too much philosophically and they seem to be on
their way out anyway but...)

[Andy Koppe]

Post by aputerguy
Does cygwin have any ability to find/identify NTFS junction points?
This would be useful so that you don't inadvertently mistreat them thinking
they are regular files or directories.

They appear as symbolic links. Dunno how to tell them from other sorts
of shortcuts.

Post by aputerguy
Also, is there any native cygwin utilities with functionality similar to
junction.exe allowing you to make or delete junction points?

No. Use junction.exe, or linkd.exe from the Windows resource kit tools.

Andy

[Corinna Vinschen]

Post by Andy Koppe

Post by aputerguy
Does cygwin have any ability to find/identify NTFS junction points?
This would be useful so that you don't inadvertently mistreat them thinking
they are regular files or directories.

They appear as symbolic links. Dunno how to tell them from other sorts
of shortcuts.

Not quite. Directory junctions appear as symlinks. Volume junctions
are treated as simple directories since they are for all practically
purposes the same as Unix mount points.


Corinna

[aputerguy]

Corinna Vinschen writes

Post by Corinna Vinschen
Not quite. Directory junctions appear as symlinks. Volume junctions
are treated as simple directories since they are for all practically
purposes the same as Unix mount points.

But I still see several issues at least with directory junctions.
1. When I use junction.exe to make a junction with a regular file, the
junction shows up as a regular file under cygwin. When I make a junction to
a directory, the junction shows up as a directory. In particular, I don't
see symlinks in either case.

2. Shouldn't we have a way of identify and/or differentiating junctions from
their targets. For example, cygwin (appropriately) doesn't allow you to
remove junctions using 'rm' (either files or directories). But if I am
writing code to manipulate files, I would like to be able to identify
junctions pro-actively rather than retroactively by the fact that I can't
remove them.

3. Moving a junction, moves the target file. And leaves the junction itself
'unlinked'. I'm not sure this is the logical behavior expected, particularly
if it is supposed to act like a symlink. Because with symlinks, 'mv' moves
the link not the target.

[aputerguy]

Actually the behavior is even stranger... renaming and then deleting
junctions creates spurious directories.

echo "This is a test file" >| targetfile
mkdir targetdir
echo "This is a test dir file" >| targetdir/targetdirfile

junction.exe junctionfile targetfile
junction.exe junctiondir targetdir

ls -Ag
drwxr-xr-x 1 None 0 2009-11-09 11:56 junctiondir/
-rw-r--r-- 1 None 20 2009-11-09 11:55 junctionfile
drwxr-xr-x 1 None 0 2009-11-09 11:56 targetdir/
-rw-r--r-- 1 None 20 2009-11-09 11:55 targetfile

mv junctionfile newjunctionfile
mv junctiondir newjunctiondir

ls -Ag
drwxr-xr-x 1 ???????? 0 2009-11-09 11:57 junctiondir/
drwxr-xr-x 1 ???????? 0 2009-11-09 11:57 junctionfile/
drwxr-xr-x 1 None 0 2009-11-09 11:56 newjunctiondir/
-rw-r--r-- 1 None 20 2009-11-09 11:55 newjunctionfile

junction.exe -d junctionfile
junction.exe -d junctiondir

ls -Ag
drwxr-xr-x 1 None 0 2009-11-09 11:56 newjunctiondir/
-rw-r--r-- 1 None 20 2009-11-09 11:55 newjunctionfile
drwx------+ 1 None 0 2009-11-09 12:01 targetdir/
drwx------+ 1 None 0 2009-11-09 12:01 targetfile/

Now this seems to be sheer madness.
The original file and directory names have reappeared!
However 'targetdir' is now empty and 'targetfile' is also an (empty)
directory!


ls -Ag targetdir targetfile newjunctiondir
newjunctiondir:
total 1
-rw-r--r-- 1 None 24 2009-11-09 11:56 targetdirfile

targetdir:
total 0

Interestingly, in Windows explorer, renaming seems to do the right thing -
it renames the target.

Interestingly, Windows explorer allows both file and directory junctions to
be removed (though it displays file junctions as non-openable directories).
Not sure why it does this since I thought junctions could only be deleted
using '-d'.

So it seems to me, we have the following conclusions:
- cygwin treatment of junctions is not consistent with Windows or with
notion of symlinks. It also leaves weird residua after renaming junctions.
- Windows junctions are also messed up but not as much




targetfile:
total 0

[Corinna Vinschen]

Post by aputerguy
Actually the behavior is even stranger... renaming and then deleting
junctions creates spurious directories.
echo "This is a test file" >| targetfile
mkdir targetdir
echo "This is a test dir file" >| targetdir/targetdirfile
junction.exe junctionfile targetfile
junction.exe junctiondir targetdir
ls -Ag
drwxr-xr-x 1 None 0 2009-11-09 11:56 junctiondir/
-rw-r--r-- 1 None 20 2009-11-09 11:55 junctionfile
drwxr-xr-x 1 None 0 2009-11-09 11:56 targetdir/
-rw-r--r-- 1 None 20 2009-11-09 11:55 targetfile
mv junctionfile newjunctionfile
mv junctiondir newjunctiondir
ls -Ag
drwxr-xr-x 1 ???????? 0 2009-11-09 11:57 junctiondir/
drwxr-xr-x 1 ???????? 0 2009-11-09 11:57 junctionfile/
drwxr-xr-x 1 None 0 2009-11-09 11:56 newjunctiondir/
-rw-r--r-- 1 None 20 2009-11-09 11:55 newjunctionfile
junction.exe -d junctionfile
junction.exe -d junctiondir
ls -Ag
drwxr-xr-x 1 None 0 2009-11-09 11:56 newjunctiondir/
-rw-r--r-- 1 None 20 2009-11-09 11:55 newjunctionfile
drwx------+ 1 None 0 2009-11-09 12:01 targetdir/
drwx------+ 1 None 0 2009-11-09 12:01 targetfile/
Now this seems to be sheer madness.

Indeed, and I can't reproduce this, neither in Cygwin 1.5.25, nor in
Cygwin 1.7. The only difference between your and my run is that I'm
using the cmd mklink builtin rather than the junction tool, like this:

$ cmd /c mklink /j junctionfile targetfile
Junction created for junctionfile <<===>> targetfile
$ cmd /c mklink /j junctiondir targetdir
Junction created for junctiondir <<===>> targetdir

BLODA?


Corinna

[aputerguy]

Corinna Vinschen writes...

Post by Corinna Vinschen
Indeed, and I can't reproduce this, neither in Cygwin 1.5.25, nor in
Cygwin 1.7. The only difference between your and my run is that I'm
BLODA?

I don't know... I don't have a lot of BLODA on my machine...

I found the problem once and then I reproduced it in order to cut & paste
the problem to the list.
But when I just tried to reproduce it again, I couldn't. So let's ignore
that problem for now or maybe it is related to whatever weirdness is causing
my Cygwin 1.7 not to recognize junctions as symlinks.

Any suggestions on how to troubleshoot why I'm not seeing the symlinks?

And just to confirm, 'find' also recognizes the junctions as files and
directories - not as symlinks.

[Corinna Vinschen]

Post by aputerguy
Corinna Vinschen writes

Post by Corinna Vinschen
Not quite. Directory junctions appear as symlinks. Volume junctions
are treated as simple directories since they are for all practically
purposes the same as Unix mount points.

But I still see several issues at least with directory junctions.
1. When I use junction.exe to make a junction with a regular file, the
junction shows up as a regular file under cygwin. When I make a junction to
a directory, the junction shows up as a directory. In particular, I don't
see symlinks in either case.

Are you running Cygwin 1.5.25? If so, yes, Cygwin 1.5.25 doesn't know
anything about junctions or native symlinks. It only sees what is
visible through the Win32 API.

Btw., while directory junctions can point to files, they are always
treated as directories by the Win32 API. There's no way to access the
target file of such a directory junction from non-Cygwin applications
like Windows Explorer or CMD. It's not really supported to do so, and
it's kind of schizophrenic that the CMD builtin command mklink allows
to create such directory junctions pointing to files.

Post by aputerguy
2. Shouldn't we have a way of identify and/or differentiating junctions from
their targets. For example, cygwin (appropriately) doesn't allow you to
remove junctions using 'rm' (either files or directories). But if I am
writing code to manipulate files, I would like to be able to identify
junctions pro-actively rather than retroactively by the fact that I can't
remove them.

Try Cygwin 1.7. It recognizes directory junctions as symlinks.

Post by aputerguy
3. Moving a junction, moves the target file. And leaves the junction itself
'unlinked'. I'm not sure this is the logical behavior expected, particularly
if it is supposed to act like a symlink. Because with symlinks, 'mv' moves
the link not the target.

Try Cygwin 1.7. It recognizes directory junctions as symlinks.


Corinna

[aputerguy]

Corinna writes..

Post by Corinna Vinschen
Try Cygwin 1.7. It recognizes directory junctions as symlinks.

$ uname -r
1.7.0(0.214/5/3)

But don't see any symlinks...

[Corinna Vinschen]

Post by aputerguy
Corinna writes..

Post by Corinna Vinschen
Try Cygwin 1.7. It recognizes directory junctions as symlinks.

$ uname -r
1.7.0(0.214/5/3)
But don't see any symlinks...

Uh, I see. Don't use the junction tool, use cmd's mklink instead.
junction.exe creates directory symlinks which can't be easily recognized
as directory junctions, at least not using the default technique.

I'll look into supporting these weird junctions as well.


Corinna

[Andy Koppe]

Post by aputerguy
But don't see any symlinks..

Uh, I see.  Don't use the junction tool, use cmd's mklink instead.

Was mklink introduced with Vista? It's not present on XP. The
alternative there is linkd.exe, available as part of the freely
downloadable Windows Server 2003 Resource Kit Tools.

I checked again that Cygwin recognizes links created by linkd.exe as
symlinks. Sorry for not trying junction.exe before posting.

Andy

[Corinna Vinschen]

Post by Andy Koppe

Post by aputerguy
But don't see any symlinks..

Uh, I see.  Don't use the junction tool, use cmd's mklink instead.

Was mklink introduced with Vista? It's not present on XP. The

Yes, it has been added to cmd in Vista. Unfortunately it's a
builtin, not a stand-alone tool.


Corinna

[aputerguy]

Post by Corinna Vinschen
Uh, I see. Don't use the junction tool, use cmd's mklink instead.
junction.exe creates directory symlinks which can't be easily recognized
as directory junctions, at least not using the default technique.
I'll look into supporting these weird junctions as well.

Thanks. Something should be done here I think because otherwise you can
really unwittingly create a mess if someone else has created junctions and
you start renaming and moving files around. The behavior seems to be
unexpected and potentially destructive. Better to not allow any
(destructive) cygwin operations on such files than to have such unnatural
behavior.

I will look into getting mklink for XP in the meantime.

[aputerguy]

I have been googling on junction.exe and mklink.
Since they both create reparse points, in what way are the reparse points
different to the extent that cygwin recognizes those from mklink but not
those form junction.exe.

The nice thing though about junction.exe is that it uses the *nix like '-d'
flag rather than the dos-like '/D' flag that mklink seems to use.

[Corinna Vinschen]

Post by aputerguy
The nice thing though about junction.exe is that it uses the *nix like '-d'
flag rather than the dos-like '/D' flag that mklink seems to use.

mklink /d creates a symlink with a directory DOS attribute, it does
not delete the symlink.


Corinna

[aputerguy]

Post by Corinna Vinschen

Post by aputerguy
The nice thing though about junction.exe is that it uses the *nix like '-d'
flag rather than the dos-like '/D' flag that mklink seems to use.

mklink /d creates a symlink with a directory DOS attribute, it does
not delete the symlink.

I'm sorry I meant linkd.exe.
It uses the '/D' flag to delete rather than *nix-like '-d'

[aputerguy]

More generally, could someone point me to a single source that can accurately
compare and contrast the following notions of "links" in cygwin/windoze:

1. Hard links (ln)
2. Soft links (ln -s)
- Old style
- New style
3. Windows shortcuts
4. Junctions created by junction.exe
5. Reparse points created by linkd.exe
6. Other types of reparse points?
5. Mount points created by cygwin mount
6. Mount points created by mountvol
7. Letter drives created by dosdev
8. Letter drives created using Administrative Tools computer management
9. Other types of mounting?

I know that some of the above only work on files, some only on directories,
some only on shares, etc.
but there is a lot of overlap and a nice table would be very helpful.

Personally, I'm sure I don't understand all the differences, subtleties,
limitations, and when to use which one. I'm also left with the feeling that
Microsoft just keeps throwing new flavors of links and mounts rather than
going with a consistent approach but maybe I'm just biased to *nix.

[aputerguy]

And also add to the below list:
10. mklink
--------------------------
More generally, could someone point me to a single source that can
accurately compare and contrast the following notions of "links" in
cygwin/windoze:

1. Hard links (ln)
2. Soft links (ln -s)
- Old style
- New style
3. Windows shortcuts
4. Junctions created by junction.exe
5. Reparse points created by linkd.exe
6. Other types of reparse points?
5. Mount points created by cygwin mount
6. Mount points created by mountvol
7. Letter drives created by dosdev
8. Letter drives created using Administrative Tools computer management
9. Other types of mounting?

I know that some of the above only work on files, some only on directories,
some only on shares, etc.
but there is a lot of overlap and a nice table would be very helpful.

Personally, I'm sure I don't understand all the differences, subtleties,
limitations, and when to use which one. I'm also left with the feeling that
Microsoft just keeps throwing new flavors of links and mounts rather than
going with a consistent approach but maybe I'm just biased to *nix.

[DePriest, Jason R.]

Post by aputerguy
More generally, could someone point me to a single source that can accurately
1. Hard links (ln)
2. Soft links (ln -s)
   - Old style
   - New style
3. Windows shortcuts
4. Junctions created by junction.exe
5. Reparse points created by linkd.exe
6. Other types of reparse points?
5. Mount points created by cygwin mount
6. Mount points created by mountvol
7. Letter drives created by dosdev
8. Letter drives created using Administrative Tools computer management
9. Other types of mounting?
I know that some of the above only work on files, some only on directories,
some only on shares, etc.
but there is a lot of overlap and a nice table would be very helpful.
Personally, I'm sure I don't understand all the differences, subtleties,
limitations, and when to use which one. I'm also left with the feeling that
Microsoft just keeps throwing new flavors of links and mounts rather than
going with a consistent approach but maybe I'm just biased to *nix.

There is also the 'subst' command that lets you create a directory and
point it to a drive.

C:\>subst /?
Associates a path with a drive letter.

SUBST [drive1: [drive2:]path]
SUBST drive1: /D

drive1: Specifies a virtual drive to which you want to assign a path.
[drive2:]path Specifies a physical drive and path you want to assign to
a virtual drive.
/D Deletes a substituted (virtual) drive.

Type SUBST with no parameters to display a list of current virtual drives.

[aputerguy]

Post by DePriest, Jason R.
There is also the 'subst' command that lets you create a directory and
point it to a drive.

OK - now I am truly tearing out my hair as 'subst' makes #11.

I'm thinking a table with the following columns would be very helpful:
A. Name of command
B. Source (e.g., Cygwin 1.x+, Windows ver X-Y, etc.)
C. Targets (e.g., files, directories, volumes)
D. Type of link/junction/mount point
E. *nix analogy and compatibility (including whether exact or similar)
F. Advantages relative to analogous concepts
G. Limitations, gotchas, etc.
H. How (or even if) handled by cygwin

[Christopher Faylor]

Post by aputerguy

Post by DePriest, Jason R.
There is also the 'subst' command that lets you create a directory and
point it to a drive.

OK - now I am truly tearing out my hair as 'subst' makes #11.
A. Name of command
B. Source (e.g., Cygwin 1.x+, Windows ver X-Y, etc.)
C. Targets (e.g., files, directories, volumes)
D. Type of link/junction/mount point
E. *nix analogy and compatibility (including whether exact or similar)
F. Advantages relative to analogous concepts
G. Limitations, gotchas, etc.
H. How (or even if) handled by cygwin

It's not clear whom you are expecting to prepare this comprehensive
list. For Cygwin we clearly want you to use our symlinks. It's a
bonus that Corinna has implemented any functionality for anything
else at all.

cgf

[aputerguy]

Christopher Faylor writes

Post by Christopher Faylor
It's not clear whom you are expecting to prepare this comprehensive
list. For Cygwin we clearly want you to use our symlinks. It's a
bonus that Corinna has implemented any functionality for anything
else at all.

No real expectations and not a complaint about cygwin. Just more of a
frustration of trying to merge the *nix and Windows worlds.

My problem is not within cygwin itself -- it's with trying to use cygwin to
also do Windoze-related tasks. In particular, I am trying to extend a
*nix-focused rsync-based program to do a better job of backing up Windoze
systems by capturing as much of the ntfs structure as possible. So, I am
trying to understand ACLs, reparse points, the MFT, etc.

Cygwin is of course awesome...

[Christopher Faylor]

Post by aputerguy
Christopher Faylor writes

Post by Christopher Faylor
It's not clear whom you are expecting to prepare this comprehensive
list. For Cygwin we clearly want you to use our symlinks. It's a
bonus that Corinna has implemented any functionality for anything
else at all.

No real expectations and not a complaint about cygwin. Just more of a
frustration of trying to merge the *nix and Windows worlds.
My problem is not within cygwin itself -- it's with trying to use cygwin to
also do Windoze-related tasks. In particular, I am trying to extend a
*nix-focused rsync-based program to do a better job of backing up Windoze
systems by capturing as much of the ntfs structure as possible. So, I am
trying to understand ACLs, reparse points, the MFT, etc.
Cygwin is of course awesome...

Well, thanks, but I think you're missing a big part of Cygwin if you
think that you need someone else to compile a table for you. If this
really is something useful then you could always go down in history by
doing the research (reading source code?) and contributing the table
yourself.

cgf

[Corinna Vinschen]

Post by aputerguy
I will look into getting mklink for XP in the meantime.

There's no mklink for XP. It's a cmd builtin in Vista and later.


Corinna

[Corinna Vinschen]

Post by Corinna Vinschen

Post by aputerguy
Corinna writes..

Post by Corinna Vinschen
Try Cygwin 1.7. It recognizes directory junctions as symlinks.

$ uname -r
1.7.0(0.214/5/3)
But don't see any symlinks...

Uh, I see. Don't use the junction tool, use cmd's mklink instead.
junction.exe creates directory symlinks which can't be easily recognized
as directory junctions, at least not using the default technique.
I'll look into supporting these weird junctions as well.

Not quite as weird. The test got actually simpler now. I also set the
return code of rename(2) to EBUSY when you try to rename a volume
junction. Otherwise Windows returns an error code equivalent to EXDEV
and mv(1) starts to move the directory over by copying its entire
content (cross-device mv).


HTH,
Corinna