We all love Vista!



  • So... I recently purchased a laptop with Windows Vista installed on it.  After playing with it for a few months, I decided that I don't like Vista (for too many reasons to count), and am now trying to "downgrade" to XP.

    I figure since I'm trying to get rid of Vista, I might as well just reformat the laptop and reinstall XP from scratch.  Since I have a bunch of important files on the laptop, I decide to back everything up to an external hard drive before I do the reformat.  Sounds simple, right?

    Attempt #1:  Select my user account's folder (C:\Users\Account Name), and copy it to the external hard drive.  After grinding away for a few minutes, it pops up an error message saying it can't copy some file, and fails.  I try again, and the same thing happens.

    Attempt #2:  I bring up a command prompt, and run XCopy, Microsoft's command line file copy utility.  It grinds for about an hour, and after copying about 30% of my files, it spits out a message saying "Out of memory", and crashes.

    Attempt #3:  I've heard of this new Microsoft utility for copying files called Robocopy.  OK, so let's give that a try.  I bring up a command prompt, and do a Robocopy /?.  It returns about two pages of command line arguments.  OK, Let's see... /E for subdirectories... That looks like all I need.  So I start the utility, and let it run, and go get some lunch.

    I return two hours later to see it copying "C:\Users\Account Name\AppData\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Somefile.dat". 

    What the hell?  Looking more closely, I discover that Microsoft, in all of its infinite wisdom, created an NTFS Hard Link in C:\Users\Account\AppData\Application Data, called "Application Data", to it's parent folder.  This creates a virtual loop, so when you browse into the child folder, you see the contents of its parent, and so forth.  So I cancel the backup, and take a look at my external hard drive.  It has virtually nothing copied, except a tree of "Application Data" folders a mile deep.  Well, I don't need them, and it's taking up a ton of space on the HDD, so I try to delete them:

    The following is the exact number and order of dialogs that appeared.  I typed this while running it to make sure:

    > Are you sure you want to move this folder to the recycle bin? [Yes] [No]

    Yes!

    > Do you want to permanently delete this folder?  This folder contains items whose names are too long for the recycle bin [Yes] [No]

    Yes!

    > You need to confirm this operation [Continue] [Skip] [Cancel]

    Continue

    > Windows needs your permission to continue [Continue] [Cancel]

    Continue

    > Are you sure you want to move this folder to the recycle bin? [Yes] [No]

    YES!!!

    > Do you want to permanently delete this folder?  This folder contains items whose names are too long for the recycle bin [Yes] [No]

    FOR THE LAST TIME, YES!

    > The file name(s) would be too long for the destination folder. [Skip] [Cancel]

    What?

     

    So, it turns out I can't even delete this recursive folder tree thing from my external hard drive.  So now I have no backup, no useful external hard drive (I can't reformat it because it has other important backups on it), and therefore no way to get away from Vista!  So what the hell am I supposed to do now?  I can't back up my files, I can't delete my broken backup, I can't even see how deep the folder tree goes, 'cause windows explorer crashes if I open too many folders up.  I even tried a dos "del *.* /s" command, and it gave me an error too! 

    AAAARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGGGGGGGGGGG!!

    </100% truthful rant>

     

     

     

    PS For next time, I should have read the Robocopy command line argument reference line that said "/XJ :: eXclude Junction points. (normally included by default)", because that's Microsoft's official solution to the problem.  But since I didn't know that, I'm now 100% screwed.



  • Can't you ask a friend with Linux/Mac/Xp on his pc to cut down the "Application Data"-forest??



  • Have you tried a Shift+Delete? I don't know if that still works in Vista, but in every other version of windows (at least since 98) that bypasses the recycle bin and just deletes everything. Sounds like that might work.

    Also, thanks for confirming my decision to stick with XP on the laptop I just bought for my wife! :)



  • I did try a shift-delete, and it resulted in the exact same thing as regular delete, minus the first dialog box.



  • How weird and annoying. Well, when all else fails, I usually use a Linux live cd.



  • I wish I could vote this 6 stars out of 5, but alas 5 is all I can do. The baby Cthulhu weeps. At least we can rejoice that the 255-character limit on paths is now removed. It's just been replaced with a slightly longer one.

    You're not the first person to find Vista's Recycle Bin inform you that something cannot be stored in the bin, confirm physical deletion and then decide to put it in the Recycle Bin anyway (remember that funny screenshot series on Flickr?) Normally, it's harmless but irritating, but clearly in this case, it's show-stopping. I am not sure why it also prevents shift-delete but, by the sounds of it, shift-delete is bypassing the "Are you sure you want to put this in the Recycle Bin?" warning and not facilitating physical deletion.

    Which brings me to four WTFs:

    • Windows confirms placing files into the Recycle Bin. The whole point of the damn thing is that files are safe and secure, and you can take them out or Undo the deletion.
    • Turning off confirmation is retarded. It works fine for local drives, but it also turns off physical deletion confirmation for remote volumes where there is no Recycle Bin. You think you are safe, and suddenly realise you deleted something from a volume with no undelete.
    • Apple get all this right, as you would expect, but OS X seems to have lost its ability to restore files. Put something in the Trash, and you can no longer Put Away the file back to its source.
    • Which also reminds me -- Undo in Explorer is rather hopeless. In every possible way.

    The more I use OS X, the more I realise how dreadful the Finder is, and sadly, how much better Windows Explorer is. Restore deleted files directly, cut/paste to move, right-drag (very awesome), viewable Back/Forwards history, address bar to differentiate windows of identically-named folders ... And since Explorer still sucks rocks ...

    But nothing compares to an OS where it's possible to create a cycle in the file system. That is INSANE. Even the OS shouldn't be able to do that under its own demands.



  • While that's a most excellent WTF, why are you trying to copy the whole folder?  Is the Start Menu and that sort of thing even stored in the same structure as XP?  I'd try copying just what you need first.

    This WTF is definitely familiar to me, though.  I wanted to set up my little brother's laptop with everything he needed and then make an image of the Windows partition for easy reinstalls, but I wanted to create a junction to the main partition as his Documents and Settings folder so he didn't lose anything if I restored the image.  As you've noticed, Windows gets upset if its settings start disappearing, so I had to do it through BartPE, which caused some more problems because the drive letters were different.



  • @Daniel Beardsmore said:

    But nothing compares to an OS where it's possible to create a cycle in the file system. That is INSANE. Even the OS shouldn't be able to do that under its own demands.



    Isn't it possible to do cyclic symlinks in *nix?



  • I can create cyclic symbolic links in OS 9 and Win2k, but generally you don't follow those when copying data -- you copy the symlink as a file. The snag here is creating cyclic hard links which are spectacularly fatal. (You do have to be very careful in Mac OS as aliases (symbolic links) in some frameworks can get automatically resolved for you and then you can get in trouble ...)



  • @Rotary Jihad said:

    @Daniel Beardsmore said:

    But nothing compares to an OS where it's possible to create a cycle in the file system. That is INSANE. Even the OS shouldn't be able to do that under its own demands.



    Isn't it possible to do cyclic symlinks in *nix?

    Yes using ln.

    We just try not to introduce a cycle as such (child owning parent).

    We also expect the commands to be a little more intellegent. (Detect that this is the same file as a prior copied, and create a suitable hard or symbolic link to match).


    @Daniel Beardsmore said:

    <snip>

    Which brings me to four WTFs:

    <snip>

    • Apple get all this right, as you would expect, but OS X seems to have lost its ability to restore files. Put something in the Trash, and you can no longer Put Away the file back to its source.

    <snip>

    The more I use OS X, the more I realise how dreadful the Finder is, and sadly, how much better Windows Explorer is. Restore deleted files directly, cut/paste to move, right-drag (very awesome), viewable Back/Forwards history, address bar to differentiate windows of identically-named folders ... And since Explorer still sucks rocks ...


    And while finder doesn't have the lovely "restore file" and undo delete commands, it also doesn't have the concept that it is dealing with a stupid user. You probably put the file in the bin for a reason, you probably intend on deleting it. If you accidentally put a file in the bin and didn't mean it, you can use command-z to undo your last action (ie. you are smart enough to realise a stupid action). If you have deleted a really important file, being such an intellegent user, you have a backup and know where it is. In the grey between those two extremes, why did you put it in the trash if your intention wasn't deletion?

    Admitedly a copyable piece of text containing the full path of a folder/file would be nice, even just as a configurable option.



  • @Kain0_0 said:

    And while finder doesn't have the lovely "restore file" and undo delete commands, it also doesn't have the concept that it is dealing with a stupid user. You probably put the file in the bin for a reason, you probably intend on deleting it. If you accidentally put a file in the bin and didn't mean it, you can use command-z to undo your last action (ie. you are smart enough to realise a stupid action)

    That is assuming that you just deleted the file. I might have deleted it a minute ago, whereupon Undo will have to undo everything I've done in the last minute to get to it. Cf. undo stack interleaving in Microsoft Excel.

    I may have deleted the file a day or ten ago. It's just nice in OS 9 and Explorer to Put Away/Restore a file back to where it originated. It's been around for years and Apple decided to drop it at a whim.

    @Kain0_0 said:

    Admitedly a copyable piece of text containing the full path of a folder/file would be nice, even just as a configurable option.

    That sounds like a job for OnMyCommand. Actually, the Mac approach is to let you copy file names, which is truly invaluable. (That does still work in OS X) In Windows ... no such feature. So, how do you do it? There's no sanctioned ActiveX way to copy to the clipboard, and the best I've seen so far is this:

    • Gather all the command line arguments (paths or filenames, whichever you want) into a CRLF-delimited string
    • Launch Internet Explorer as an ActiveX object
    • Ask it to navigate to about:blank (!)
    • Spinlock until it has finished loading about:blank (don't ask me, it's what the code says)
    • Write the paths string to Internet Explorer's document's parent window's ClipboardData object
    • Quit Internet Explorer

    There is a noticeable pause for this, and the active window loses focus for half a second.

    I hope there is a better way.



  • Move pieces of the subtree closer to the root, then delete them.  I've had to do this before with obscure malware files that had found there way into my Temporary Internet Files folder.  The system may be able to move the files even if it can't delete them immediately.  Once they have moved, the path length will be shorter, and deleting them will be no problem.

     
     



  • Really good WTF. I am personally running Linux and I would do some kind of "unlink" here,that sound much more sane than deleting. And I hope that It would not let me crete hard-link like that. But the best thing are theese messages. Maybe there is a new msgbox function with parameter int severity added :). Than it goes thorught the cycle of displaying the msgbox severity times and each time changes the question a little bit.



  • @Rotary Jihad said:

    @Daniel Beardsmore said:

    But nothing compares to an OS where it's possible to create a cycle in the file system. That is INSANE. Even the OS shouldn't be able to do that under its own demands.



    Isn't it possible to do cyclic symlinks in *nix?

    You can, but only using symbolic links. They are easier for programs to notice since its very easy to see if a file is a symlink or a real file.

    For hard links, its virtually impossible to say if the file is a link or if its the "original" since they are, by definition, the exact same thing. And *nix (linux at least) does not allow you to create hard links to folders.

     



  • The real WTF is that he tried to remove a folder structure with "del /s *". The DEL command only removes FILES and nothing else. For removing directories, you should use RD or RMDIR.

    "RM /S ." also removes all files and subdirectories, and if you only want to remove empty directories, you may use "for /r "delims=" %i in ('dir /s /b /ad ^| sort /r') do rd "%i".



  • Maybe you should stick to a box of rocks instead of a computer or call 1-800-GEEK-SQUAD.



  • I just took the Vista plunge a few days ago, when I had to buy a new box to replace my suddenly-hovering-near-death desktop machine. Installation went fine, and once I had Aero and the rest of the useless graphical crap turned off, things were looking just fine.

    Then I tried to use the 'Easy File Transfer' to slurp stuff off the old machine (which I'd coaxed into booting up so I could get various things off it without having to do a drive transplant). Two attempts failed with no discernable reason, except the screen saver kicked in on the old machine (who knew the 'Blank' SS was so resource hungry it could kill network links...) both times. hmm... 3rd time it worked and it copied over everything it decided should be copied (about 1/3rd of what really should have been).

    That's when things went south. I'm guessing it copied over a DLL or something from XP Sp2 and nuked the equivalent Vista once, because now I cannot get *ANY application to display a file picker. They all either just silently crash, or spit out a "Windows has unexpectedly closed the file picker" error.

    How nice... Good thing I haven't finished installing my old apps on the new box. Much easier to just nuke Vista and start from scratch, and manually do my app copying.

     

    Other than that, my only major gripe is the stupid Explorer windows. Anyone know how to disable the @%@#$@# address bar and task options? Address bar I could somewhat live with, but the task options are generally always WRONG for the filetypes in the windows, and I ain't going to be using the standard M$ trashy tools, I've got other (read: better) apps for those options, and I'll start them myself from the Start Menu or Desktop, thankyouverymuchBill.


     



  • @isaks said:

    For hard links, its virtually impossible to say if the file is a link or if its the "original" since they are, by definition, the exact same thing. And *nix (linux at least) does not allow you to create hard links to folders.

    Actually, both linux and most other unixes permit this, via ln -d, but very few of the filesystems they support will allow you to; it's widely regarded as a bad idea and the support is only there for historical compatibility with old filesystems (I haven't found anybody who knows why modern NTFS versions include it).



  • NTFS junctions aren't really hardlinks, although they do have some behavior that looks like them - but just like with symlinks, there's still only 1 real directory on disk, and the rest are junctions (which are clearly identifiable as such).

    P.S.: why does this editor arbitrarily decide to stop wrapping text?



  • Actually: you can *sort of* hard link directories in linux, and I think NTFS folder to folder junction is basically equivalent to this. It's not technically a "hard link" however, so much as it's a request for the kernel to basically jump elsewhere to resolve a path (which actually is basically like NTFS junctions if I recall correctly), aka a mount:

    /tmp # mkdir test
    /tmp # cd test
    /tmp/test # mkdir test
    /tmp/test # mount --bind /tmp/test /tmp/test/test/
    /tmp/test # ls /tmp/test/test/
    test
    /tmp/test # ls /tmp/test/test/test
    /tmp/test #

    It seems neither --bind nor --rbind can get the infinitely recursive filesystem effect that can be acheived with ln -s. Note the last ls gives an empty dir. It will with both --bind and --rbind. You'll also note that attempting to tab complete also only gets as far as /tmp/test/test/test/ with either. I would imagine it is possible to do through indirectly looping (r)bind mounts but I don't feel like trying to figure it out.

    (edit: guess this should've been in reply to the post right before the one I quoted)



  • @aquanight said:

    Actually: you can sort of hard link directories in linux, and I think NTFS folder to folder junction is basically equivalent to this. It's not technically a "hard link" however, so much as it's a request for the kernel to basically jump elsewhere to resolve a path (which actually is basically like NTFS junctions if I recall correctly), aka a mount:

    /tmp # mkdir test
    /tmp # cd test
    /tmp/test # mkdir test
    /tmp/test # mount --bind /tmp/test /tmp/test/test/
    /tmp/test # ls /tmp/test/test/
    test
    /tmp/test # ls /tmp/test/test/test
    /tmp/test #

    It seems neither --bind nor --rbind can get the infinitely recursive filesystem effect that can be acheived with ln -s. Note the last ls gives an empty dir. It will with both --bind and --rbind. You'll also note that attempting to tab complete also only gets as far as /tmp/test/test/test/ with either. I would imagine it is possible to do through indirectly looping (r)bind mounts but I don't feel like trying to figure it out.


    I don't think so.  "/tmp/test/test" does not contain "/tmp/test", it merely provides a mapping point for it.  Because of this, you can't get an infinite loop.


  • If you still need to backup the system just get a live cd of either knoppix or ubuntu and then copy the files that way, I have done it many times with vista now and have not had a problem copying the entire hard drive to a usb drive before reinstall the OS.

     

    Good wtf though, that is messed up.



  • Just move some of the subfolders into a different folder, this will shorten the tree and allow deletion of folders within it as well as those that you just moved.

     

    I realize this is probably too late for you, but I just ran into this thread...

     So, you know for next time, if it happens again.


     



  • Copy the files you want to keep from your backup onto your main HD and then format your backup.

    or try going to D:\Users\AccountName\Application Data in dos and run rmdir "Application Data" /s /q



  • @Albatross said:

    AAAARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGGGGGGGGGGG!!

    You are coming to a sad realization.  Cancel or Allow? 



  • @Strider said:

    Copy the files you want to keep from your backup onto your main HD and then format your backup.

    or try going to D:\Users\AccountName\Application Data in dos and run rmdir "Application Data" /s /q

    I would have formatted the backup drive, but it was a 'shared' backup drive with several other important backups already on it.  Also - I tried rmdir in dos, but it returned with an error message relating to the 255-character path limit.  Thanks for the advice, tho



  • ohh,poor you... and of course had you actually gotten that far, since the laptop CAME WITH VISTA! They might (I said might) not actually have XP drivers. so either way, you're scr3wed!!!



  • The real WTF is thinking Robocopy is new.



  • Hmmmmm...what about:

    - mkdir Account Name (on external HD) 

    - Navigate to your Account Name folder on Vista 

    - Ctrl+A;

    - Ctrl+Click on Application Data to unselect it

    - Ctrl+C;

    - Ctrl+V on external HD

    Or is there something I'm missing?
     



  • I FEEL YOUR PAIN!

    I have robocopy scripts backing up my "Users" directory every night, to two different places.  Just like I do with "Documents and Settings" on my XP machines.  Well today I've decided to hell with that, I'm not using the Microsoft User folders anymore, they always get too cluttered with junk.  So I go to delete them and ... I CAN"T!  And we're not talking about the files that are on the Vista machine and probably in use.  These are copies of the files sitting on a 2003 server!

    "Filenames are too long"
    "Can't delete file:"

    Reboot...

    "Filenames are too long"
    "Can't delete file:"

    Boot to safe mode...

    "Filenames are too long"
    "Can't delete file:"

    UNBELIEVABLE.

    So, thanks for the /XJ tip, I'll add that one to the arsenal.  But I'll be avoiding the Users directory like the plague from now on.



  • Thoughts:

    The "Path name too long" error should only happen when you're doing stuff (like deletes) that have to mess with the stuff really deep into the tree... things that only tinker with the top of the tree should work OK.

    So rename "Application Data" to "a", then open it up and rename "Application Data" to "a"... that way the path keeps on shrinking, and it shouldn't (in theory, though this is Microsoft) have to descend into the tree to rename a dir.

    Hopefully, by the time you're done, the full path name will fit in MAX_PATHLEN chars and you'll be able to delete it. Then you'll have your external HDD back, and you can get on with whatever you are doing.

    Still, an OS that can create files it can't delete == massive fail. Indeed, Windows being able to create paths longer than MAX_PATHLEN, and being unable to delete them, are both, individually, massive fail.



  • @Phlip said:

    Still, an OS that can create files it can't delete == massive fail. Indeed, Windows being able to create paths longer than MAX_PATHLEN, and being unable to delete them, are both, individually, massive fail.

    A certain P2P system has a problem with this. Certain files cannot be downloaded by another user due to excessive path length, owing to too many nested folders with long names. The files can be opened at the source end just fine, but cannot be downloaded. Explorer can see and manipulate this faulty directory tree, and other applications can use the excessively long paths, but at least one app sees a shorter limit.

    How this makes sense, I have no idea. The only conclusion that I can draw is that it's not a hard (or a fixed) limit, and not all programs obey it. Explorer in Windows 2000 seems to have a softer limit than other software.

    Better systems don't even have path limits, or, rather, have a limit high enough to not be a problem. (Mac OS prior to X had no limit as directories were represented only by UIDs in most cases; I don't know whether modern Mac apps still use them.) But you still have a filename limit, 255 pseudo-characters. UNIX probably has a 255-byte limit, whereas Mac OS X has a 255 UTF16-character limit, using decomposed characters. In both cases, it's pretty obvious that there's no longer a meaningful idea of maximum filename length. For example, "é" on Mac OS X is split into "e" + "´", causing it to suddenly eat two UTF16 characters. Out-of-range code points will also start eating characters, especially with UTF8 filenames where anything outside of 7-bit ASCII needs at least two bytes.

    Imagine writing code that validates filenames being within the length limit ...



  • There are 2 limits regarding paths on Windows: the traditional 260 bytes limit for path length (Windows 9x legacy), and the ~32000 characters limit (NT when using Unicode APIs with paths prefixed by \?). Unfortunately almost all Windows programs (including Explorer) use the 260 characters limit, which causes problems when you manage to create deeper trees. You can get more detailed info at MSDN. I don't know what are the limits on Linux, except that a single path element is limited to 255 bytes.



  • @ender said:

    I don't know what are the limits on Linux, except that a single path element is limited to 255 bytes.

    Filesystem-specific. Some syscalls are limited to PATH_MAX bytes of data in their arguments, which is 4k.



  • @Daniel Beardsmore said:

    Better systems don't even have path limits, or, rather, have a limit high enough to not be a problem. (Mac OS prior to X had no limit as directories were represented only by UIDs in most cases; I don't know whether modern Mac apps still use them.) But you still have a filename limit, 255 pseudo-characters. UNIX probably has a 255-byte limit, whereas Mac OS X has a 255 UTF16-character limit, using decomposed characters. In both cases, it's pretty obvious that there's no longer a meaningful idea of maximum filename length. For example, "é" on Mac OS X is split into "e" + "´", causing it to suddenly eat two UTF16 characters. Out-of-range code points will also start eating characters, especially with UTF8 filenames where anything outside of 7-bit ASCII needs at least two bytes.

    Imagine writing code that validates filenames being within the length limit ...

    MacOSX filenames are a rather incredible WTF in their own right. You can refer to a file in six different ways:

    1) As a FSRef. This is a magic 80-byte value that uniquely identifies a file, and can be passed from one program to another. It cannot refer to a non-existant file. It does not remain valid across reboots. There are no limits to path length.

    2) As an alias. This is a magic value that uniquely identifies a file, can be passed from one program to another, and that remains valid across reboots and even if the file is moved on the volume or renamed. It can refer to a non-existant file. It does not remain valid if the file is moved to another volume. It has some bugs relating to files being renamed and then replaced with other files of the original name. There are no limits to path length.

    3) As an FSSpec. This identifies a file by the combination of volume ID, parent folder ID, and filename. It can refer to a non-existant file. If the filename is 31 bytes of MacRoman-compatible characters, the FSSpec can be passed from one program to another, and remains valid across reboots. If the filename is longer, or uses non-MacRoman characters, the FSSpec is invalidated if the program is restarted. An FSSpec remains valid if any of the folders containing the file are renamed or moved. There are no limits to path length.

    4) As a UTF-8 path using the standard file hierarchy. It can refer to a non-existant file. Path length is limited to MAX_PATH.

    5) As a UTF-8 path using the hidden file hierarchy. It cannot refer to a non-existant file. This is an undocumented way of identifying a file that guarantees the path will be shorter than MAX_PATH.

    6) As the combination of the FSRef of the parent folder, and the UTF-16 name of the file. This has the same limits as an FSRef, except that it can refer to non-existant files.

    The real excitement comes from how the different methods are used. MacOS 9 programs tend to use FSSpecs and aliases. Carbon programs tend to use FSRefs. Cocoa programs (including the Finder and many of the OS utilities) tend to use paths. Unix programs always use paths. The OS uses all of the above, including the hidden file hierarchy. Funny and counterintuitive things happen if you create a directory hierarchy deeper than MAX_PATH.



  • Try this script:

    http://www.jsifaq.com/SF/Tips/Tip.aspx?id=9651

     

    I found it via a blog ( http://davidgardiner.blogspot.com/2007/03/preparing-for-vista-rtm-backing-up-your.html ) and it worked for me.

    For interest, here's the sizes and times - showing how crazy deep the tree was (note, the one "Skipped" was the folder I was in... I accidentally issued the command from the top folder  I wanted to delete, so just had to remove it afterwards):

                    Total    Copied   Skipped  Mismatch    FAILED    Extras
         Dirs :         1         0         1         0         0      1541
        Files :         0         0         0         0         0     25647
        Bytes :         0         0         0         0         0   1.127 g
        Times :   0:07:35   0:00:00                       0:00:00   0:07:35
    


  • Sorry for restarting an old thread, but...

    @Daniel Beardsmore said:

    I hope there is a better way.

    To copy the fill path of a file in Vista, shift+right-click on the folder, and click Copy as Path.

    Shift+right-click brings up a bunch of extra goodies on most folders, like the aforementioned Copy as Path, and Open Command Window Here.



  • @Fred Foobar said:

    Sorry for restarting an old thread, but...

    @Daniel Beardsmore said:

    I hope there is a better way.

    To copy the fill path of a file in Vista, shift+right-click on the folder, and click Copy as Path.

    Shift+right-click brings up a bunch of extra goodies on most folders, like the aforementioned Copy as Path, and Open Command Window Here.

    Hm, but I said that I want to copy names, not paths. Open Command Window Here is much easier if you add cmd /k cd "%1" to HKLM\Folder\Shell\cmd\Command: no need to hold shift that way (and I only use that command on folders; for a window, just right-click the window's control/system/window menu (whatever Microsoft are calling it this week)

    Note, calling cmd /k cd "%1" on the Recycle Bin or other interesting items in Win2k can cause Explorer to crap itself. Try to stick to actual folders :)



  • @Daniel Beardsmore said:

    Hm, but I said that I want to copy names, not paths.
     

    Sorry to resurrect an oldish thread, but if you ever need to copy filenames in the future, try Clipname:

    http://www.mainsoft.fr/en/downloads.htm



  • @ OP: this is the reason why i use linux(if something like that happens, I can change it myself (but by the time I get to it someone has already changed it and I only have to update my software)) 



  • @Daniel Beardsmore said:

    But nothing compares to an OS where it's possible to create a cycle in the file system. That is INSANE. Even the OS shouldn't be able to do that under its own demands.

    I was reading up on OS X Leopard and Time Machine the other day, and it seems Apple has added more hard link functionality. From the Ars Technica review:

    "Time Machine goes one step further. Historically, Unix has only allowed hard links to files. In Leopard, Apple has included the ability to make hard links to directories. This has not been allowed in Unix because it can lead to all sorts of very nasty infinite loops during file look-ups. Of course, symbolic links can create loops too, but they're a lot easier to detect and prevent since symbolic links are easily distinguished from normal files. But as discussed earlier, every file is essentially a hard link, and all hard links have equal standing in the eyes of the OS, making loop detection a bit trickier."



  • @CodeSimian said:

    Sorry to resurrect an oldish thread, but if you ever need to copy filenames in the future, try Clipname ...

    I do already have a tool for this installed, but thanks for the tip.

    @OzPeter said:

    I was reading up on OS X Leopard and Time Machine the other day, and it seems Apple has added more hard link functionality. From the Ars Technica review: ...

    Apple may just get away with this. Mac OS X still uses the HFS+ file system, which has no hard link support. Apple provide some tortuous hacks to simulate hard links, and it may be possible to tell whether a file is a hard link or not.

    I like the way they're using hard links in Time Machine, it's a very elegant solution, except of course also very dangerous!



  • Since robocopy caused the problem, you can use robocopy to remove the problem.

    Resolution:

    1. Create a folder.  Doesn't matter the folder name or location.  I used D:\B
    2. robocopy /MIR /log:D:\nul D:\B [RecursiveCopiedFUBARFolderName]

    If you don't use the /log:D:\nul option, it will take about three times as long to remove the folders.  Of course if you do use the /log... option, you won't be able to see any progress besides the memory usage climing for robocopy.

    It will take quite a while to purge depending on how long it was running before you cought it but it will eventually remove the folder structure... Eventually...

    -Burr Headed [Server Simian|Code Monkey]



  • @Green1A said:

    -Burr Headed [Server Simian|Code Monkey]

    Please prepare your ass for a large amount of flames involving comments such as "WTF, look at the dates you fucktard" and "MPS, SFTU no-one likes you", other classics include "You are TRWTF, goddbye." and "lern2read, QQ newb". Don't worry, your ass will heal eventually.



  • @Albatross said:

    Attempt #1:  Select my user account's folder (C:\Users\Account Name), and copy it to the external hard drive.  After grinding away for a few minutes, it pops up an error message saying it can't copy some file, and fails.  I try again, and the same thing happens.

    I've seen this happen in Windows XP/2000 but not Vista.  In fact I just tried copying the entire C:\USers\Account Name tree to an external drive and it worked fine.  Near the end of the copying process it did pop up a dialog box telling me that it couldn't copy a file, so I just clicked on the "Skip" button and it proceeded with the copying.  This is certainly an improvement over previous versions of Winodws which just stopped when encountering an uncopyable file.  This does however point out a WTF that has annoyed me for many years -- why are there certain "important system files" that can't be copied?  It makes sense.that you can't delete, move or rename them --  but can't even copy them?  WTF? 

    And I don't have a NTFS Hard Link in C:\Users\Account\AppData\Application Data, called "Application Data".

     I guess I must be the luckiest person n the whole world.  Everyone is constantly bitching and complaining about problems with Vista but it has performed quite well for me.  There are  a few design WTFs where they removed functionality that was present in XP, but that's another story.



  • @Albatross said:

    Attempt #1:  Select my user account's folder (C:\Users\Account Name), and copy it to the external hard drive.  After grinding away for a few minutes, it pops up an error message saying it can't copy some file, and fails.  I try again, and the same thing happens.

    It won't be able to copy registry files of the currently logged-on used. Log on as Administrator (I hope you're NOT an Administrator, as it's very poor practice security-wise) and repeat that. You actually DON'T need those registry files.

    2. Vista creates quite a few aliases for legacy (pre-vista) names and paths. If you use an old program that doesn't recognise symlinks and reparse points, you might be screwed.

    3. You can make CMD.EXE operate on very long paths by prepending the path spec with \\?\. In this case, the filename may have to include full path; it cannot be relative to the current directory. Such names are passed from a user process to the filesystem without any legacy fudging, like catching COM1 or such names. You can even create/delete a file with period ('.') character at the end. Such file in not accessible without the magic \\?\ prefix, because for legacy compatibility, a trailing period is removed when the name is passed to the filesystem.

     



  • @Lingerance said:

    @Green1A said:
    -Burr Headed [Server Simian|Code Monkey]
    Please prepare your ass for a large amount of flames involving comments such as "WTF, look at the dates you fucktard" and "MPS, SFTU no-one likes you", other classics include "You are TRWTF, goddbye." and "lern2read, QQ newb". Don't worry, your ass will heal eventually.
     

    Actually, TRWTF is the two fucking clowns who SHOULD know better (50+ posts) and they STILL decided to answer the OP back without paying ANY attention.



  • @MasterPlanSoftware said:

    @Lingerance said:

    @Green1A said:
    -Burr Headed [Server Simian|Code Monkey]
    Please prepare your ass for a large amount of flames involving comments such as "WTF, look at the dates you fucktard" and "MPS, SFTU no-one likes you", other classics include "You are TRWTF, goddbye." and "lern2read, QQ newb". Don't worry, your ass will heal eventually.
     

    Actually, TRWTF is the two fucking clowns who SHOULD know better (50+ posts) and they STILL decided to answer the OP back without paying ANY attention.

    MPS, STFU, no one likes you.



  • Ya - this stupid problem bugged me too.

    So, I spent a minute to rename 20 of the "Application Data" folders to "A" by hand. It became kind of a zen thing...

    This action allowed me to "start" deleting the backup directory. It took about 10 minutes to delete 49000 items (11GB).

    Then I got an error that the file names with path for another 250 items were still too long. So, I renamed another 10 folders, and it all deleted.

     



  • Please do not bump topics (see the date of the last posting, and the general age of this topic).

     

    Topic locked. 


Log in to reply