Note! There might be ways to achieve this a lot easier than the one I suggest below, but this is at least one way to solve your problem.
What you can do, is ‘subst’ a temporary drive folder to the root of your path using a Unicode path indicator prefix '\?' (given that all files beneath that path fall below the 260 character limit, otherwise you would have to do it for every path part which risk being longer than 260 characters, but I guess you get the idea). You can read more about the maximum path length limitation at Naming Files, Paths, and Namespaces - Win32 apps | Microsoft Learn.
Here’s a sample of a script which uses ‘subst’ to get into longer paths, which worked on my Win8.1 machine:
subst t: \\?\c:\this\is\the\root\of\my\too\long\path
cd t:
$deleteOlderThan = (Get-Date).AddDays(-14)
Get-ChildItem -File -Recurse | Where { $_.LastWriteTime -lt $deleteOlderThan } | Remote-Item -Force
This should get around the length problem.
Again, this is given that you don’t also have any path below the root which is longer than 260 characters, then you’d have to split it up and remove in batches. Perhaps a relatively simple solution would be to write a script which ‘subst’ into every path, looking for files. This means writing the recursion manually (but shouldn’t be difficult at all), but it should work.
Another solution to the problem would to not use the PowerShell cmdlets for retrieving and removing files and instead using PInvoke, calling into the Win32 APIs using Unicode paths all the time. You have code snippets for such PInvoke code in part two of the bcl team’s three part blog series on long paths at http://blogs.msdn.com/b/bclteam/archive/2007/03/26/long-paths-in-net-part-2-of-3-long-path-workarounds-kim-hamilton.aspx
That blog post series also mentions some things which are important to note regarding working with longer file names. I’ll qoute a couple of paragraphs below:
[...] about security, the \\?\ prefix not only enables long paths; it causes the path to be passed to the file system with minimal modification by the Windows APIs. A consequence is that \\?\ turns off file name normalization performed by Windows APIs, including removing trailing spaces, expanding ‘.’ and ‘..’, converting relative paths into full paths, and so on.
Another concern is inconsistent behavior that would result by exposing long path support. Long paths with the \?\ prefix can be used in most of the file-related Windows APIs, but not all Windows APIs. For example, LoadLibrary, which maps a module into the address of the calling process, fails if the file name is longer than MAX_PATH. So this means MoveFile will let you move a DLL to a location such that its path is longer than 260 characters, but when you try to load the DLL, it would fail. There are similar examples throughout the Windows APIs; some workarounds exist, but they are on a case-by-case basis.
And on why they are reluctant do just allow longer file names on a .NET front before everything in the underlying operating system (Win32 API) supports it:
Other apps may not support this prefix, and may not be able to use these files
Not all Win32 APIs allow this prefix, meaning that the file will not necessarily work with other .NET APIs
- qoute from part 3 in the three part blog post series on http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx