Physically remove bug: Ignoring selected files

[giveortake]

Hi there, awesome work on the latest build thank you! I have noticed a bug though with the permanently delete behaviour, when I have several tracks in the playlist, if I select all then REM Remove... Physically remove selected files : only the loaded track is deleted not the other ones in the playlist.
I tried to overide default wacup remove file and the other options in the More Option of file removal to no effect.
This worked perfectly before v1.99.12.18980 and is still broken in v1.99.13.19100, has anyone experienced this?

[dro]

No one's reported it so I wasn't aware its broken. Are you doing this in the main playlist or the library playlist views ?

-dro

[dro]

I've tried out the main playlist & library playlist actions with the current 19100 build & it's removing things in the manner I'd expect (i.e. the playlist item is removed & the actual files appear in the recycle bin per the default settings to do that for physically removed files). Really could do with clarification on where in the ui you're trying to do the remove action.

-dro

[giveortake]

Hi there, sorry for the delay. So it happens from the "Playlist Editor" using the REM. Remove... and Physically Remove Selected Files. It only removes the track highlighted in White not the selected ones from the drive, the playlist is emptied though. The files are located on a different physical drive than the installation drive.Happy to send any logs that could help you.

Update:
just did a test on the same drive and the behaviour is correct! So it looks like it's related to path. The drive containing the files doesn't have weird characters or long path.

Update 2:
Same issue with a network drive, so it seems to only work with deletion on the same drive (at least on my side).

[dro]

The drive location doesn't seem to be directly the reason & is something I'd messed up during some code consolidation causing what's passed to the OS api used to not behave as expected if the length of the filepath string for any items after the first item attempted to be removed is shorter than it.

For what I could replicate once I'd realised that (being on another drive just seemed to be a more obvious way to help replicate the issue), it should be resolved for when the next build is made available. The library playlists are working ok so it's just limited to the main playlist & at least doing it a file at a time or batch sending to a library playlist & removing from within there is a clunky but viable workaround for it.

-dro