Closed xeviff closed 2 years ago
WARNING: GVFS: ...
error messages can only happen during drag-n-drop or copy-n-paste. Not sure how to do that with xpra
in the first place since you can't open a File Manager window in the first place.
This error message is possibly misleading. You'll want to play around with it. Delete the log. Try again. See if you can consistently generate this log entry every time you select a file.
Notably, even the GTK File Dialog seems to have trouble displaying some of these characters. That could be a clue.
Also, the error message is technically correct, since the file path (seemingly cut off at the end for unknown reasons) does indeed not exist:
file:///hack3_pelis/ð%C2%9F¤%C2%96Filebot/1/Belleza%20eterna%20(Eternal%20Beauty)%20(2020)%20%5BWEB-DL%201080p%20X265%2010bits%5D.
/hack3_pelis/ð<0x9F>¤<0x96>Filebot/1/Belleza eterna (Eternal Beauty) (2020) [WEB-DL 1080p X265 10bits].
I've been able to reproduce the issue with different File Dialog implementations using the following sample file path:
/volume1/😺/😺.groovy
A. GTK File Dialog via JavaFX (-Dnet.filebot.UserFiles.fileChooser=JavaFX
)
/volume1/ð<0x9F><0x98>º/ð<0x9F><0x98>º.
B. GTK File Dialog via Java AWT (-Dnet.filebot.UserFiles.fileChooser=AWT
)
volume1/ð/ð<0x9F><0x98>º.gro
C. Java Swing JFileChooser (-Dnet.filebot.UserFiles.fileChooser=Swing
)
/volume1/😺/😺.groovy
JavaFX
and AWT
both being broken, but in different ways, is rather interesting.
Setting JAVA_OPTS
to -Dnet.filebot.UserFiles.fileChooser=Swing
can be used to work around the problem. However, making this default is not ideal since the GTK File Dialog UI is significantly better.
The underlying issue may have been fixed with JavaFX 17
:
https://bugs.openjdk.java.net/browse/JDK-8210199
However, Ubuntu 20.04
packages OpenJFX 11.0.6
at this point in time. A future update will hopefully resolve the issue.
cool! you found the problem cause and possible solutions.
It semms the way that can make it work right now is the JAVA_OPTS trick... I tried and now it is taking the files! Thanks
Well,
I think I celebrate the victory very quick.
The files are taken, but I can't work with them
This validation allways fail when the files are inside a path with special characters
I copied the same files into another folder (withour special characters) and it works... Dammit, I dedicated many hours decorating the folder texts :(
IDK, but it's very possible that libmediainfo
doesn't play well with esoteric file paths like that.
From inside the docker I created a file (so it has write permissions), I readed the content of file (so it has execution permissions). Here is the proof:![image](https://user-images.githubusercontent.com/73612508/131248182-9dd9d9e7-e10b-4e0f-9bfc-1bb834090205.png)
But when I select a movie file in the Load > Select Files window:![image](https://user-images.githubusercontent.com/73612508/131248214-6214ebcc-2e18-418c-9d2d-8c206e313c80.png)
The file is not loaded![image](https://user-images.githubusercontent.com/73612508/131248221-3394b828-95ac-4988-a183-bda79fc4a662.png)
I found this log in the console: Aug 29, 2021 11:05:22 AM net.filebot.ui.transfer.FileTransferable getFilesFromTransferable WARNING: GVFS: file:///hack3_pelis/ð%C2%9F¤%C2%96Filebot/1/Belleza%20eterna%20(Eternal%20Beauty)%20(2020)%20%5BWEB-DL%201080p%20X265%2010bits%5D. => java.io.FileNotFoundException: /hack3_pelis/ð<0x9F>¤<0x96>Filebot/1/Belleza eterna (Eternal Beauty) (2020) [WEB-DL 1080p X265 10bits].