Watched function dies when using default folder

[MaxWinterstein]

I switched to the devel branch to use the watched feature. I would like to throw a file into via samba and is should automatically show in the file list.

When i use the "default" folder the feature works one time and then crashes.

2015-11-25 19:45:27,042 - octoprint.filemanager.analysis - INFO - Starting analysis of local:orangepipc_final3.gcode
Exception in thread Thread-12:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/local/lib/python2.7/dist-packages/watchdog-0.8.3-py2.7.egg/watchdog/observers/api.py", line 199, in run
    self.dispatch_events(self.event_queue, self.timeout)
  File "/usr/local/lib/python2.7/dist-packages/watchdog-0.8.3-py2.7.egg/watchdog/observers/api.py", line 368, in dispatch_events
    handler.dispatch(event)
  File "/usr/local/lib/python2.7/dist-packages/watchdog-0.8.3-py2.7.egg/watchdog/events.py", line 454, in dispatch
    _method_map[event_type](event)
  File "/usr/local/lib/python2.7/dist-packages/OctoPrint-1.3.0.dev701+gb3e6fe6-py2.7.egg/octoprint/server/util/watchdog.py", line 66, in on_created
    self._upload(event.src_path)
  File "/usr/local/lib/python2.7/dist-packages/OctoPrint-1.3.0.dev701+gb3e6fe6-py2.7.egg/octoprint/server/util/watchdog.py", line 58, in _upload
    allow_overwrite=True)
  File "/usr/local/lib/python2.7/dist-packages/OctoPrint-1.3.0.dev701+gb3e6fe6-py2.7.egg/octoprint/filemanager/__init__.py", line 376, in add_file
    file_path = self._storage(destination).add_file(path, file_object, links=links, printer_profile=printer_profile, allow_overwrite=allow_overwrite)
  File "/usr/local/lib/python2.7/dist-packages/OctoPrint-1.3.0.dev701+gb3e6fe6-py2.7.egg/octoprint/filemanager/storage.py", line 571, in add_file
    file_object.save(file_path)
  File "/usr/local/lib/python2.7/dist-packages/OctoPrint-1.3.0.dev701+gb3e6fe6-py2.7.egg/octoprint/filemanager/util.py", line 62, in save
    shutil.move(self.path, path)
  File "/usr/lib/python2.7/shutil.py", line 302, in move
    copy2(src, real_dst)
  File "/usr/lib/python2.7/shutil.py", line 130, in copy2
    copyfile(src, dst)
  File "/usr/lib/python2.7/shutil.py", line 82, in copyfile
    with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: '/home/orangepi/.octoprint/watched/orangepipc_final3.gcode'

i changed the watch folder to /tmp/watched and reconfigured samba and everything works fine. It looks like the copy and analyze thread is working against each other or something like this.

i use

• OrangePi-PC with Ubuntu 15.10 minimal
• Version: 1.3.0.dev701+gb3e6fe6 (devel branch)

Gruß aus Stuttgart :)

[GitIssueBot]

Hi @MaxWinterstein,

It looks like there is some information missing from your ticket that will be needed in order to process it properly. Please take a look at the Contribution Guidelines and the page How to file a bug report on the project wiki, which will tell you exactly what your ticket has to contain in order to be processable.

If you did not intend to report a bug, please take special note of the title format to use as described in the Contribution Guidelines.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2015-12-09 20:10) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

[MaxWinterstein]

@GitIssueBot you are the reason why people hate writing bug reports... oh this is so annoying...

1. What were you doing?
   tried to use the watched folder feature
2. What did you expect to happen?
   it to work
3. What happened instead?
   it crashed - see post 1
4. Branch & Commit or Version of OctoPrint:
   Version: 1.3.0.dev701+gb3e6fe6 (devel branch)
5. Printer model & used firmware incl. version
   (if applicable - always include if unsure):
   doesn't matter
6. Browser and Version of Browser, Operating
   System running Browser (if applicable - always
   include if unsure):
   doesn't matter
7. Link to octoprint.log on gist.github.com or pastebin.com
   (ALWAYS INCLUDE AND DO NOT TRUNCATE):
   https://gist.github.com/MaxWinterstein/55fd90fcc8a44876e542
8. Link to contents of terminal tab or serial.log on
   gist.github.com or pastebin.com (if applicable - always
   include if unsure or reporting communication issues AND
   DO NOT TRUNCATE):
   see 7.
9. Link to contents of Javascript console in the browser
   on gist.github.com or pastebin.com or alternatively a
   screenshot (if applicable - always include if unsure
   or reporting UI issues):
   doesn't matter
10. Screenshot(s) showing the problem (if applicable - always
    include if unsure or reporting UI issues):
    doesn't matter

I have read the FAQ.

[Murenius]

@MaxWinterstein you are the reason why people hate being human and devs hate being devs... oh this is so annoying...

There is a fragging reason why bug report templates exist. And you are using a free open source software. If you're not even willing to take the 3 bloody minutes to use a report template - and expect the dev to take HIS/HER time to work though your BS - you do not even deserve to be provided with free software.

[MaxWinterstein]

@Murenius thanks for insulting me, this will help me / us a lot. is there anything useful you can provide here?

[Murenius]

"@GitIssueBot you are the reason why people hate writing bug reports... oh this is so annoying... " I only slightly changed your answer, so guess you were insulting as well. The useful part of my contribution was to point out that you left the pure factual level. I suggest getting back to that and in the future show some respect to a dev investing his time by at least filling out the bug report template properly.

[MaxWinterstein]

@Murenius you know that @GitIssueBot is an automatic system that only checks if the template is included? If you compare the second post of me against the first post you will see it does not include more information and was approved.

So anyway, i will leave this useless conversation with you. It does not get us any usefull information and does not help me or the developers in any way. Since you seem not to be involved in octoprint in any way, and your fist post on github at all is the one insulting me, it is not worth the time to discuss something here with you.

[foosel]

@MaxWinterstein Why I do not agree 100% with the choice of @Murenius words, he has a point. You apparently felt annoyed by the bot enough to feel it necessary to complain about it. You might be surprised to hear that I also don't like it very much - and I wrote it. The problem is, even more annoying than that bot is getting bug reports that

• are support requests in disguise
• are missing what version of the software is even the one we are talking about
• don't have any logs attached
• don't explain what happened BEFORE the problem occurred
• are about stuff that is explained in detail in the FAQ
• aren't even at the correct place here since they are either about OctoPi or an OctoPrint plugin or even a completely unrelated project (I've gotten tickets for git here...)

and having to run after all that information, revisiting each and every ticket continuously until either all data is there or it is clear that the OP won't be answering at all. And not only with one ticket but several dozens. With a noticeable increase over certain events like e.g. the holidays.

So if you want to complain about something, complain about those users of OctoPrint please that have made it necessary to put some automated response system in place to basically hit them over the head with what is posted on top of every new issue form and also automating the revisiting of the tickets that aren't complete after two weeks. You can believe me when I tell you that I really wish that stupid bot wasn't necessary and people would just provide all data, always, with concise information about how to reproduce. Alas, that isn't the case, and the bot has at least reduced the time spent ticket management to levels where not only actual development (bug fixing, new features, ...) is possible again, it's actually fun helping people again.

---

And with that please let us leave that behind and concentrate on the actual issue.

Speaking of which, I haven't yet been able to reproduce it on current devel on my development system.

edit Also not on devel on a Pi (1.3.0.dev701+gb3e6fe6). So, let's mark that as unreproduced and see if other people encounter it.

[MaxWinterstein]

@foosel i can totaly agree with you. peple use the issue system way too often for things that doent make sense. And wasting time in working on tickets that seems to be totally wrong is anoying at all.
I am an system/network administrator myself and know the pro and cons of ticket systems. But my opinion is a little different. I would rather have 5 not very informative tickets that point to an problem than no ticket because the user is not willing/able to fill it correctly. But this is my personal opinion, and this is your issue tracker and not mine, so i accepted it and filled everything that the issue tracker was asking for.

I also think this should not be even worth to discuss about. As i said, this is your house, i agree to your rules.

---

i invested my coffee break to see if i can provide more information.
I removed the changed watchfolder from /tmp back to the default and made a few tests. 1.2.7 or 1.3 made the seem output for me. my test:

orangepi@OrangePi:~/.octoprint/watched$ cp ../uploads/orangepipc_final1.gcode user-orangepi-normal`date +%s.gcode`

works fine. the file is move to the uploads folder and its working nice for the next cp.

using sudo produces the problem:

orangepi@OrangePi:~/.octoprint/watched$ sudo cp ../uploads/orangepipc_final1.gcode user-orangepi-sudo`date +%s.gcode`

produces the following output on console:

Exception in thread Thread-8:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/home/orangepi/OctoPrint/venv/local/lib/python2.7/site-packages/watchdog-0.8.3-py2.7.egg/watchdog/observers/api.py", line 199, in run
    self.dispatch_events(self.event_queue, self.timeout)
  File "/home/orangepi/OctoPrint/venv/local/lib/python2.7/site-packages/watchdog-0.8.3-py2.7.egg/watchdog/observers/api.py", line 368, in dispatch_events
    handler.dispatch(event)
  File "/home/orangepi/OctoPrint/venv/local/lib/python2.7/site-packages/watchdog-0.8.3-py2.7.egg/watchdog/events.py", line 454, in dispatch
    _method_map[event_type](event)
  File "/home/orangepi/OctoPrint/venv/local/lib/python2.7/site-packages/OctoPrint-1.2.7-py2.7.egg/octoprint/server/util/watchdog.py", line 66, in on_created
    self._upload(event.src_path)
  File "/home/orangepi/OctoPrint/venv/local/lib/python2.7/site-packages/OctoPrint-1.2.7-py2.7.egg/octoprint/server/util/watchdog.py", line 58, in _upload
    allow_overwrite=True)
  File "/home/orangepi/OctoPrint/venv/local/lib/python2.7/site-packages/OctoPrint-1.2.7-py2.7.egg/octoprint/filemanager/__init__.py", line 370, in add_file
    file_path = self._storage(destination).add_file(path, file_object, links=links, printer_profile=printer_profile, allow_overwrite=allow_overwrite)
  File "/home/orangepi/OctoPrint/venv/local/lib/python2.7/site-packages/OctoPrint-1.2.7-py2.7.egg/octoprint/filemanager/storage.py", line 459, in add_file
    os.utime(file_path, None)
OSError: [Errno 13] Permission denied: '/home/orangepi/.octoprint/uploads/user-orangepi-sudo1448548549.gcode'

The problem itself is - for sure - the use of sudo. And my samba drive was possibly using the wrong file rights also. The problem is that octoprint is not looking in the watched folder any longer after this error output. It would be nice if the error would be printed in the console but octoprint would then work with the next file instead of crashing and not restarting the watched folder worker.

edit: octoprint is able to move the file somehow. here is the created file (i stopped octoprint)

orangepi@OrangePi:~/.octoprint/watched$ ls -liah
total 1.3M
243149 drwxrwxr-x  2 orangepi orangepi 4.0K Nov 26 14:44 .
243120 drwxrwxr-x 13 orangepi orangepi 4.0K Nov 26 14:16 ..
243162 -rwxr--r--  1 root     root     1.3M Nov 26 14:44 user-orangepi-sudo1448549081.gcode

[foosel]

Then I misunderstood the problem. I understood "it crashed" as referring to the specific exception (a lot of people say "it crashed" when in fact they mean "logged an error"), not as "if some exception is raised in the watchdog due to problems external to OctoPrint, it stops working".

The latter I can reproduce and is fixed in the above commit.

[MaxWinterstein]

i updated my devel to Version: 1.3.0.dev703+g47670a1 (devel branch) and tried with the same files. Now it works as expected. It throws an exception but does not die, and the next correct file is proccessed as supposed.

Thanks for the quick reply & bugfix :)

[foosel]

Perfect, closing then. Thanks for reporting!