Finding and deleting bad symbolic links in windows - windows

Is there any simple way to find broken ntfs symbolic links in windows and delete them? (other than manual search and destroy)
I'm in this mess because of windows home server's inability to upgrade without removing disks :/ and the files are scattered randomly on a bunch of disks (but the structure is intact and mirrored on all disks)

Junction Link Magic should find and delete bad symbolic links:

You can use a SageLinks utility (it's open source), it shows and test NTFS junctions, symbolic links and shortcuts.

Related

Am I losing space on C: to IIS 'sites', and what can i do about it?

Factoid One:
I have been happily creating "sites" using IIS. If I want to try something out, I just start IIS Manager, right-click 'sites', click Add Site, put a folder name in the 'Physical Path' box and add an unused Port number. There are now 30 entries in the "Sites" list.
In every case, the "Physical Path" is an F: folder, and nothing in any of those folders directly references another drive.
Factoid Two:
For months, i've been getting warnings about shrinking C: space. I go to Settings/System/Storage, and clean up what I can. I set up a couple of Simlinks to move folders to the much larger F drive. I get some space back, and pretty soon the messages begin reappearing.
Factoid Three:
After the latest warning about space on C:, I began looking around the C: drive (again). Now I discover C:/Users (how did I miss this before?) has folders whose names correspond with IIS Site Names. Inside some, and probably all, are folders named AppData, Application Data, Cookies..., a large subset of the folders found in any Users/username folder.
Finally the question:
Until I saw (3), I did not suspect a relationship between my naive use of IIS, and disappearing space on C:. Now I see a relationship, but I don't understand it. What is it, and how can I create "sites" w/o clobbering my C: drive? (And why does IIS need to reproduce a user folder, if that's what's happening?)
It is unlikely that IIS is using much space for those accounts. They are only created/used by IIS so you can manage (limit/grant) permissions (file access, db access, nw access, etc) for anonymous visitors to IIS (if your web apps need to do that kind of stuff).
You can check the actual usage (space) for those accounts: right-click and choose Properties for folders within those c:\users folders. Chances-are they will only be around 85 MB. IIS does keep logs. Those files will grow. They are in your c:\inetpub\logs\ folder and adjacent folders. Those won't be very big unless you generate a lot of traffic to your IIS server.
More likely, your space is being consumed by windows updates. My pc seems to accumulate 100mb periodically from win updates (I just checked mine: 8.9gb). Check your c:\windows\installer and c:\windows\temp folders. Those can be compressed, or if you need the space, you could purge old installer & temp (files older than 2 years). Just be careful/cautious/gentle with deleting stuff. Don't just take the opinion of one guy on stackoverflow please.
There are other good utilities you could use to find out what is using so much space.
Bottom line: it is very unlikely to be IIS or logs, or utility accounts.

Can I move Windows SDK folder to another volume?

I have got plenty of Windows SDKs installed with Visual Studio. The two directories Program Files (x86)\Microsoft SDKs and Program Files (x86)\Windows Kits take a lot of space (approx. 2 GB). Can I move these directories to another volume to reclaim some space on my small SSD C: drive? Can NTFS links to folders or junction points be used to do it? I mean to let it think the files are still in their original places but to place them physically to a different place on a different volume.
Similar question was already asked ( Safely move Microsoft SDKs folder ), but neither NTFS links nor NTFS junction points were discussed there.
Never tried, but I'd do it the UNIX way - move them and put an NTFS junction (pointing to the new location) in the original position, I don't see why it shouldn't work.
Yes, just to confirm Matteo's guess: I've done it using NTFS junction, and works perfectly fine.

How to recover the deleted or moved data from a particular directory in Linux Environment?

I accidentally moved some files from /home/name/Pictures/ directory from my opensuse 11.4 machine to flash drive. Is there a way to recover the data? I lost the data from my flash drive.
Probably no.
Many (most?) Linux desktops have a "wastebasket". If you delete files using the GUI, you should be able to recover them from the wastebasket GUI:
There are also tools like TestDisk or ExtUndelete that might be able to help you:
http://www.linux.org/threads/undelete-files-on-linux-systems.4316/
http://extundelete.sourceforge.net/
Finally, here are some other links that might (might!) help:
http://www.linux.org/threads/undelete-files-on-linux-systems.4316/
https://superuser.com/questions/150027/how-to-recover-a-removed-file-under-linux
https://help.ubuntu.com/community/DataRecovery
http://www.smashingapps.com/2011/08/11/5-must-have-file-recovery-tools-for-linux-users.html
But frankly, your best choices for Linux are the same as for Windows: keep backups of anything you really care about!

Silverlight 5 Trusted Mode. Accessing FileSystem and Local drives

Is there any way, any chance at all to access entire filesystem in SL app with elevated trust?
That will work both in Windows and Mac?
Through AutomationFactory,PInvoke or unmanaged code?
I need an app that could read local drives, folders and files.
UDP: Ok, seems it's possible to read folders and files using classes of System.IO from mscorlib. Although you still can't get information about local mounted drives. There is no DriveInfo in Silverlight's mscorlib :(
Ok I have an idea about this.
It is straightforward enough with Windows, to get the list of the local drives you can use AutomationFactory. There is plenty amount of examples if you google it. Search for something called SilverlightFileExplorer.
Now on a Mac you can use Directory.EnumerateDirectories("/") and then it gets all the folders in the root. Including Volumes folder which contains shortcuts to the local drives. I'm not an expert of Berkeley System Distribution (BSD) Unix filesystems, so I can't really promise that it would work on any Mac, but this approach works on mine.
I'm still playing around with that. When I get working prototype I'll probably share it through github or something.

Windows XP vs Vista: NTFS Junction points

Problem: I relied heavily on NTFS Junction points in Windows XP, even though they apparently were not an "official" feature of the operating system. Now MSFT has generously made NTFS Junction points an official part of Vista, but apparently they also intentionally broke them. Now my WinXP-created junction points on portable USB drive don't work when I plug that drive into a Vista box.
Questions: Does anyone have a script that will force NTFS junctions created on XP to work correctly within BOTH Vista and XP? Is there documentation or a spec that explains what MSFT did to cause this breakage?
Update: Thanks, Ulrich and Scott, for your follow-up questions. The tool I used to create the junctions was Systinternals Junction v1.05 although I can't say for sure that all of them were created with that specific version of the now-MSFT-hosted app.
As far as how the junctions are used ... assuming an external "Q Drive" device:
1) Some items on the Q Drive are junctions that point from one place on the Q Drive to another place on the Q Drive (e.g., cases where I needed to have a folder in more than one place, and a traditional .lnk style shortcut would not work)
2) Some items are junctions that point from the C Drive directly to locations on the Q Drive. These items obviously do not work when the Q Drive is not actually connected box (XP or Vista), but when connected on Vista, the junctions do not work as on XP.
Junctions and symbolic links are two different types of NTFS objects and are not exactly the same thing. Why your junctions are not recognized in Vista is a mystery, but the junction functionality still exists in Vista and it not purposefully broken.
You can use mklink (http://technet.microsoft.com/en-us/library/cc753194.aspx) to create soft links (the default), hard links (/h), or junctions (/j). The biggest improvement of sym links over junctions is sym links can reference files OR directories (junctions are directory only) and the can reference network shares as well (junctions cannot).
But the bottom line is they are different. Can't tell you why your existing junctions are not recognized by Vista though. You can still create them as described above.
There freeware utility referenced in another post (LinkMagic) is your best bet to getting your junctions working again. Or recreate them with mklink.
Why don't you try with this program (freeware) to create the links. Apparently Windows Vista needs a different version. I have tried both versions (XP and Vista) and they work. I know it doesn't have to do with your specific problem, but given that there are separate versions for each OS, there might be diferences in the way Junctions are created.
The tool you have used is rather old (2007) and doesn't mention Windows Vista. I know that MSFT did change something in the Junction Points in order to add some functionality they wanted to use. Vista is more authoritative when it comes to Program Files folders and such.
Besides the Linkmagic program already suggested in one of the previous comments, Link shell extension is another good program to manipulate (and check) links and junctions:
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html
Both of these programs can tell you what the existing links/junctions point to, and what they are. This may help you in figuring out what's wrong.
What you trying to link to? Are you linking TO your portable drive or FROM your drive? Are you using "mklink /d"?
Junctions points within the same volume should work - they should be hardlinked directories.
Have you tried if the USB drive works between XP machines? It might not work.
I know that for vista the volumes are NOT identified by path (Q:) but by volume GUID.
The $MFT_REPARSE_POINT format might have changed from XP to Vista to accomodate this.
Under Vista, this mean that even if your Q drive is suddenly X, the junction point shoudl still work, where under XP it would be broken.
Christoph Hochstätter made an "mklink.exe" substitute for Windows XP that can actually create
genuine Vista (et al.) symlink reparse points, but warns that they may not be usable under
the Windows XP OS. However, Cygwin will recognise them under XP. And, of course, Linux ntfs mounts.
Not sure if this will be of much help though...
http://www.zdnet.de/windows_system_verbessern_mklink_f_uuml_r_windows_download-39002345-30973-1.htm

Resources