I have been looking into file commanders that can handle very long file names due to the need to get the correct properties info form "selected" Files/Folders;same as windows [Alt+Enter]; from folders with very long file paths (up to 300ch). Windows explorer API has 259ch limit and always gives different results depending where you apply the command within the subfolders.
My decision to purchase DO rests solelly on this issue. I recently sent an email to your sales department for the inquiry but they referred me to the forum thinking I had a technical issue.
I guess a developer is the only person really qualified for my question.
Can DO correctly count folder/file size and quantity where there are very long path names while having a similar UI to windows?
I am aware of all the issues with long file path/names & how different OS's behave with them.
I would appreciate a clear cut answer and no advice about shortening the paths, that is not an option.
Thank you.
We aim to make the core parts of Opus work with very long paths so that you can at least enter them and move/rename things around.
We cannot make everything work with very long paths due to limitations of APIs and libraries that are not always within our control.
If you need to know if a particular aspect works with your scenario, the best thing is to try it out using the free trial version.
Note that the Properties dialog will be the same in Opus as it's the same dialog that comes from Windows. But Opus can calculate and display folder sizes and and file/size counts in columns that are displayed in the File Display itself (without opening any extra dialog), and those are calculated using our own code.
I think that code handles arbitrary path lengths, but you should test it with your scenario if it's the deciding factor for you. If you find it doesn't work, please let us know the details (e.g. the paths and folder structure involved) and we can look into fixing that, as it should work.
Thanks for the prompt reply.
My need, as you mentioned, is only about simple move/copy, open/delete Etc. No need for other software API's.
I understand your file count method and view is similar to Total Commander; I couldn't get it to view the way I needed; so I started looking at other software, which brought me here.
To clarify, what I need is the result of the count to remain persistantly viewable, even when I move away from the original selection.
Most "commanders/listers" folder sizes are within the panes and change ounce you select anything else. Their results are mostly for individual items, while I need the compounded result of all items I selected.
Can DO do that without having to delve into Add-ons and scripts?
I will test OP with my folder structures and see if I can set it up to meet my requirements.
I posted the question to you because I did not want to waist time doinf futile testing when i knew a developper could easly answer the most pertenant issues
(the ~ prefixes are due to the sizes being approximate, which happens while the calculation is still ongoing and, as in this case, if some of the child folders cannot be accessed due to permissions.)
Yep, that is what I am used to seeing. I will still give OP a try.
Thanks for all the feedback, Really appreciate it.
As a final question and suggestion; seeing as the Windows Properties command or [Alt+Enter] can get the Size/Count wrong with long File path issues & Microsoft has no clear info about updating there API regardless of there new longPath enabler method in new Win 10 Builds; do you guys have it in the pipeline to write a Replacement Function/Command or New UI window that does the correct count?
You could write a script add-in which shows a dialog with file and folder counts if you wanted it in a dialog instead of the main file display for some reason.
The standard Properties dialogs show a lot of other things, and are something other software can hook into and extend, so they can't really be replaced, but individual aspects of them (like the size/item counts) are easy enough to reproduce via scripts.
The issue with the counts being wrong in the standard Properties dialogs is quite well known now so I am hoping Microsoft will fix it soon, but who knows with how that company is run these days.
Ouch Leo. I couldn't write a script to save my life! My work never required me to delve into any type of coding, even the simplest ones. I have a few friends that could possibly do the Job.
But i will reiterate, scince your program mainly deals with file manipulation & the long file path issue is not a commun problem that even many Techy's and most standard users are aware of. As such anyone who might suspect that they are getting incorrect info when they inadvertently working with LPN will most likely blame OP for being buggy ( or and other similar software) instead of knowing the problem lies with Microsoft's API.
Just something for you to consider in Future Versions of OP, or we can all just wait for Microsoft to do something about it ( Shaking my head right now)!
I will get back to you with my results after I get through with my testing.
Thanks again!
