Ok, so here is my issue. I have a law firm that asked me to set up a simple backup script for their network drive... back up all their case files to external hard drives. The network is mostly Windows XP computers with one Windows 7 computer. The share drive is on a windows XP computer that I don't have direct access to normally (Its the attorney's office computer and it is rarely available to work on during the regular business day, which is the only time I have to work). So, I created a batch file, which is left on the backup drives, to xcopy the files through a symbolically linked directory on the C drive. I did that so I could set the same symbolic directory on all the computers and the script will work regardless of which computer they are plugged into.
So, my script runs xcopy with the /d /v /y /e flags, plus an exclusion file excluding random things like $RECYCLE.BIN and /RECYCLER/. Because a lot of the computers are XP, robocopy wasn't an option. Regardless, I found that running robocopy created the same problem anyway.
After copying everything over, the file system stops recognizing the backup directory. My batch file is still there. The exclusion text file is still there. The Backup directory, however, just vanishes. It almost like its hidden, but it doesn't show up when hidden files and directory are shown and, in the CLI, dir /ah doesn't pick it up either. It is there though... trying to create another "Backup" directory at that location is rejected and, if I remember where things are, I can still cd into the directory structure. I have tried restarting the external hardrive. I've tried rebooting the computer. I've tried refreshing the explorer. Nothing works. If I copy the files over, the directory that I copy them to just stops being recognized... every single time. Not sure if it matters, but I formatted the hard drives to NTFS. So, any ideas?
As a side note... $300 for tech support? Really? What I'm doing is really basic and simple, and I'm not using anything that isn't integral to your software... xcopy. You want me to pay $300 to report and fix bugs that are either in a fundamental component of your own command line application suite or with the compatibility of your file system? "Lets get them to pay for something that doesn't work and then make them pay us to fix it!" That is blatantly unethical. In any other industry it wouldn't even come close to being legit. If you paid a plumber to install piping in your house, and then your house flooded right after you turned the water on, is it reasonable to have to pay him again to fix the problems that he caused? Nobody would tolerate it... but somehow its a standard practice here. Your solution is "Either pay us, or get the community of other users to help you". There is a good reason why my entire business (not the law firm, but my business) runs on Linux and other open source software. If we are being told to "fix it yourselves" anyway, then I at least want access to the source code so I can. Seriously... I hate it when I have to come here to correct issues with MS overpriced, bloated, proprietary POS.