Tracker issue: Drag and Drop.

[shymega]

Due to the numerous issues created, without any sign of checking for duplicate issues, I have taken this opportunity to close those issues about drag and drop not working in favour of a centralised tracking issue.

Please only comment on this issue with constructive and positive messages that will facilitate the development and maintenance of drag and drop support. Unconstructive messages will be removed if they do not fit the discussion. Reacting to messages is fine, however, as it indicates the general feeling towards construction and maintenance of drag and drop.

Thank you 😄

[shymega]

On the note of reactions, could those with this issue, please react to this comment with 👍 (:+1). Thanks. This will allow us to gauge the spread of the issue.

[chrishultberg]

Using Ubuntu 18.04.3 LTS as the server and Windows 10 Pro as the client, I can not drag and drop files.
This also means that I can't copy/paste the files...

Doesn't seem like there's been an update to this in a few weeks so I wanted to double-check.

[shymega]

You don't need to double-check. If the issue hasn't been updated, please assume nothing has changed. Which it hasn't. I only say this so the tracker issue doesn't get "noisy" with comments asking if there's been any progress etc....

[arthur-tacca]

Personally, I would prefer a file transfer that was very clunky (even just pasting the source and destination filenames into text boxes) but worked, rather than something with a smooth interface (like drag and drop) but is unreliable. This is especially the case with Linux - I don't believe drag and drop is even intended to work on Linux but Linux-Windows is my primary use case, so anything at all would be a great help with that.

(Apologies for commenting on this high-activity thread but I think this is genuinely new content. Those that agree/disagree with my preference had add their reactions accordingly to this comment.)

[shymega]

All - this is a tracking issue for the development of this feature. Please only comment constructively. I'm going to delete those comments that merely post logs etc of the current behaviour. I recognise my decision may be controversial, but we really need to keep the issue constructive. Thank you.

[shymega]

Personally, I would prefer a file transfer that was very clunky (even just pasting the source and destination filenames into text boxes) but worked, rather than something with a smooth interface (like drag and drop) but is unreliable. This is especially the case with Linux - I don't believe drag and drop is even intended to work on Linux but Linux-Windows is my primary use case, so anything at all would be a great help with that.

(Apologies for commenting on this high-activity thread but I think this is genuinely new content. Those that agree/disagree with my preference had add their reactions accordingly to this comment.)

By the way, I know this is a late reply, but thank you for your comment - I think we should bear this in mind for the implementation, as and when. Definitely valuable content, thank you!

[baldyman01]

Drag and drop does not work at all on Ubuntu 20.04. If this is the central tracking issue for drag and drop and the last actual status update was "If the issue hasn't been updated, please assume nothing has changed. Which it hasn't." and this was back in Sept 2020, can we now assume that this feature will never happen and is being removed from the feature list of the program?

[shymega]

No, it will happen, but we just don't have enough devs or manpower yet. Again, assume nothing has changed...

[mblend27]

How can I help make this happen? I have $ and don't like any other software out there. If me throwing $ at you isnt constructive... del this ;)

[shymega]

Still no update, but we will consider the suggestion of monetary contributions towards the goal. I don't think it will be a straightforward fix, however, and we have a fair few critical issues to go through.

[chloelcdev]

First off as a side note I find it odd that this was merged with the clipboard issues.

I'm running Macmini 9,1 with macOS 11.6 (20G165) for the client, Windows 10 Pro 10.0.19043 Build 19043 as the server, and the clipboard will only successfully copy from client to server, but never from server to client. The client logs do note that the clipboard was updated (though only sometimes, and there are two prints) but it seems the clipboard is only cleared when this happens.

[Zeratoxx]

Did not see a comment about the log message, so here it is:

[2021-12-13T17:00:46] ERROR: failed to get drag file name from OLE

[retX0]

I just got ERROR: failed to get drop target with version 2.4.0

[JoshQuake]

Drag and drop has never worked for me since install over a year ago.

ERROR: failed to get desktop path, no drop target available, error=2

Host: Windows 10 20H2 19042.1415
Client: Windows 10 v2004 19041.1348

Barrier version currently 2.3.3. I will update and test again.

UPDATE: Updated to 2.4.0 on both machines. No longer receive the above, but I now receive

[2022-01-05T17:31:24] ERROR: failed to get drag file name from OLE

[ElJuky]

Tests on Barrier 2.4.0.1, used on two Windows 10 and command line exclusively :
With no admin rights, drag and drop of files is ok (I've added the --drop-dir and --enabled-drag-drop parameters of course)
With admin rights, the message "failed to get drag file name from OLE" is displayed

Copy/paste of files not working. Don't know if it's normal. I check the content of clipboards and I see an entry "BarrierOwnership" on the computer that waiting to paste the file.
Thank you for this software !

[jmrenouard]

Hi,

This issue is still present in 2.4.0
Changing setting Elevate to As needed on the server side solves this issue

But iI don't figure it out why this is impacting copy/paste feature

Thanks for this great piece of software, Barrier is awesome !

Jean-Marie

[shymega]

First off as a side note I find it odd that this was merged with the clipboard issues.

I'm running Macmini 9,1 with macOS 11.6 (20G165) for the client, Windows 10 Pro 10.0.19043 Build 19043 as the server, and the clipboard will only successfully copy from client to server, but never from server to client. The client logs do note that the clipboard was updated (though only sometimes, and there are two prints) but it seems the clipboard is only cleared when this happens.

Yes, the main reason I merged it with them is because of the similar mechanic, and I thought at the time it would be solved with the same fix. But I'm not with the Barrier project now - so I can't change this. I've been meaning to reply to your side note, so I hope this explains my reasoning.

[Sollace]

Hi,

This issue is still present in 2.4.0 Changing setting Elevate to As needed on the server side solves this issue

But iI don't figure it out why this is impacting copy/paste feature

Thanks for this great piece of software, Barrier is awesome !

Jean-Marie

Having the same issue on 2.4.0 where both drag-n-drop and clipboard sharing is not working, however when I check I see Elevate is set to As Needed on both the client and server, so I'm thinking it could be something else entirely.

Also for context, my setup is Window 10 to Windows 10, with SSL disabled (because I couldn't get it working with).

[Sollace]

One thing that I notice, which is weird... I can drag a file, but then as soon as I move the cursor to the other screen, the drag is cancelled on the server's side (and the log window closes, for some reason).

Just taking a guess here, but you don't think the drag is being cancelled before Barrier gets notified, and so it ends up trying to read a file drag with no file (hence the "failed to get drag file name from OLE" message)? So maybe the thing to look at is what is causing Windows Explorer to cancel the drag operation prematurely?

[ksdavidc]

I think I may have a hint as to what is happening.

My journey:
first: I am working on 3 macs, 2 of them updated to monterey, one high sierra. server is monterey, others client. will post config details in a second.

Behavior:
Drag and drop fails when I reach the edge of the screen. The mouse moves to the other screen, but the operation fails. In addition, I am now stuck in the second machine (can't return) and have to reload to return.
configuration
server

Client: auto config

unrelated note: I couldn't actually get barrier to run initially on the clients until I disabled SSL, which is a bug.

HOWEVER:

I am now finding that if I double tap I can get through with the file seemingly still attached to the cursor, but dropping in finder fails. no file appears, but

I try AGAIN and it seems to work.

I realize that it worked because this time perhaps somehow I did not trigger something in my menu bar (autohidden) by etnering at a different location. I am entering via the bottom of server into top of client and hitting the menubar/file menu. Or maybe just the file was different, or the folder i dragged into.bar

See if I can reproduce:
turning off autohide on client. not quite helping. still triggering finder menu or menubar actions.
reconfiguring client to the right of server.

YAY, I think I figured it out!! If I make sure that when I drag out of the finder and over the desktop, not another application, then when I enter the client I can drop, as long as I don't have anything selected in the corresponding finder and i am not meeting other parts of the GUI. I roughly tested again, and double tap seems to be necessary as well.

Of course this isn't thorough test, and my diagnosis is probably off, but I think it does give a hint as to what might be happening.

Logs attached
Logs.txt.zip

PS Barrier is really awesome. I just went to a 3 computer setup and being able to have only one set of mouse, keyboard and trackpad (partial...some gestures not working) on the table is great!!

[ksdavidc]

forgot the client logs, which show at ton of these: related?? I don't understand logspeak.
2022-04-27 03:15:36.096 barrierc[3666:562066] pid(3666)/euid(501) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!

clientlogs.txt
.

[jhay06]

does anyone fix this issue ? , i have mac os server and windows 10 client , but cannot drag and drop as well

[dimyself]

I'm also having this issue :(

I'm trying to copy/paste and drag/drop from Arch linux <-> Arch linux

I can provide logs if needed.

Basically, when I try to drag a file, the cursor just stops at the edge of the screen.

The log is saying:

"try to leave "pc" on the right"
"locked by mouse buttonID: 0"
"locked to screen"

Thank you!

[mood128]

Any update on this?

[HobbitSlayer]

Getting this error when trying to drag n drop a large file. Server running on MacOS 12.4, client on Windows 10 Pro.
[sandbox] Failed to get a sandbox extension

[DSDev-NickHogle]

Hi,
This issue is still present in 2.4.0 Changing setting Elevate to As needed on the server side solves this issue
But iI don't figure it out why this is impacting copy/paste feature
Thanks for this great piece of software, Barrier is awesome !
Jean-Marie

Having the same issue on 2.4.0 where both drag-n-drop and clipboard sharing is not working, however when I check I see Elevate is set to As Needed on both the client and server, so I'm thinking it could be something else entirely.

Also for context, my setup is Window 10 to Windows 10, with SSL disabled (because I couldn't get it working with).

@shymega: I am also experiencing this issue, and I did a pretty deep dive into it. I suspect it may have something to do with barrierd.exe being run as a Windows Service. In MSWindowsWatchdog.cpp, the activeDesktopName() function is returning an empty string. I added hooks to get the error code, and the failure happens when here, when calling OpenInputDesktop(0, FALSE, GENERIC_READ).

If activeDesktopName() doesn't return the string "Default", then the Watchdog service forces the child process barriers.exe to run with elevated privileges. This results in the process being started as the SYSTEM user, which does not have it's own Desktop directory.

(The call to SHGetFolderPath in MSWindowsScreen.cpp will attempt to get the Desktop folder by expanding %USERPROFILE%\Desktop, which expands to C:\Windows\System32\config\systemprofile\Desktop, which does not exist on my Windows 8.1 machine nor on my Windows 10 machine.)

Some other things I've observed:

• If I run barrierd.exe as a regular user, not as a system service then SHGetFolderPath succeeds, but I have other issues, like it cannot save the LogLevel setting.
• If I check the box Allow service to interact with desktop, in the Services ControlPanel, I still get the same failure in the call to OpenInputDesktop.
• If I call GetError(), after the OpenInputDesktop failure, the error code is 0x1.
• The failure to get desktop path happens on the server machine, which runs barriers.exe. I haven't checked if I am getting the same error message on the client machine ("failed to get desktop path, no drop target available")

Host (Server) machine: Windows 8.1, [Version 6.3.9600]
Client machine: Windows 10, [Version 10.0.19044.1706]

Barrier version v2.1.0.

I hope this helps! I'd love to see Drag & Drop working someday!

[mehdico]

Getting this error when trying to drag n drop a large file. Server running on MacOS 12.4, client on Windows 10 Pro.
[sandbox] Failed to get a sandbox extension

Same with Mac<>Kubuntu

when drag file from Kubuntu to Mac:

INFO: leaving screen

when drag file from Mac to Kubuntu:

2022-07-14 19:12:04.362132+0430 barriers[4775:208114] [sandbox] Failed to get a sandbox extension
[2022-07-14T19:12:04] INFO: switch from "Mehdis-MacBook-Pro.local" to "lbt" at 985,1079
[2022-07-14T19:12:04] INFO: leaving screen
[2022-07-14T19:12:04] WARNING: cursor may not be visible

[shymega]

Hi,
This issue is still present in 2.4.0 Changing setting Elevate to As needed on the server side solves this issue
But iI don't figure it out why this is impacting copy/paste feature
Thanks for this great piece of software, Barrier is awesome !
Jean-Marie

Having the same issue on 2.4.0 where both drag-n-drop and clipboard sharing is not working, however when I check I see Elevate is set to As Needed on both the client and server, so I'm thinking it could be something else entirely.
Also for context, my setup is Window 10 to Windows 10, with SSL disabled (because I couldn't get it working with).

@shymega: I am also experiencing this issue, and I did a pretty deep dive into it. I suspect it may have something to do with barrierd.exe being run as a Windows Service. In MSWindowsWatchdog.cpp, the activeDesktopName() function is returning an empty string. I added hooks to get the error code, and the failure happens when here, when calling OpenInputDesktop(0, FALSE, GENERIC_READ).

If activeDesktopName() doesn't return the string "Default", then the Watchdog service forces the child process barriers.exe to run with elevated privileges. This results in the process being started as the SYSTEM user, which does not have it's own Desktop directory.

(The call to SHGetFolderPath in MSWindowsScreen.cpp will attempt to get the Desktop folder by expanding %USERPROFILE%\Desktop, which expands to C:\Windows\System32\config\systemprofile\Desktop, which does not exist on my Windows 8.1 machine nor on my Windows 10 machine.)

Some other things I've observed:

• If I run barrierd.exe as a regular user, not as a system service then SHGetFolderPath succeeds, but I have other issues, like it cannot save the LogLevel setting.
• If I check the box Allow service to interact with desktop, in the Services ControlPanel, I still get the same failure in the call to OpenInputDesktop.
• If I call GetError(), after the OpenInputDesktop failure, the error code is 0x1.
• The failure to get desktop path happens on the server machine, which runs barriers.exe. I haven't checked if I am getting the same error message on the client machine ("failed to get desktop path, no drop target available")

Host (Server) machine: Windows 8.1, [Version 6.3.9600] Client machine: Windows 10, [Version 10.0.19044.1706]

Barrier version v2.1.0.

I hope this helps! I'd love to see Drag & Drop working someday!

Thanks for the input, but I'm no longer involved with Barrier. I gave up. Now forked to Input Leap and my own hybrid KVM. I am no longer subscribed to this issue either, so I'm afraid you're on your own...

[RainOfPain125]

sad that development for the only working open-source virtual KVM has been abandoned. I got the same problem, can't drag/drop files. If I could copy paste files I wouldn't care, but copy paste only works with text and etc, not files.

[mirh]

Development is still going on...
https://github.com/input-leap/input-leap

[RainOfPain125]

Development is still going on... https://github.com/input-leap/input-leap

um... If it was being developed then it would be great if the lads could make a download for it haha

[shymega]

There are CI artifacts still being generated, but we have a lot of Barrier references and copyright headers to be updated. You can access the artifacts via GH Actions. Tags still exist, and if you check them out in a local Git clone, you'll be able to build.

[joseveland]

I got a solution to this problem by:

I just untrust graphical interfaces (barrier.exe) so i went directly to run the client/server binaries at "C:\Program Files\Barrier"

1. But at first i used the GUI "barrier.exe" to test the mouse/keyboar etc.. finally i saved this "server configuration" (myhome.sgc) on the SERVER computer (Menu : Barrier --> Save configuration). NOTICE this .scg file JUST save the server config i mean the screens and stuff so the CLIENT doesn't need that or even use this (i actually checked on its --help)
2. I started task manager and closed the daemon (barrierd.exe) first and other binaries (barrierXxxx.exe) after, just to stop everything running on both computers.
3. I started a powershell (cmd should work too) console on both computers under the path "C:\Program Files\Barrier"
4. I run the binaries "barriers.exe" on the SERVER computer and also the "barrierc.exe" on the CLIENT computer with the followed arguments: (NOTICE the file "myhome.sgc" is used and 192.168.1.100 was the IP address of my SERVER computer where the CLIENT points on its command execution):

• .\barriers.exe --config ....\Users\josem\Documents\Barrier\myhome.sgc --disable-client-cert-checking --disable-crypto --enable-drag-drop
• .\barrierc.exe --enable-drag-drop --disable-crypto 192.168.1.100

Ta Da .. I dragged and dropped files from one computer to another and the result was, the files were copied on the "Desktop" of the other computer always (as the binaries also said in the logs), so worked beautifly

For you dev guys:

I came up with this solution after digging a little bit on the github source code using "grep -rne Xxx" search and "nano ...." to look further on the files (Actually using windows on its ubuntu WSL2 support and some "apt install nano")

I realize the error was a problem about not having a "filename = m_dropTarget->getDraggingFilename()" (src/lib/platform/MSWindowsScreen.cpp) which derived from another portion of code at the beggining of the execution of these binaries because where i wasn't reading a message "drag and drop enabled" (src/lib/barrier/App.cpp) when using F2 logging (Menu : Barrier --> Show log) on the GUI binary (barrier.exe)

So as you saw, i add these argument manually on the barriec.exe and barriers.exe binaries (--enable-drag-drop) with a little "--help" reading on each one of them to see the right flag to enable.

[shymega]

@joseveland I was pointed to your comment on the new fork's tracker.

Might be a good idea to post your solution on the Wiki as a PR? https://github.com/input-leap/wiki-prs

Barrier doesn't seem maintained anymore.

Thanks.