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.
Related
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.
stupid question perhaps, but addressing a 40 year old stupid OS... I have a RAID6 array on a server which contains some 8TB in one partition. This is the Ubuntu box. I then have a Win 7 box, whereby I have 12TB in 6x2TB drives.
I am trying to copy the folders from ubuntu RAID6 to Windows 7, but as follows:
Drive 1 of Win 7 contains all folders A to D, drive 2 contains E to G, etc.
I started the copy / back up but then I had Windows reboot (thank you!) due to automatic updates installed. Having turned this off, I now want to restart the copy, but of course, the very smart Windows copy routine tells me there is not enough space on the destination drive to copy all A to D folders as it checks for space without consideration of duplicate / existing files at destination... so the only way I can see is to erase all copied folders and start again... bloody stupid.
I have tried Robocopy, FastCopy, SimpleCopy but I cannot get a piece of SW that can just copy the MISSING / NON EXISTENT files in the destination drive. Some of these programs do not even let me select Folders A - D...
How can I copy the missing files only, without having Win 7 check for available space before starting the process?
Not sure that there is a way. Have you looked at SyncToy. It is an MS software and might be able to help you with that. The other thing that you can do; assuming you are using some sort of smb copy and not ftp or anything; why not mount the windows drive on the linux box and do the coping on the linux box rather than on the windows box?
We need to distribute lots of small jpg files to offline systems. Right now, we send it as a 7zip (or plain zip) which is 800MB (230K files) and use 7zip to unzip it. It is taking about an hour to unzip on fairly large 4 core processors.
Is there a way on windows7 (or win server 2008) to create and unpack a package of files of this size in a more reasonable time frame?
(I will entertain even far out answers such as: put this all in a single CloudDB database as binary blobs and then ship the archive to the target machine, or create a VM, or a virtual disk image - but I will need some pointers to tips on doing that sort of stuff).
So then here's your far out answer: ;)
The problem probably doesn't lie in computing power. The filesystem and/or harddisk are the bottleneck most likely.
For Win7 (and afaik Server2008 as well) you could use a Virtual Hard Disk instead of zipping it. Win7 has native support for VHD-files and can emulate the content as a drive or subfolder via Disk Management. So there would be no need to unzip the files.
I had the same problem, and solved it. The issue is likely the Windows Attachment Service, which subjects downloaded or attached zip files to additional scrutiny for security reasons.
To bypass this:
Right-click the file
Choose Properties
Check Unblock
For more info, see: Why is WinZip slow?
I spoke to some colleagues, and they might have an easier solution. Since the size is under 4GB, and I want READ-ONLY access, I can create an ISO image, and then mount it on win7 or win2008server, using this Microsoft utility:
This utility enables users of Windows XP, Windows Vista, and Windows 7 to mount ISO disk image files as virtual CD-ROM drives.
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.
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