cut = copy

[view]

Hi,
In everything 1.5, when moving a file, the original file remains in the previous folder, just like when copying.
What could be the reason for this?

[horst.epp]

No delete rights on the source folder ?

[view]

no I don't think, manually I can delete (inside everything)

[void]

Thank you for the issue report view,

How are you moving the file?
For example: Ctrl + X, Ctrl + V or drag drop or Edit -> Move to folder?

Does the file get moved and Everything doesn't detect the old file being deleted? (can you open the old file?)
-Please make sure Index -> Update Indexes is checked.

Debug logs might help:

• In Everything 1.5, from the Tools menu, under the Debug submenu, click Start Debug Logging....
• Move a file in Everything.
• From the Tools menu, under the Debug submenu, click Stop Debug Logging....
  ---This will open your %TEMP%\Everything Debug Log.txt in Notepad.
• Please reply with the contents of this file or create a [/rurl=/bugreport]bug report[/rurl] with this file attached.

[view]

How are you moving the file?
For example: Ctrl + X, Ctrl + V or drag drop or Edit -> Move to folder

Ctrl + X in Everything, Ctrl + V in Explorer

Does the file get moved and Everything doesn't detect the old file being deleted? (can you open the old file?)

In Everything I see the copied file in new and old directory, I still can open in the old directory (and in the new too), the file in the old folder remains selected; when I move the moved file back to the old folder in Explorer, I am asked if I want to replace tor rename.

[void]

2024-11-09 23:45:04.647: Everything: 1.5.0.1383a (x64)
2024-11-09 23:45:04.647: OS: Windows NT 10.0 19045 (x64)
2024-11-09 23:45:04.647: Admin: 1
...
2024-11-09 23:45:08.090: CUT isviewing 0 0
2024-11-09 23:45:08.091: iscut 1
2024-11-09 23:45:08.091: ghost selection
2024-11-09 23:45:08.091: viewing 0 0
2024-11-09 23:45:08.091: on clipboard changed 0 1630 1636 1
2024-11-09 23:45:08.091: is cut done

Everything sees the cut.
Looks like Windows Explorer is performing a copy-paste instead of a cut-paste.

There might be a permission issue.
Although, I have not been able to reproduce the issue..

Please try running Everything as a standard user and see if the issue persists:

• In Everything, from the Tools menu, click Options.
• Click the General tab on the left.
• Check Store settings and data in %APPDATA%\Everything.
• Uncheck Run as administrator.
• Check Everything Service. (Please make sure this is tick-checked and not square-checked)
• Click OK.
• Exit Everything (from the File menu, click Exit).
• Restart Everything.

What is the path of the file being cut? what is the path of the paste destination?

[view]

Unfortunately nothing has changed with the service...

What is the path of the file being cut? what is the path of the paste destination?

From Y:\A1t\ to Y:\11test\, It is a veracrypt volume

Background: I have been working with 1.4 for both my PC and the Veracrypt volume, but this version started at some point (or I only noticed it then) to show (empty) files from the disconnected Veracrypt volume, which I don't want. I tried to work with version 1.4 with 2 different databases, one installed, the other portable, but they don't seem to be independent.
1.4 and 1.5 work well in parallel, but unfortunately with the problem above...

[Xadro]

I'm glad that I'm not the only one with this problem.

What still works for me is dragging the file from Everything to an explorer window, that still moves a file. But both Ctrl + X and the Cut option from the right mouse click menu only copies.

Oh and Edit -> Move to Folder also works as it should.

I'm using Version 1.5.0.1383a (x64)

Edit: I ran 1.4 Portable without changing any settings and it had no problems.

I also closed 1.5a and then ran the Portable version of 1.5a and it had the same problem as my installed version of 1.5a has.

[jimspoon]

Not to hijack thread, but when I saw this post I thought I'd try it:

Select some files in Everything.
Press Ctrl+X
Move focus to a file contained in a different folder.
Press Ctrl+V.
Sure enough the cut files were moved to the folder containing the focused file.

I didn't know we could do that! Very useful.

[void]

I haven't been able to reproduce the issue with Veracrypt on my end.

Edit: I ran 1.4 Portable without changing any settings and it had no problems.

The only difference between 1.4 and 1.5 is Everything 1.5 also adds a Shell IDList Array to the clipboard.
Maybe this is causing troubles..

I will add an option to disable Shell IDList Array for the next alpha update.
I will report back once this is ready for testing.

CIDA
ClipSpy

[void]

Does the issue persist if you enable clipboard_simple_pidl:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  simple
• Select: clipboard_simple_pidl
• Set the value to: true
• Click OK.

[Xadro]

Tried it with my installed version and the portable one and no changes the only way to Move a file is to drag it from the Everything window to the Explorer window.

It's quite mystifying because my other PC and Laptop work just fine.

Does the issue persist if you enable clipboard_simple_pidl:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  simple
• Select: clipboard_simple_pidl
• Set the value to: true
• Click OK.

[void]

Everything 1.5.0.1384a adds an option to disable the Shell IDList Array.

The Shell IDList Array is a list of all the files.
Instead of Filenames, the files are referenced by PIDLs.

To disable the Shell IDList Array:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  shell
• Select: shell_idlist_array
• Set the value to: false
• Click OK.

Disabling will give the same experience as Everything 1.4.
Please note: disabling will force Everything to use simple context menus.
Please let me know if disabling fixes the copy issue.



Everything 1.5.0.1384a will now use the parent folder when possible instead of the desktop when creating the Shell IDList Array.
Everything will continue to use the Desktop folder if items are in different locations.
The Shell IDList Array will now be identical to Windows Explorer.

[Xadro]

Hmm it worked kinda, here is what i tried and what results i got:

Right Click Cut -> Right Click Paste = Copies the file
Right Click Cut -> Ctrl+V = Moves the file
Ctrl+X -> Right Click Paste = Copies the file
Ctrl+X -> Ctrl+V = Moves the file

I have never seen such strange behaviour.

Still since i mostly use keyboard shortcuts i'm quite happy with it, thank you. Just got to remember not to use the context menu when pasting i guess.

Everything 1.5.0.1384a adds an option to disable the Shell IDList Array.

The Shell IDList Array is a list of all the files.
Instead of Filenames, the files are referenced by PIDLs.

To disable the Shell IDList Array:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  shell
• Select: shell_idlist_array
• Set the value to: false
• Click OK.

Disabling will give the same experience as Everything 1.4.
Please note: disabling will force Everything to use simple context menus.
Please let me know if disabling fixes the copy issue.



Everything 1.5.0.1384a will now use the parent folder when possible instead of the desktop when creating the Shell IDList Array.
Everything will continue to use the Desktop folder if items are in different locations.

[ChrisGreaves]

In everything 1.5, when moving a file, the original file remains in the previous folder, just like when copying. What could be the reason for this?

I see the discussion about the possibility of there being a bug in Everything.

But too I remember being fascinated between cut/copy in the early days.

For example, dragging a file-name in Explorer is a move if the drive letter is to remain the same, but is a copy otherwise.

This might give a clue to a bug (anywhere) if for any reason an application is led to believe that the equivalent of a drive letter is seen (by the application) to be identical when it is not really so (effects a MOVE) or vice-versa (effects a COPY).
Cheers, Chris

[void]

Thanks for testing 1384a Xadro,

Hmm it worked kinda, here is what i tried and what results i got:

Right Click Cut -> Right Click Paste = Copies the file
Right Click Cut -> Ctrl+V = Moves the file
Ctrl+X -> Right Click Paste = Copies the file
Ctrl+X -> Ctrl+V = Moves the file

I have never seen such strange behaviour.

Strange indeed.

Do you have a shell extension that is hooking the paste verb?
-Some sort of copying software?

[Xadro]

After some trial and error and far to much time wasted I found out it was Directory Opus v12.12.

I don't how or why but once I shut it down Cut and Paste works as it should again. Even with shell_idlist_array set to true really strange because I barely use Directory Opus let alone update or change settings.

BUT Plot twist, since I was wasting time I just started testing older versions of Everything Portable and this is the result:

Everything-1.5.0.1369a.x64 -> Works
Everything-1.5.0.1372a.x64 -> Works
Everything-1.5.0.1373a.x64 -> Not Work
Everything-1.5.0.1374a.x64 -> Not Work
Everything-1.5.0.1377a.x64 -> Not Work
Everything-1.5.0.1385a.x64 -> Not Work

As you can see between 1.5.0.1372a and 1.5.0.1373a the Cut and Paste stopped working for me, or better said in that update there is something that conflicts with Directory Opus causing it to recognize the Cut command as Copy.

Anyhow thanks for all the help so far even though my problem is isolated and niche

Thanks for testing 1384a Xadro,
Strange indeed.

Do you have a shell extension that is hooking the paste verb?
-Some sort of copying software?

[void]

Everything-1.5.0.1369a.x64 -> Works
Everything-1.5.0.1372a.x64 -> Works
Everything-1.5.0.1373a.x64 -> Not Work
Everything-1.5.0.1374a.x64 -> Not Work
Everything-1.5.0.1377a.x64 -> Not Work
Everything-1.5.0.1385a.x64 -> Not Work

Thank you for testing and report this.

1373a adds support for OleSetClipboard.
OleSetClipboard is an API for detecting pastes in other software when you cut an item in Everything.



Looks like Directory Opus doesn't like my Data Object.
I am probably not implementing an IDataObject API call as they expect.
The next update will use the system data object when all cut files/folders are in the same folder.



Please try disabling oleSetClipboard:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  clipboard
• Select: ole_set_clipboard
• Set the value to: false
• Click OK.

When disabled, Everything will be unable to detect when an Everything-cut item is pasted.

[Xadro]

Yes that completely fixed it.

The downside of disabling oleSetClipboard doesn't affect me as much as cut and paste so this is great, cheers void!

Thank you for testing and report this.

1373a adds support for OleSetClipboard.
OleSetClipboard is an API for detecting pastes in other software when you cut an item in Everything.



Looks like Directory Opus doesn't like my Data Object.
I am probably not implementing an IDataObject API call as they expect.
The next update will use the system data object when all cut files/folders are in the same folder.



Please try disabling oleSetClipboard:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  clipboard
• Select: ole_set_clipboard
• Set the value to: false
• Click OK.

When disabled, Everything will be unable to detect when an Everything-cut item is pasted.

[void]

Everything 1.5.0.1386a will now use the system to create the data object when cutting/copying files/folders from the same location.

Please try re-enabling oleSetClipboard and see if the issue persists with this version.

To re-enable oleSetClipboard:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  clipboard
• Select: ole_set_clipboard
• Set the value to: true
• Click OK.

[Xadro]

Yep that did it, all the ways of cutting/moving a file works as it should now, also with all settings set to default (portable version)

Cheers!

Everything 1.5.0.1386a will now use the system to create the data object when cutting/copying files/folders from the same location.

Please try re-enabling oleSetClipboard and see if the issue persists with this version.

To re-enable oleSetClipboard:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  clipboard
• Select: ole_set_clipboard
• Set the value to: true
• Click OK.

[void]

Thank you for testing 1386a Xadro

[view]

Sorry, I didn't notice the further discussion here, I came back to say that the problem had suddenly been resolved itself, didn't know why.
Now I'm reading here about directory opus, which I use too, I had it upgraded on version 13 in the meantime. Maybe that's why the problems disappeared - anyway, thank you very much for the help here and for the program, which is working perfectly now!

[Xadro]

Sorry for re-opening this topic but it seems its only half fixed, it seems when i select multiple files that are in different locations/paths it will copy instead of cut/move. But when i select any number of files of the same location/path it works as intended.

It works fine when i disable ole_set_clipboard though.

Also on the portable version of Everything-1.5.0.1386a.x64 this problem is not happening.

I'm using Everything-1.5.0.1387a.x64-Setup.exe

[void]

Thank you for your post Xadro,

It's a known issue.

Directory Opus doesn't like Everything's IDataObject (cut files) on the clipboard.



If you cut a single file or files in the same location:
Everything will use the system IDataObject.

If you cut files from different locations:
Everything will use its own IDataObject.

The shell_idlist_array on the clipboard doesn't really support files from different locations.

Fow now, disabling ole_set_clipboard or shell_idlist_array will fix the issue.

I will look into a more permanent fix.

[void]

Everything 1.5.0.1388a improves the shell_idlist_array.

The shell_idlist_array will no longer be created when cutting/copying items from multiple locations.
DOpus should now work with Everything out of the box.
Please try re-enabling ole_set_clipboard and shell_idlist_array.
Please let me know if you have any issues with this version.



This version adds a clipboard_multiple_locations_shell_idlist_array advanced setting.

When enabled, Everything will use a shell_idlist_array when cutting/copying items from multiple locations.

To enable shell_idlist_array when cutting/copying items from multiple locations:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  clipboard
• Select: clipboard_multiple_locations_shell_idlist_array
• Set the value to: true
• Click OK.

When disabled, the system will fallback to a CF_HDROP.



I have made a small change to the shell_idlist_array to use the common parent instead of the desktop.
I am curious to know if this change helps with DOpus when enabling clipboard_multiple_locations_shell_idlist_array.

[Xadro]

With clipboard_multiple_locations_shell_idlist_array & ole_set_clipboard set to true and directory opus running all cut/move operations except dragging turn into copying

UNLESS all files are from the same Path/Folder if they are it all works fine

With clipboard_multiple_locations_shell_idlist_array set to false and ole_set_clipboard set to true

It works as it should when using shortcuts ctrl+x ctrl+v but not when using the right click context menu Cut -> Paste

UNLESS all files are from the same Path/Folder if they are it all works fine

[void]

Thank you for testing 1388a Xadro,



Everything 1.5.0.1389a fixes a crash when right clicking multiple items from different locations.

Dragging from Everything should now work with DOpus.



Everything 1.5.0.1389a adds a drag_drop_multiple_locations_shell_idlist_array advanced setting.

When enabled, Everything will use a shell_idlist_array when dragging items from multiple locations.

To enable shell_idlist_array when cutting/copying items from multiple locations:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  drag
• Select: drag_drop_multiple_locations_shell_idlist_array
• Set the value to: true
• Click OK.

When disabled, the system will fallback to a CF_HDROP.



Does the issue persist with right click -> Cut/Copy from Everything in this version?

[Xadro]

With clipboard_multiple_locations_shell_idlist_array & drag_drop_multiple_locations_shell_idlist_array Set to True and ole_set_clipboard set to False all forms of Cutting/Moving works as it should in both Explorer and Directory Opus v12.12

Thank you very much

[void]

Thank you for testing 1389a Xadro,

I will likely revert drag_drop_multiple_locations_shell_idlist_array as it's causing other issues with drag images.
I am exploring other methods.

I've noticed Everything 1.4 uses a shell_idlist_array when drag dropping.
Does the drag issue occur with Everything 1.4?

[Xadro]

No troubles with 1.4 at all, at least in the portable version