I'm so !@#$ frustrated right now. I've been working on a program to export documents out of our portal and onto a file system. This is enough of a pain in the neck as it is because the documents are stored in four different places. The portal just contains links to the native document. Adding to the problem is that I have to replicate the portal directory structure on the file system. So, my app has to replicate the portal folder structure, figure out where the document that is being referenced actually lives and copy it into the new location on the file system. All of that would be fine (somewhat) if it were for how Windows handles path definitions. Because the portal didn't care how long a path might wind up being it let people create folder structures that stretched over twenty levels deep with folder and file names that were hundreds of characters long. Of course when I try to recreate this on a file system Windows barfs all over it. Or, to be more precise, .NET barfs all over it. In some way Windows can deal with the long path, but .NET can't at all. I say that Windows can deal with it in some ways because the reality is that it's very spotty in its handling of it. You can navigate through the folders. You can open the documents. You can even move the folders around as long as it is on the same drive. If you try to delete something or move it to a new disk then Windows starts barfing on it. There are .NET tricks to getting around these things so that you can build these offending folder structures, but it's not all peaches and cream. Copying from one location to another can apparently only be done if the source does not have the "long path" designator in front of it. Dynamically created shortcuts appear to vomit all over the long path issue no matter what I try. I even tried creating the shortcut in a path-friendly location and then copying it over to the final, long-path location but it doesn't seem to like that. To make matters worse, the methods you use for long paths from .NET are actually calls to the core Windows API. They apparently didn't write any useful error/debug messages into this API because all of the methods either succeed or fail with no explanation of the problem. It's not like a specific exception gets raised that you can work with to trace down the problem. No, the method just doesn't work and continues happily on. I'm left totally in the dark as to what the heck the actual problem is. It's driving me nuts. I've spent the last six days beating my head against these problems and they currently are only sort-of resolved. I think I'm about ready to say screw the whole thing. This is the best you're getting; deal with it and shut-up!
Showing posts with label Programming. Show all posts
Showing posts with label Programming. Show all posts
Thursday, August 21, 2008
Stupid Windows Long Path Names
I'm so !@#$ frustrated right now. I've been working on a program to export documents out of our portal and onto a file system. This is enough of a pain in the neck as it is because the documents are stored in four different places. The portal just contains links to the native document. Adding to the problem is that I have to replicate the portal directory structure on the file system. So, my app has to replicate the portal folder structure, figure out where the document that is being referenced actually lives and copy it into the new location on the file system. All of that would be fine (somewhat) if it were for how Windows handles path definitions. Because the portal didn't care how long a path might wind up being it let people create folder structures that stretched over twenty levels deep with folder and file names that were hundreds of characters long. Of course when I try to recreate this on a file system Windows barfs all over it. Or, to be more precise, .NET barfs all over it. In some way Windows can deal with the long path, but .NET can't at all. I say that Windows can deal with it in some ways because the reality is that it's very spotty in its handling of it. You can navigate through the folders. You can open the documents. You can even move the folders around as long as it is on the same drive. If you try to delete something or move it to a new disk then Windows starts barfing on it. There are .NET tricks to getting around these things so that you can build these offending folder structures, but it's not all peaches and cream. Copying from one location to another can apparently only be done if the source does not have the "long path" designator in front of it. Dynamically created shortcuts appear to vomit all over the long path issue no matter what I try. I even tried creating the shortcut in a path-friendly location and then copying it over to the final, long-path location but it doesn't seem to like that. To make matters worse, the methods you use for long paths from .NET are actually calls to the core Windows API. They apparently didn't write any useful error/debug messages into this API because all of the methods either succeed or fail with no explanation of the problem. It's not like a specific exception gets raised that you can work with to trace down the problem. No, the method just doesn't work and continues happily on. I'm left totally in the dark as to what the heck the actual problem is. It's driving me nuts. I've spent the last six days beating my head against these problems and they currently are only sort-of resolved. I think I'm about ready to say screw the whole thing. This is the best you're getting; deal with it and shut-up!
Tuesday, August 19, 2008
Terribly Exciting Day
Terribly exciting day yesterday. Nothing very amazing happened. I worked late and we had IHOP for dinner. Then I was up late watching our friends' kids while they went to the emergency room. It gave me a good excuse to get a lot of reading in, though, so I'm not complaining too much. I'm working on an application to export documents out of our portal onto a file system while recreating the directory structure on the portal. This has caused me to bump into the dreaded path-length issue that I have been skirting during the last three projects. So, I finally have to deal with it. It's rather annoying, actually. I spent all day yesterday writing a class to handle the main file operations we need using p/invoke methods from the Windows API. It's not nearly as much fun as it sounds. The special part of the fun occurs when the method doesn't work for some reason but doesn't bother to give me any debugging error information. It just fails and moves happily along. I'm stuck with a big ol' question mark on my forehead wondering what to do now. I've actually gotten the primary part of the app working, so that's good. I just have to write the code to extract from a secondary source, but that shouldn't be too problematic. Oh well.... back to the grindstone...
Subscribe to:
Posts (Atom)