[FileVoyager (Author)]

PIDLs are generally faster than string paths, and they also provide capabilities that paths simply don’t. In particular, PIDLs allow navigation within the Windows Shell namespace (e.g., Desktop, This PC, Libraries), which aren’t always backed by real filesystem paths. String paths, by contrast, are limited to actual files and folders.

Regarding the slowdown when browsing network locations, this appears to be related to how Windows handles network discovery rather than anything specific to FileVoyager.

For example, navigating directly to a UNC path (like \\server\share) without opening the tree view is typically very fast. However, when the tree view is opened for the first time, FileVoyager asks the system to enumerate all network locations. At that point, Windows may trigger network discovery and attempt to enumerate available resources, which can take noticeable time (around 10-15 seconds in my tests).

This delay seems to come from the operating system’s network enumeration process, not from FileVoyager itself. In more controlled environments, such as professional networks with properly configured discovery or mapped resources, this slowdown is usually not observed.

[FileVoyager (Author)]

I already plan on working on the default action on Copies/Moves for this upcoming release.

The point with the “report” tracking of copied/moved items (or not) will be planned for later

[FileVoyager (Author)]

Hi,

The issue “Preview in taskbar showing ghost copy/move window” has been fixed.

The problem was caused by the popup windows involved. They were implemented as full-fledged forms (borderstyle=sizable or dialog, with minimize, restore, and maximize buttons in the title bar). When closed, these forms were not destroyed but simply hidden.

Because of this, the Desktop Window Manager (DWM) treated them as independent windows, making them eligible for taskbar previews. It also appears that DWM does not properly react when such windows are merely hidden.

I had 2 options to fix it:

• Convert their BorderStyle to SizeToolWindow or ToolWindow
• Destroy/free the windows on closure

By converting these windows to ToolWindows (or SizeToolWindows), the issue disappears. In this configuration, DWM considers them as dependent “slave” windows of the main form, and therefore excludes them from taskbar previews.

For the lightweight windows, I opted for destruction/freeing on closure, as those windows are not computing-power-demanding when (re)created.

The improvement will be part of this month’s release

[FileVoyager (Author)]

Hi all,

I implemented the saving of some key properties immediately after there are modified.

Will be included in this month’s release

[FileVoyager (Author)]

Thanks for the additional investigation.

I’ve experienced this issue once on my side as well, but it never happened again.

I’m still trying to identify a pattern. In my case, it occurred after unplugging a phone connected via USB, but I haven’t been able to reproduce it since.

Quite frustrating…

[FileVoyager (Author)]

Hi HomeBoy,

I recently improved support for very long paths in FileVoyager. There may still be cases that are not handled properly, but in most situations this is due to limitations of Windows itself. File Explorer exhibits the same issues for the same reasons.

Regarding the specific case in this Topic, I tested using extremely long paths created for stress testing, and everything worked correctly.

The key point is that FileVoyager does not rely on plain text paths. Instead, it uses Item ID Lists (aka PIDLs), which are binary structures used by the Windows Shell to identify objects.

A PIDL represents a path as a sequence of linked identifiers rather than a single string. Because of this, it avoids many of the traditional MAX_PATH limitations associated with text-based paths. In practice, PIDLs allow handling much longer paths than standard string-based approaches.

[FileVoyager (Author)]

Hi,
I will start by saving regularily (on idle)
Added to my backlog

[FileVoyager (Author)]

This improvement will be part of the next release (End April 2026)

[FileVoyager (Author)]

Hi HomeBoy,

The reason of the symptoms you described is that the Tree doesn’t show the hierarchy for ‘non-shell’ items like the \\ServerName\…
After your message and checking the reasons, I decided to proceed like File Explorer and thus, to ‘inject’ non-shell nodes until the shell takes over again.
Was needed for the \\ServerName\ and the for the root drive \c$\ or any other root. After that, the shell takes over again.
This is what it looks to on my Dev version:

[FileVoyager (Author)]

Hi HomeBoy,
(I moved your post from Issues and Bug to Feature Requests)

• add an option in the copy/move window to choose a default action.
  • Already in my backlog but lost from sight. I higher its prio.
• Preview in taskbar showing ghost copy/move window.
  • I put a ticket in my backlog but honestly, I don’t even see how I can fix that. Windows handles the preview itself. I will see…
• Keep track of files manipulated
  • This is also a feature I wanted, mainly to make an “undo” possible. But your use case is also inspiring. Ticket in my backlog

Thank you for the valuable input

[FileVoyager (Author)]

Hi HomeBoy,

Yes bug confirmed. I put it in my backlog.

Thank you for reporting

[FileVoyager (Author)]

Hi,

What you describe is exactly how FileVoyager’s Create Item is supposed to behave.
This is how it should look:

This means that something goes wrong when FileVoyager tries to load your registry’s Shellnew entries.

[FileVoyager (Author)]

Hi Benjamin,

Thanks for the ini and the portable test. In your ini, I remark the absence of the [RoorPaths] section. Can we make a test by adding in your ini the following ?

[RootPaths]
CheminLV1-1=#20#0#31#80#224#79#208#32#234#58#105#16#162#216#8#0#43#48#48#157#0#0
CheminLV2-1=#20#0#31#80#224#79#208#32#234#58#105#16#162#216#8#0#43#48#48#157#0#0

To do so,

1. close FileVoyager
2. add the above section in your ini file
3. then open FileVoyager (both panels should display your ‘This PC’ virtual folder)
4. when it’s fully open, close it. and let me know if the error occurs again

[FileVoyager (Author)]

Hi Benjamin,

Is if the x86 or x64 version that you are running ?
Setup or Portable ?
Also, would you share your ini file with me ? It would help me see what’s the last value saved and maybe figure out what fails to be saved in it. If you have installed the Setup version, the ini file should be in the following path: %AppData%\FileVoyager\Ini\FileVoyager.ini

In the mean time, what you could also do is to install a Portable version of FileVoyager and see if it behaves better.

[FileVoyager (Author)]

Thanks for the feedback and happy it’s working fine.

[Author]

Posts