Message ID | 20220323052149.28674-1-wangxinpeng@uniontech.com (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | obexd: Fix can't receive small files sent by windows | expand |
Context | Check | Description |
---|---|---|
tedd_an/pre-ci_am | success | Success |
tedd_an/checkpatch | success | Checkpatch PASS |
tedd_an/gitlint | success | Gitlint PASS |
tedd_an/setupell | success | Setup ELL PASS |
tedd_an/buildprep | success | Build Prep PASS |
tedd_an/build | success | Build Configuration PASS |
tedd_an/makecheck | success | Make Check PASS |
tedd_an/makecheckvalgrind | success | Make Check PASS |
tedd_an/makedistcheck | success | Make Distcheck PASS |
tedd_an/build_extell | success | Build External ELL PASS |
tedd_an/build_extell_make | success | Build Make with External ELL PASS |
This is automated email and please do not reply to this email! Dear submitter, Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series: PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=625643 ---Test result--- Test Summary: CheckPatch PASS 1.48 seconds GitLint PASS 0.92 seconds Prep - Setup ELL PASS 52.57 seconds Build - Prep PASS 0.81 seconds Build - Configure PASS 10.33 seconds Build - Make PASS 1493.17 seconds Make Check PASS 12.78 seconds Make Check w/Valgrind PASS 538.63 seconds Make Distcheck PASS 280.99 seconds Build w/ext ELL - Configure PASS 10.66 seconds Build w/ext ELL - Make PASS 1479.03 seconds Incremental Build with patchesPASS 0.00 seconds --- Regards, Linux Bluetooth
Dear Xinpeng, Thank you for the patch. You can use `git format-patch`’s switch `--reroll-count` to denote that it’s replacing an earlier sent in patch. It’s also good practice to write the changes between the version below the `---` line, so it’s clear for the reviewer, what changed. For example: v2: Fix typo in commit message summary Am 23.03.22 um 06:21 schrieb xinpeng wang: > Windows devices use streaming mode to send files. If a small file is What do you mean by Windows devices exactly? Windows phone or any computer? > sent,the first time processing data will be completed successfully, Please add a space after the comma. > and the transfer_complete function will be called before the end to > clear os->path.At this time, the dbus signal is still pending, and Please add a space after the dot/period. > the dbus method call requesting the file path has not been processed; > in this way, the upper-level program will not be able to obtain the > file path, resulting in failure to receive the file. > Therefore, the signal of Filename is generated, and it is forced to > be sent when status=active. I’d also add a blank line between paragraphs. How can your issue be reproduced, and the fix verified? > Signed-off-by: xinpeng wang <wangxinpeng@uniontech.com> > --- > obexd/src/manager.c | 6 +++++- > obexd/src/obex.c | 1 + > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/obexd/src/manager.c b/obexd/src/manager.c > index 01741fe62..2c180dc44 100644 > --- a/obexd/src/manager.c > +++ b/obexd/src/manager.c > @@ -533,8 +533,12 @@ void manager_emit_transfer_property(struct obex_transfer *transfer, > void manager_emit_transfer_started(struct obex_transfer *transfer) > { > transfer->status = TRANSFER_STATUS_ACTIVE; > + if (!transfer->path) > + return; > > - manager_emit_transfer_property(transfer, "Status"); > + g_dbus_emit_property_changed_full(connection, transfer->path, > + TRANSFER_INTERFACE, "Status", > + G_DBUS_PROPERTY_CHANGED_FLAG_FLUSH); > } > > static void emit_transfer_completed(struct obex_transfer *transfer, > diff --git a/obexd/src/obex.c b/obexd/src/obex.c > index 3a68fd66c..c0d9e160a 100644 > --- a/obexd/src/obex.c > +++ b/obexd/src/obex.c > @@ -720,6 +720,7 @@ int obex_put_stream_start(struct obex_session *os, const char *filename) > manager_emit_transfer_property(os->service_data, "Size"); > > os->path = g_strdup(filename); > + manager_emit_transfer_property(os->service_data, "Filename"); > > return 0; > }
Dear Xinpeng, Am 23.03.22 um 14:15 schrieb wangxinpeng@uniontech.com: > 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
diff --git a/obexd/src/manager.c b/obexd/src/manager.c index 01741fe62..2c180dc44 100644 --- a/obexd/src/manager.c +++ b/obexd/src/manager.c @@ -533,8 +533,12 @@ void manager_emit_transfer_property(struct obex_transfer *transfer, void manager_emit_transfer_started(struct obex_transfer *transfer) { transfer->status = TRANSFER_STATUS_ACTIVE; + if (!transfer->path) + return; - manager_emit_transfer_property(transfer, "Status"); + g_dbus_emit_property_changed_full(connection, transfer->path, + TRANSFER_INTERFACE, "Status", + G_DBUS_PROPERTY_CHANGED_FLAG_FLUSH); } static void emit_transfer_completed(struct obex_transfer *transfer, diff --git a/obexd/src/obex.c b/obexd/src/obex.c index 3a68fd66c..c0d9e160a 100644 --- a/obexd/src/obex.c +++ b/obexd/src/obex.c @@ -720,6 +720,7 @@ int obex_put_stream_start(struct obex_session *os, const char *filename) manager_emit_transfer_property(os->service_data, "Size"); os->path = g_strdup(filename); + manager_emit_transfer_property(os->service_data, "Filename"); return 0; }
Windows devices use streaming mode to send files. If a small file is sent,the first time processing data will be completed successfully, and the transfer_complete function will be called before the end to clear os->path.At this time, the dbus signal is still pending, and the dbus method call requesting the file path has not been processed; in this way, the upper-level program will not be able to obtain the file path, resulting in failure to receive the file. Therefore, the signal of Filename is generated, and it is forced to be sent when status=active. Signed-off-by: xinpeng wang <wangxinpeng@uniontech.com> --- obexd/src/manager.c | 6 +++++- obexd/src/obex.c | 1 + 2 files changed, 6 insertions(+), 1 deletion(-)