Tab completion of directory paths containing single quotes is broken like so:
$ mkdir -p ”a’b/c”
$ cd a\’b/ # pressing tab won’t complete the ’c’ dir
as opposed to:
$ mkdir -p ”de/f”
$ cd de/ # pressing tab here completes the ’f’ dir just fine, to ’de/f/’
I initially thought this was Bug #1485777, but the reason I’m not so sure anymore is that for me, a manually appended \’ does not disappear (unlike for the reporter of #1485777). This does however also seem like a regression back to the issue of Bug #590829.
Just adding a note that this does still occur under 14.04, to which I recently upgraded. Naturally this was to be expected, given that the issue first occurred after switching to the Trusty HWE pack in 12.04.
Spoke too soon: looks like the context menu for links just also turned affected. I swear they still worked correctly when I was writing the previous comment!
I can reproduce this on a two-monitor setup: right-clicking in Chromium on the right monitor brings up context menu on the left monitor. Right-clicking on the left monitor works as expected.
I cannot reproduce the workaround: here the context menu opens on the left monitor no matter how close to the right edge of the right monitor I right-click Chromium.
I recently upgraded from 12.04 to 14.04, and this issue appeared with the upgrade. 12.04 currently has Chromium 37.0.2062.120, whereas 14.04 has version 44.0.2403.89.
Upstream has a similar bug report about right-clicking links [1], but for me at least right-clicking links is *not* affected: the issue occurs only for the tabs’ context menu and for web page right-clicks outside links, whereas the context menu of links opens on the right monitor.
Also, LP bug #1430393 [2] looks related, and is also reproducible here: (left-clicking) the main menu button also opens the menu on the wrong monitor.
* [1] https://code.google.com/p/chromium/issues/detail?id=409287
* [2] https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1430393
All right, I managed to upload it with chunked uploading just now, so I’m closing this as invalid. (Not sure if that’s correct, feel free to change it if needed.)
I had already tried chunked uploading yesterday, but it failed with a strange error message so I figured it doesn’t work. Sorry for the noise.
Please upload the linked video file to Wikimedia Commons:
Upgraded to 8.1 today and the issue remains.
So I set up a Debian Wheezy VM just to test this, and was able to reproduce it straight away: did a clean install of 8.1 in /var/www/owncloud/ and set the data directory to /var/www/oc (whose owner I set to www-data:www-data). After installer was finished, selecting Admin from the Admin menu immediately causes ”File does not exist: /var/www/owncloud/data” to show up in error.log.
There was also this other error associated with it (copying here by hand instead because haven’t set up copy & paste in VM yet):
touch(): Unable to create file \\/var\\/www\\/owncloud\\/data\\/owncloud.log because No such file or directory at \\/var\\/www\\/owncloud\\/lib\\/private\\/log\\/owncloud.php#53
It would seem to hint the source of this being OC_Log_Owncloud::init (which is where the line it refers to belongs to AFAICT). For some reason this message about touch() failing does not show up on my actual installation’s logs (the one I pasted the logs from in the initial report above). It no longer seems to show up in the VM either after I raised logging level up to ”Errors and fatal issues”; not even after I lower it back down to ”Info, warnings, errors and fatal issues”; only the ”File does not exist: /var/www/owncloud/data” still keeps appearing. Perhaps the vanishing of that other message is also caused by the same problem with OC_Log_Owncloud::init.
@PeterDaveHello done, hopefully right this time! Thanks for guiding me through this (it’s my first pull request, in case you couldn’t tell).
Hi @PeterDaveHello, the issues you mentioned should now be fixed. (I’m making this comment in case you’re not receiving notifications about the fix commits and test automaton pass, but do tell if more fixes are needed.)
Hi,
I’m getting this entry in my server log when I open the latest post in single-post view:
Trying to get property of non-object in [...]/wp-content/themes/cover/inc/template-tags.php on line 61
It looks like the reference to $next->ID on said line is causing this; there’s no next post from the newest, obviously. There is a test for ! $next && ! $previous on line 51, but I’m guessing the block generating$next_img_array for next_post_link should also be wrapped with a separate test for the existence of$next, to suppress the error.