Dear Xinpeng, Am 23.03.22 um 14:15 schrieb wangxinpeng@xxxxxxxxxxxxx:
Thank you very much for your guidance.
Thank you for the patch, and your response. Sorry for the late reply.
Modifications to the patch, I will pay attention to replace it with `--reroll-count` in the future, thanks a lot.
Awesome.
A Windows device refers to a computer with the Windows 10 system installed. Ways to reproduce the problem: 1.Use the laptop with the windows 10 system installed to send small files to the computer with the ubuntu system through bluetooth (I found that sometimes sending fails during testing,then i installed a blueman on ubuntu, use blueman to connect to the windows computer first); 2.the small file's size is less than 10k. After sending ok, it will be found that the file is in the ~/.cache/obexd/ directory, but not transferred to the ~/Download directory. For large files, it is in the ~/Download directory after sending. Validation bug fix: This problem needs to be done by bluez and the upper management program (like blueman); the full effect cannot be seen until the upper management program is modified. Now use dbus-monitor --session path=/org/bluez/obex/server/session1/transfer0 (this command is the first time the file is received at startup, and the number will be incremented each time after that) to see whether obexd generates the correct signal(include Filename).
Thank you for the detailed response. I do currently not have a Microsoft Windows system to test this, but sounds good.
Personally, I would like to hive this information in the commit message, but I d not know the policy of the project. If you are up to it, you could amend the commit message, and reroll it.
Thank you for your work. Kind regards, Paul
