Strange paths in NTFS reparse points created by Cygwin Setup for e.g. TTF fonts

[L A Walsh]

On 2020/11/08 06:40, Michael Soegtrop wrote:
> What I don't understand is why it does work sometimes and sometimes not. 
> I always use the same scripts to install and remove cygwin on the same 
> machines and then do pretty much the same thing with this cygwin (build 
> our open source software) before I delete it.
----
	Likely because the windows settings are different on the
various machines -- especially the various policies.

	But, first, basic, you know that windows symlinks are
turned off for normal users by default when they first get it (i.e. they
can't create them).  Which ways work and who can create them are settings
under fsultil/behavior/(set/query) symlinkEvaluation.  These 4 settings
control directions of symlinking

	There's another setting that is suppose to control where fonts
can be installed, but can't find it off hand -- in the group policy 
editor.  If I remember, it was suppose to allow/disallow fonts being
installed in folders other than /windows/fonts.  I think the default
might be to allow, but am not sure.  I thought I disabled it, and what
I've seen is the same font-file hardlinked between windows/fonts
and the application path.  


> It is unlikely that the issue is that the target files are open as L A 
> Welsh suggested because always either all symlinks or none at all 
> remain. The number is always the same (with recent versions afair 258).
----
	Windows doesn't hold open all fonts -- but some subset -- they
have some font cache services that may be running at times to support
some apps.  So could be if one of those apps has run, it started its
font caching service, which could lock it.  Each font system has a
set of "core fonts" that it will load whether they are called upon
or not -- that could create a toggle situation between a bunch being
used or not.

	Some applications (though I don't think rm does this) will
follow the symlink by default, so when they try to delete a file,
it doesn't delete the symlink but tries to delete the font, which
may be opened by some service.  

	BTW, are you familiar with 'Process Hacker' (google it, its
open source, and hasn't been changed for a while).  It can replace
the task manager and ProcessExplorer that MS helps distribute.
It's more powerful than either.  But specifically if you can't delete
a file, you can find out what process(es) have the file open.

	Finding that out might enable you to find the what apps
might be running and holding those files open.  Symlinks and
their older counterparts mountd+junction have different formats
for directories and volumes.  Some will work with network, some not.

	If they are all Microsoft windows symlinks, you might
look at the fsutil settings -- as well as open files.

	You maybe said, but don't remember -- is there any error
message when you can't delete those files?

> 
> @ L A Walsh: you wrote "1) if you try to delete the file in cygwin"
> 
> Why shouldn't I be able to remove symlinks with rm -rf from within a 
> cygwin? As far as I understand the standard behavior of "rm" is to 
> remove the symlink and not its target. 
---
	With posix/linux type symlinks, yes, but am not equally
sure that windows behaves the same in all circumstances.  One thing
you could try is to use cygwin-only symlinks and not use
native symlinks -- the cygwin-only links should be more reliably
just controlled by cygwin rules.  If they are native links, there
might be some windows settings interaction(s).

> In case it doesn't work the symlinks are quite hard to get rid of. 
> FSUTIL REPARSEPOINT DELETE is the only method which works I found so 
> far. Even after a reboot, resetting the ACLs in various ways, ... no 
> usual method to remove these files works.
---
	How were these links created?  Also, MSsymlinks unlike
unix symlinks require the target's existence when they are setup.
unix symlinks do no checks on the target.  If the target is missing,
some operations on that symlink (if it is a win-symlink) might not
work as expected.

	Also note, that these two entries in my root dir
look like this from unix:
lrwxrwxrwx   1           20 Nov  6  2014 Prog -> /Program Files (x86)/
lrwxrwxrwx   1           13 Apr 21  2013 Prog64 -> Program Files/

Both sorta look like symlinks.  But in windows, they look 
different because they were made differently, and they may
have different effects on 'rm' from cygwin.

2014/11/06  19:45    <JUNCTION>     Prog [C:\Program Files (x86)]
2013/04/21  22:53    <SYMLINKD>     Prog64 [Program Files]


1. Make sure the symlinks you see in cygwin are the same type.
2. you say you have symlinks left over after you try deletion.
Do they point to existing files? or not?  If not, what happens if
you create the target of one of them, and then try deleting the
symlink?  
3. you said you had to use fsutil to remove some symlinks --
have you tried just 'del' in windows? 

Anyway, sorry to write so much, but I'm trying to point to how there
can be many differences, even when you think you are doing the same
thing to delete a cygwin.

-linda