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!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!
Subscribe to:
Post Comments (Atom)
4 comments:
I don't know whether or not this will help, but I have a few suggestions.
* Try using the \\?\ prefix when naming the path (e.g., "\\?\C:\Users\Jerry\Some\insanely\long\path name\Blah blah blah.txt").
* If that doesn't work, try using the Unicode versions of the Windows API functions directly along with the \\?\ prefix. (I doubt this would help, but it's worth a shot.)
* If that doesn't work, try using GetShortPathName to help you handle the path.
Like I said, I don't know for sure that these would help.
In other news ... Hi, Jerry!
I've done the \\?\ and going directly at the Windows API functions. Some of the Windows API methods handle it completely, some do not. It's kind of a mixed bag. Also, switching things to short path versions unfortunately doesn't work because the end users are lawyers who never abbreviate anything and can't handle it if we do. I had an idea that maybe I would save everything in a flat file structure and then just have an index.html file that has the full structure represented.
You may have misunderstood the GetShortPathName thing. You'd only use the short path name internally to avoid the path length problems. For example, say you need to put files in "C:\A really long folder name\Another really long folder name\Wow is this long", and imagine that that path length is too long. You could break it down into the component directories and create each individually, using short path names whenever possible. You'd first create "C:\A really long folder name", then "C:\AREALL~1\Another really long folder name", then "C:\AREALL~1\ANOTHE~1\Wow is this long", then you'd write files into "C:\AREALL~1\ANOTHE~1\WOWIST~1" (of course, you'd be asking the system for those short folder names to construct these).
If you used this in conjunction with the \\?\ approach, you might get closer, though because I don't know what Windows is doing behind the scenes, and I don't know what other operations you might have to do, it might not be close enough. (Some file systems may have short file names disabled, so they'd be screwed anyway.)
Ohhh.... You're right, I did misunderstand what that function did. I will have to try it out. I think I have them at a point where it's close enough (a.k.a. I'm sick of working on it and they're happy enough) but I will give that function a try. Thanks for the tip.
Post a Comment