Curiously, that regexp seems to only work with smaller numbers... for example .{150,} would find anything over 150 characters, but .{200,} fails to find anything, even when they exist. I would posit this has something to do with how x2 internally represents the paths (nikos loves his 8.3 reductions).
Ultimately it's simpler to just use the Characters [S] column, which was essentially designed for this. Double-click on the "Additional Rules" part of the search dialog and create a rule that targets that column and specifies a size-range, looking something like this:
Kilmatead wrote: ↑Ultimately it's simpler to just use the Characters [S] column, which was essentially designed for this.
Designed as a part of x2 or of Windows ? I use xplorer2 1.8.1.4 and Windows 7, and can't find Characters in the list...
Kilmatead wrote: ↑Curiously, that regexp seems to only work with smaller numbers... for example .{150,} would find anything over 150 characters, but .{200,} fails to find anything, even when they exist.
I can't make it work at all, even with .{30,} ... When I have both Files and Folders ticked, it says "The search filter must not be completely unconstrained", and when I untick Folders, it returns every file in the folder regardless of the length of the file name. Is it also because I use an older version?
if you are using the old version 1.8 sadly none of these tricks will work. It had a different regexp engine and far fewer columns. Also the latest version 3.4 supports long filenames so you don't need to bother finding them in the first place
The Characters [S] column was introduced in version 3.0.0.0, for the record.
As the regexp won't work either (even in the newest versions), you might be limited to using some form of scripting (as mentioned previously in this thread).
nikos wrote:so you don't need to bother finding them in the first place
Often the need still arises in order for them to be renamed/shortened in the interests of allowing other programmes to access the same objects, as most 3rd-party software is not intrinsically long-path-aware.
Personally, I'm of the school-of-thought which says if you have long-paths in the first place, you're doing something wrong to begin with... but that's just me. The only time I run into them is when RAR packages are auto-extracted within already deep-folders.
Kilmatead wrote: ↑Personally, I'm of the school-of-thought which says if you have long-paths in the first place, you're doing something wrong to begin with... but that's just me. The only time I run into them is when RAR packages are auto-extracted within already deep-folders.
I mostly have screenshots taken by Firefox add-on Fireshot scattered in many folders all over my drive. The add-on uses the pages' titles as the file names, and I only recently realized that by default, it used up to 256 characters just for the file name! So many of them are very long, and I'm looking to clean that up now.
nikos wrote: ↑
if you are using the old version 1.8 sadly none of these tricks will work. It had a different regexp engine and far fewer columns. Also the latest version 3.4 supports long filenames so you don't need to bother finding them in the first place
Got it, thanks Nikos! I'll try one of the other tools recommended here then.
