I know this isn't really code related, but I don't know where else to ask?
While working yesterday I got a message saying that my startup disk was almost full. Which I wasn't too surprised by because it's only a 128gb Air.
But when I fired up Daisydisk to see what the issue was it appears that my computer has stored 2 files in the private/var/tmp directory, each over 30gb. Obviously Daisydisk won't let me erase them because of the directory they are in.
They are called magick-23598T_US4im5XKvQ.pam and magick-23587vell8J7UTKgS.pam
I have no idea where they came from, but I was testing a file upload system for a rails project when this happened. I was however uploading images over no more than 800kb or so. This seems a little extreme for that.
If anyone has any idea what might have happened, or how I can safely free up this space again, I would be massively grateful.
Looks like ImageMagick temp files -- are you processing the images with ImageMagick? There's a similar problem discussed here although the exact cause may be different.
It is likely a large swap file from ImageMagick that hasn't been cleaned up. You can limit the file sizes by editing your policy.xml config for ImageMagic (/etc/ImageMagick/policy.xml on Ubuntu).
More info here: https://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=29225&p=130707#p130707
Related
This question is not a duplicate to another question that asks about the same message, but in another context. The context of this question is just about uploading screenshot images and getting the message.
Today, I had a new message when uploading images to App Store Connect:
Invalid GeoJSON: Your routing app coverage file is invalid.
This makes absolutely no sense since, at this time, I had not even chosen a build for the upload.
Retrying to upload the images, it worked. But unfortunately, the message appeared for each language and format.
Is this a bug by Apple or am I missing something? I would guess that uploading images has nothing to do with GeoJSON.
I used Safari. Others seem to have the problem with Chrome. So it occasionally seems to happen on all browsers.
I had this same problem today while uploading App Store Icon on Preparing for submission page. Solved it by removing "-" from my image name.
This is an unusual bug. Apple might be already working on it. It's not coming on any specific browser. It occurs mostly when we are trying to upload more than one images at once.
Apple always keeps their live site maintenance work active, so this is most likely a bug occurring in their live site maintenance. It will be fixed soon.
For now, if you are finding difficulties handling screenshot uploads, you can try to upload them one by one rather than uploading in a bulk.
Important Note:
I am stating this on basis of the last few uploads I have experienced. Also, the solution I have given is tried from my side and it worked for me well. So, you can just try it out and I'm sure that it's not a browser issue. It can occur on any browser.
It did not work for me even if I provided English file names. It kept giving the above error.
Only thing that worked for me was to remove all underscores. So instead of iphone_xs_max_1.png, it worked when I renamed it to iphone1.png and uploaded.
Make sure screenshot files name in English.
Make sure screenshot files all the directory path(and folder name) in English.
it worked for me.
I had the same bug today. Some of the images uploaded without problems, others didn't.
I was uploading in Chrome when I got the issue. Opening the site in Safari and uploading the images there, solved the problem.
What solved this for me was removing strings of numbers and periods from the filenames. It appears the system is running the filenames through some kind of geocoder, and if there are strings of characters that could be interpreted as locations, it will error out.
Make sure after editing the image you save the file with an extension like myimage.png or myimage.jpg
In my case, I forgot to save the file with extension after removing alpha and transparency properties and no need to change browser etc.
The images in question are JPEGs and I've gotten them down to a smaller size (30kb). The wordpress site in question is responsive and this issue on happens when I'm using mobile network to load the site. Wirelessly, it has no issues but on 3G/4G, images loaded randomly, some are corrupted, images swap places, so all css and js seems messed up. I'm using W3 cache to enhance the speed, but nothing is helping. Some images are half grey, black and look corrupted sometimes. This only happens on iOS devices with safari browser.
Anyone else faced the same issue? On desktop being wired, wireless, I've never had this issue.
Not sure if it has to do with with database or overall site performance of the server. Any help is greatly appreciated.
While supporting our WordPress Clients, I've faced such an issue dozens of times There are two general reasons for such a behavior:
You're using some CDN (Content Delivery Network) which you didn't mention in your question, and different CDN servers output different website cache version. If you're using CDN, try to purge your local plugin's cache, disable your local plugin and purge your CDN cache.
Sometimes images thumbnails may be corrupted, while they still exist. Try installing "Force Regenerate Thumbnails" plugin and regenerate all the thumbnails.
Though two above reasons are the most common, the issue itself may be connected with something else as well, for example, with some particular plugin. For this case it might be a good idea to temporarily deactivate your plugins one after another and see if the issue is resolved.
In case any of these won't help, it will require some debug work, so it could be a good idea to hire some WordPress developer for about an hour to fix this.
Good Luck!
If you have access to a mac + safari you can try remote debugging your iOS device. If you do this you could open the developer toolbar for the device so you can see if the information is actually being loaded. ie. if the messed up image is 300k on the desktop site, but the iOS device is loading a 30k image, you would know you're losing data somewhere.
I've not seen this specific issue, but I've had similar issues pop up due to bad CDN links, caching plugins, and lazy loading of images.
Another note to look for would be if your theme/template/plugins are using src sets. It could be possible that your normal version of the image is fine, but the images in the srcset for mobile are all messed up.
As noted above, completely disable w3 cache to troubleshoot that it's not the issue. Then take a look at the plugins.
In my app i want the user to be able to download offline map content.
So I (compressed) moved all my tiles into a zip file. (I used 0 compression)
The structure is like that: {z/x/y.jpg}
+0
+-0
+--0.jpg
+1
+-1
+--0.jpg
+2
+-2
+--1.jpg
So basically there are going to be many many files for zoom level 0-15. (about 120.000 tiles for my test-region).
I am using https://github.com/mattconnolly/ZipArchive now but also tried out https://github.com/soffes/ssziparchive before and both are pretty slow. It takes about 5!! minutes on my iPhone 5S for the files to unzip.
Is there any way I can speed things up? What other possibilities rather than downloading the tiles in one big zip file would there be?
Edit:
How can i download the content of the whole folder quickly to my iPhone without the need of unzipping something?
Any help is appreciated!
JPGs rarely compress at all with zip - they are by definition already compressed. What you should do is create your own binary file format, and put whatever metadata you need into it along with the images (which you should encode with a really low quality number, to get their size down).
When you download those files, you can open then, quickly read them into memory, and extract out data or images as needed.
This will be really fast and have virtually no overhead if your extra data is binary (not text).
PS: I just tripped on a PHP Plist class
If anyone is wondering how I was ending up:
For my use-case (MapTiles) I am using MBTiles now instead of zipped images. It's one big database file and super easy to read if using FMDB. No unpacking whatsoever needed...
Even if I was placing the Images all in one binary file without any compression, the "extracting" still took forever!
I hope you can solve this or at least tell what to do about it because I'm clueless. The thing is that once I've saved a .wxm file and then want to open it appears on wxMaxima this error and the "app" crashes:
Maxima encountered a Lisp error:
decoding error on stream
<SB-SYS:FD-STREAM for "socket 127.0.0.1:62607, peer: 127.0.0.1:4011"
{13F30991}
(:EXTERNAL-FORMAT :ASCII):
the octet sequence (195) cannot be decoded.
Automatically continuing.
To enable the Lisp debugger set debugger-hook to nil.
Thanks in advance.
P.S.: I run the latest Mac OS X version on my iMac.
Create a new file and write it down.
(setf sb-impl::*default-external-format* :utf-8)
(setf sb-alien::*default-c-string-external-format* :utf-8)
Save the file as .sbclrc at Home (User) folder.
I come back on this post as I have been affected by this today.
I am using Ubunutu 14.04 and the same bug appears. To me it is due to Maxima not being able to load anything else than ".mac" files, nothing to do with utf-8/ASCII (I have mv a file that is working to a wxm and vice-versa, it will not work anymore / rework)
Also I have prepared a workaround:
The idea is too have a tool that translates your .wxm files to a .mac file just before you load it (it is actually a very easy bash script)
So:
you put the wxm-to-mac.sh files into your path
then inside maxima, instead of doing
load("foo.wxm")
you simply do
system("wxm-to-mac foo.wxm")$
load("foo.mac")$
Bare in mind you shall not edit the foo.mac file because a routine might re-erase it afterward. Instead keep editing the .wxm file.
Hope it helps someone
Looks like the file has been saved with some non-ASCII characters (e.g. UTF-8) in it, but it is not read as UTF-8; that seems to be a bug in wxMaxima. Can you please post the offending .wxm file?
I was having the same problem, since none here could give a straight and correct answer (at least is not marked with the green icon) i tried to look somewhere else. I couldn't find an answer that solve my problem, but then i thought that i had used WxMaxima on Mac before and it worked pretty nice. The last time i installed wxmaxima on mac and it worked was in september 2012, i went to the http://sourceforge.net website and searched for the maxima file that was available on that date and i found http://sourceforge.net/projects/maxima/files/Maxima-MacOS/5.18.1-MacOS/, i installed it and its working pretty fine (about the problem, it is weird, even if i create a new maxima file typed "a" and saved it, i could no longer open it, so i'm guessing that it has nothing to do with ascii or non-ascii characters) I have no idea why this error happens on the recent version of Maxima/WxMaxima, but it makes no sense that we have to install a previous version for it to work.
Anyway, it's working for me, and i hope it works for you too. Glad i helped :)
I had the same problem.
In my case, the name of the directory where the ".wxm" file is located, contained Korean letter. I changed the directory name with an English one.
Then the problem has been solved.
I hope this works for you, too.
Sometimes when I add a new file to my path, I have to restart MATLAB or it won't be detected. There must be an other way to this!
I have experienced similar problems (Matlab does not notice it when I change a file). Unfortunately, I have no idea what causes it or how to solve it. I usually find that CLEAR ALL solves the problem, but be aware that it clears all variables in the work space. Some 'REHASH' command (e.g., REHASH TOOLBOXRESET) may also be useful.
I'd love to see a better answer; all documentation that I came across seems to indicate that this cannot happen.
Perhaps this is a problem with Matlab caching certain files at startup to improve performance. This happens with files in certain directories.
From Matlab help for path command:
Note (...) Also note that locations of files in the matlabroot/toolbox directory tree are loaded and cached in memory at the beginning of each MATLAB session to improve performance. If you save files to matlabroot/toolbox directories using an external editor or add or remove files from these directories using file system operations, run rehash toolbox before you use the files in the current session. If you make changes to existing files in matlabroot/toolbox directories using an external editor, run clear functionname before you use the files in the current session. For more information, see the rehash reference page or the Toolbox Path Caching topic in the MATLAB Desktop Tools and Development Environment documentation
I've often seen this happen with networked file locations. I don't understand the mechanism, but it definitely happens. A solution that often works:
path(path);
or, if that fails to pick it up, try this: (NB, this will clear your workspace)
clear classes;
path(path);
We did this last one so much, we put it in script on our common code path called:
shazaam;
Yes, my age is showing.
You want the "rehash" function or you need to set the path again using "path(path)" or similar. It also depends on whether you're using a "frozen" path. Look at the help for ADDPATH.
MATLAB will keep a cached copy of the compiled M-file unless it know that you've changed it. If you've created the file or you've edited it outside of MATLAB, then it may not know that it's changed.
This happens to me when the networked drive connection is lost then restored. rehash does not work but rehash toolboxreset does