XYplorer Beta Club

I'd like to have a native "Flatten Folder" command in XY. This would simply collect all files in a subtree and move them to the top folder there, deleting the now-empty subfolders.

I admit that this is not often needed, and most users will never have missed it. But some do, and there are these arguments for having it:

#) Flatten is an elemental "file manager" function. Really basic: find and move files. Nothing about their properties or meta-anything.

#) Flatten is not easy to accomplish with scripting. The very competent script I have is complex and still evolving after a year of use. The basic problem is that one must first throw away all knowledge of the nested files, then recreate that info by searching report strings. Special characters cause lots of problems in this.

#) Even when done with scripting, the only practical way to shift big files on external drives is with MoveTo, which invokes RichMove. That's the antithesis of flattening and there is no workaround - at least none that can be described without embarrassment on a site devoted to quality software.

#) XY is already fully equipped to deal with the only issue flatten creates: name collisions. Just include the standard flags for ask / overwrite / increment. No big GUI development, no effect on existing methods, structures, displays etc.

#) Flatten would likely be unique to XY, adding a conceptually simple and obviously useful bullet item to the list of what it can do out of the box.

I flatten thousands of folders, and have to watch XY literally jump through hoops to do each one. It really should and can be much simpler.

Papoulka wrote:#) Flatten is not easy to accomplish with scripting. The very competent script I have is complex and still evolving after a year of use. The basic problem is that one must first throw away all knowledge of the nested files, then recreate that info by searching report strings. Special characters cause lots of problems in this.

actually it's possible with scripting, not easy but possible. in one script i needed to check all subs so made a loop in loop -that could make a list of paths for further move.

I don't know. I never flattened a folder. I do the opposite all the time. I don't see the demand for this. Bloat.

How can you call it bloat? That's a file manager duty!
Personally, I'm with papoulka, there are times when I unpack archives that it would be easier to then gather all the extracted files into the same folder and delete the unnecessary ones, instead of browsing all the subfolders. Just an example.

OK, I don't think anybody would want "overwrite" as an option here, especially since it is unclear which file overwrites which. Same with "ask": again unclear which file would overwrite which unless I design a whole new prompt.

So, "increment" would be the hardcoded way. That way we could add "Flatten Folder" as a one-click GUI function that just does the job without asking questions (and there would be NO undo). Would that be okay? I could do that quite easily.

That would be great! And "increment" is fine for me.

Though just to revisit the options... the XY Move function will already identify which file is about to overwrite another. I guess the term "hard-coded" means you wouldn't be using that function, but working at a lower level.

Thanks

Why not add the original folder name as prefix on collisions?

prino wrote:Why not add the original folder name as prefix on collisions?

That would be an option. (Although there are theoretical limits to it due to Windows filename contraints: max component length = 255 chars).

But is it a good option? I'd say it's only good if applied to ALL or NONE of the files. Otherwise the resulting situation would be rather confusing IMO.

make a conflict resolver dialog?

I prefer this to be a GUI-less feature.

Or I add it as scripting command with flags for options...

Please, do the scripting command with options. That covers all cases, as it can be launched by a user button. In fact I will usually be scripting flatten in with other actions anyway, and in some cases will be glad to have the options.

Thanks!

Done, check it out...

admin wrote:

prino wrote:Why not add the original folder name as prefix on collisions?

That would be an option. (Although there are theoretical limits to it due to Windows filename contraints: max component length = 255 chars).

But is it a good option? I'd say it's only good if applied to ALL or NONE of the files. Otherwise the resulting situation would be rather confusing IMO.

This would be very nice to have. Re: len: the constraint could be easily handled by XY trimming excessive path lengths, right?

Depends how you define "easy". It will be easy for *you* since *I* will have to solve the problem.

The PL/I compiler uses a simple first-four/last-three characters from names that are too long, you could do something similar, with a tweak to set user-defined values?