<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body><a class="email" href="mailto:mikekaganski@hotmail.com" title="Mike Kaganski <mikekaganski@hotmail.com>"> Mike Kaganski</a> changed <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - deleting file when concurrent access from the same host" href="https://bugs.documentfoundation.org/show_bug.cgi?id=127057">bug 127057</a> <table border="1" cellspacing="0" cellpadding="8"> <tr> <th>What</th> <th>Removed</th> <th>Added</th> </tr> <tr> <td style="text-align:right;">Status</td> <td>NEW </td> <td>NEEDINFO </td> </tr></table> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - deleting file when concurrent access from the same host" href="https://bugs.documentfoundation.org/show_bug.cgi?id=127057#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - deleting file when concurrent access from the same host" href="https://bugs.documentfoundation.org/show_bug.cgi?id=127057">bug 127057</a> from <a class="email" href="mailto:mikekaganski@hotmail.com" title="Mike Kaganski <mikekaganski@hotmail.com>"> Mike Kaganski</a> <pre>(In reply to b. from <a href="show_bug.cgi?id=127057#c4">comment #4</a>) Is it reasonable for someone already having some experience here to do what you do here? > > Does RDP have any relevance to this issue? > > Can you check all this from a local computer? > > local computers will rarely have two users working in parallel, Do you say that you honestly didn't understand what was written/asked in the words you cited? that the question was about the possible distinction between some problem caused by using *RDP stack* (a possible thing) vs something which is also possible to reproduce without RDP (however unlikely that could be for a real0life scenarion, but which would enable to see that for triangers/developers in a simpler environment)? > > It would be great if you could experiment and narrow down > > the requirements and specific steps, > > OP wrote he downgraded to avoid data loss and user complaints, Did you really call the downgrade of everything (OS, LO, possibly (unknown) RDP server, too?) an answer to the direct question ("try to repro this without RDP to narrow down")? > > because QA or devs will have close to zero chance setting up a similar > > environment. > > either that should be made available (it's not very difficult), or LO should > come with 'RDP not supported', Do you really declare that QA team must never answer with attempt to help/show OP ther way to help others help OP to improve the question, and allow further work on it? Do you declare that any report must either result in "Fe found the problem and fixed it right now!" or "as you experience some problem in un(sufficiently)specified situation, we here declare the whole area (which works fine for many) unsupported"? > > It would also be good to know if it can be reproduced with a single user > > relying on multiple LO installations (see [1]) > > LO has enough problems with single user single installation single instance > access to network shares, it's quite useless to check for problems with > exotic installs while 'standard' doesn't work, Do you further call any proposed steps to limit the problem scope inappropriate, just because you you know of something unrelated? > > And finally, as this is probably closely related to the usage of samba > > shares, knowing the exact configuration there would be important. > > my 'single' problems are on a network share provided by a 'FRITZ!Box' router > accessed from a win7pro X64 host by 'net use x: > \\AAA.BBB.CCC.HHH\fritz.nas\"device_name"\"shared_directory" "password" > /user:"username"', to access it from a linux box by 'mount ... cifs ...' i > had to explicitely specify the version with 'vers=1.0'? And in the end, are you really sure that responding with such an offtopic with all that nonsense, which only cold discourage OP (or anyone else with a similar problem, who could come across and happen to be able to provide the necessary info) from collaboration and moving the bug into the good state allowing developers to further work on this, is an appropriate thing - especially for someone who seems to already have some experience... The NEEDINFO status if to receive *requested information*. If *the* information is *not* provided, then the status is still NEEDINFO. If you have a similar problem, you may provide the information. That would of course change the status to NEW (because of independent confirmation, *and* because the information was given)./ But not if you chose to "confirm" in such destructive way.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>