It's not common. You aren't supposed to make paths that require more than ~260 characters to express. You can't create them normally. Most programs don't expect it because Windows says you shouldn't do it. It's hard to work with long file paths for the same reason it's hard to make a motorcycle fly to the moon.
Edit:
Actually, here's a more apt comparison. It's hard to use long file paths for the same reason it's hard to buy crystal meth from the grocery store. You might find some store with a secret knock that lets you in a back room where the drug is sold. It won't be true of all stores, and bad things happen when addicts intermingle with normal people.
You're in this mess because some backup program had the bright idea to save directory structures but also append the AppData path in front. With a sensible username, that eats up roughly 40 characters of your 260. So if you had a path that was already pushing the limits, you're in trouble. I'd like to note the original path of that vile is 267 characters long. We can deduce some things from this:
- Adobe After Effects supports long file paths.
- The plugin's installer supports long file paths.
- The plugin's vendor is stupid.
If I noticed something I installed put files at too long a path, I'd file it as a bug. Our product has an installer, and we've had to spend weeks of effort sometimes deciding how to place things so we don't hit the path limit. We *could* make our installer use the workarounds to save things at long paths, but we have to routinely ask our customers to copy files from the directories that would be affected and our support burden would be huge. Also if you're going to write Windows software and sell it you should learn the rules and play by them.
If you're writing the backup program and it's not for sale, consider telling users with these long files to pound sand and fix their machines. I got to do that for one of my tools and it was quite pleasant. Some guy had a path with 800 characters in it because each time it got too long he made a new mapped drive. So we told him his stuff wasn't going to be backed up and the problem solved itself.
If you can't tell users to punt, consider a solution that doesn't use the "rsync" approach. Many backup programs store files in a virtual filesystem. This could be a binary file with some text file describing its contents or perhaps you might consider using Win7's support for true virtual disks. The easiest way to not have to deal with long file paths is to not create them yourself.
OK, rant over. Let's do stuff. My guess about the "Invalid TypeDecl" error is that this line:
... is a C# specific PInvoke syntax. I maintain a C# library with 100+ PInvoke calls and I've never used it, so I don't plan on investigating. Generally PInvoke figures out that kind of stuff; the attributes are for when it gets it wrong.
I made a path like this on my system:
Code:
C:\temp\asdfasdf\asdfasdf\asdfasdf\asdfasdf\asdfasdf\asdfasdf\asdfasdf\
asdfasdf\asdfasdf\asdfasdf\asdfasdf\asdfasdf\asdfasdf\asdfasdf\asdfasdf\asdfasdf\
asdfasdf\asdfasdf\asdfasdf\asdfasdf\asdfasdf\asdfasdf\asdfasdf\asdfasdf\asdfasdf\
longlonglonglongfilename.longextension
That's 272 characters if I counted right. Technically I didn't create the file because I didn't want to bother with mapping a path. So I had to start with putting contents in the file. For that, we need the
CreateFile() API. I didn't want to bother with conversion, so I used
PInvoke.net, something suggested in part 3 of the article and a handy tool for PInvoke.
After a couple of failures where I got my flags mixed up, success! I could go on and try out all the other API methods, but I think between the article, pinvoke.net, and my attached example I think you ought to be able to make some progress. I'm also not super interested because I think the world would be better if people didn't create paths that were longer than Windows allows.
(The example obviously doesn't work as-is because you don't have the directory I created. You can fill in your own long paths to try it out.)
*edit*
Also, pay no heed to "it's a kernel function so you need Administrator permission". Plenty of user-mode functions live in Kernel32.dll. If you needed kernel-mode access to work with files, it'd be impossible to do anything without UAC elevation. You won't generally stumble upon kernel-mode calls in the normal API documentation; that's mainly kept in the driver development docs.
How to resolve the specified path, file name, or both are too long.
Linear Mode
