I looked at the man pages, searched here, googled, etc.
Does anyone know the default size used by logrotate?
What reference can you cite stating the default size?
I know I can set size specifically in my config files.
There isn't a default size, because it's an optional flag. logrotate will rotate based on certain criteria that you give it, e.g., file size or time period (daily, weekly, etc). So it's not that it has a default file size (except maybe something like size 0), it's just not a precondition for a file being rotated.
So far as I know, there is no default size for logrotate, no need to waste time on this，set the value yourself in config file.
Related
We're making use of the newly added MessageSummaryItems.PreviewText feature. Thank you!!
On issue is: sometimes the PreviewText contains HTML links? From reading through the source I see this in ImapFolderFetch.cs
var body = message.TextBody ?? message.HtmlBody;
So this is saying: use the Plaintext version, if it exists, then use the HTML version?
Therefore if I see links in the preview, I can assume no Plaintext version is available?
Our problem with this is:
If our message only has an HTML version, We could strip the links from the message in our code, but there are only 256 characters of it. In many cases, there will be nothing left to display.
As per your TODO: Using the CONVERT extension would be a better approach but, as far as I can tell its not supported by Gmail?
A fall back would be:
If we could set the preview length for both HTML and Plaintext individually, then we could say, If you only have an HTML version give me 1K of it and i'll strip out the links on the client.
Thoughts?
Very few IMAP servers support the CONVERT extension which is the main reason I didn't implement it.
The PreviewText feature is an attempt at adding a convenience feature to fetch the first 256 bytes of each message body in batched requests in order to minimize latency, but no matter what I do, it's not guaranteed to be useful (since there could be a ton of markup before any real text is included in HTML).
If I were to split text and html messages into 2 different batches so that I could request different sizes for each, then it would be less efficient and might take significantly longer to fetch, so I'm not sure if it's really worth it. The less I'm able to batch at a time, the less useful the feature becomes compared to implementing your own loop over the list of messages and downloading your own specified chunk size. one message at a time.
My suggestion would be to use the PreviewText feature and for the rare messages where the 256 bytes isn't enough, perform a folder.GetStream() on them.
The following space allocation is giving me an sB37 JCL error. The cobol size of the output file is 100 bytes and the lrecl size is 100 bytes. What do you think is causing this error? I have tried increase the size to 500,100 and still get the same error.
Code:
//OUTPUT1 DD DSN=A.B.C,DISP=(NEW,CATLG,DELETE),
// DCB=(LRECL=100,BLKSIZE=,RECFM=FBM),
// SPACE=(CYL,(10,5),RLSE)
Try to increase not only the space, but the volume as well.
Include VOL=(,,,#) in your DD. # is the numbers of values you want to allocate
Ex: SPACE=(CYL,(10,5),RLSE),VOL=(,,,3) - includes 3 volumes.
Additionally, you can increase the size, but try to stay within reasonable limits :)
The documentation for B37 says the application programmer should respond as indicated for message IEC030I. The documentation for IEC030I says, in part...
Probable user error. For all cases, allocate as many units as volumes
required.
...as noted in another answer. However, be advised that the documentation for the VOL parameter of the DD statement says...
If you omit the volume count or if you specify 1 through 5, the system
allows up to five volumes; if you specify 6 through 20, the system
allows 20 volumes; if you specify a count greater than 20, the system
allows 5 plus a multiple of 15 volumes. You can override the maximum
volume count in data class by using the volume-count subparameter. The
maximum volume count for an SMS-managed mountable tape data set or a
Non-managed tape data set is 255.
...so for DASD allocations you are best served specifying a volume count greater than 5 (at least).
//OUTPUT1 DD DSN=A.B.C,DISP=(NEW,CATLG,DELETE),
// DCB=(LRECL=100,BLKSIZE=,RECFM=FBM),
// SPACE=(CYL,(10,5),RLSE)
Try this instead. Notice that the secondary will take advantage of a large dataset whereas without that parameter the largest secondary that makes any sense is < 300. Oh, and if indeed it is from a COBOL program make sure that the FD says "BLOCK 0"!!!!! If it isn't "BLOCK 0" then you might not even need to change your JCL because it wasn't fixed block machine. It was merely fixed and unblocked so the space would almost never be enough. And finally you may wish to revisit why you have the M in the RECFM to begin with. Notice also that I took out the LRECL, the BLKSIZE and the RECFM. That is because the FD in the COBOL program is all you need and putting it in the JCL is not only redundant but dangerous because any change will have to be now done in multiple places.
//OUTPUT1 DD DSN=A.B.C,DISP=(NEW,CATLG,DELETE),
// DSNTYPE=LARGE,UNIT=(SYSALLDA,59),
// SPACE=(CYL,(10,1000),RLSE)
There is a limit of 65,535 tracks per one volume. So if you will specify a SPACE that exceeds that limit - system will simply ignore it.
You can increase this limit to 16,777,215 tracks by adding DSNTYPE=LARGE paramter.
Or you can specify that your dataset is a multi volume by adding VOL=(,,,3)
You can also use DATACLAS=xxxx paramter here, however first of all you need to find it. Easy way is to contact your local Storage Team and ask for one. Or If you are familiar with ISPF navigation, you can enter ISMF;4 command to open a panel
use bellow paramters before hitting enter.
CDS Name . . . . . . 'ACTIVE'
Data Class Name . . *
It should produce a list of all available data classes. Find the one that suits you ( has enougth amount of volume count, does not limit primary and secondary space
The pagesize of the file I read is 32768. When i set the JET_paramDatabasePageSize to 32768,JetInit returns -1213.Then,i set the JET_paramRecovery to "Off",JetInit succeeds.But,when I use JetAttachDatabase,it returns -550.
Here is my code:
err=JetSetSystemParameter(&instance,sesid,JET_paramDatabasePageSize ,32768 ,NULL);
err=JetCreateInstance(&instance,NULL);
err=JetSetSystemParameter(&instance,sesid,JET_paramRecovery,0,"Off");
err=JetInit(&instance);
err=JetBeginSession(instance,&sesid,NULL,NULL);
err=JetAttachDatabase(sesid,buffer, JET_bitDbReadOnly );
err=JetOpenDatabase ( sesid, buffer, NULL, &dbid, JET_bitDbReadOnly );
What's wrong with it？I am running a Windows 7 32bit.
The page size is global to the process (NOT just the instance) and is persisted in the log files and the database, so changing the page size can be annoyingly tricky.
Is there information in the database that you're trying to access? Or did you just experience this during development?
If you saw this during development, then the easiest thing to do is to blow everything away (del .edb edb) [Assuming that you kept the prefix as "edb"].
Also, are you sure that the database is 32k pages? You can confirm with esentutl.exe -mh <database-name>.
It will be trickier to recover the data if you do care about, and you switched the page size. (I don't know off the top of my head, and I'd have to try a few things out...)
-martin
This will be a little backwards from the typical approach.
I've used ExifTool for metadata manipulation before, but I really want to keep the best metadata backup I can before I make anything permanent.
What I want to do is remove the compressed image portion of a JPEG file to leave everything else intact. That's backing up EXIF, Makernotes, IPTC, XMP, etc whether at the beginning or end of the file.
What I've tried so far is to strip all metadata from a copy of the original JPEG, and use it as a basis of what bytes will be taken out of the original. After looking at the raw data, it doesn't seem like the stripped copy is contiguous in the original copy. There may be some header information still remaining in the stripped version. I don't really know. Not a good way to do it, I suppose.
Are there any markers that will absolutely tell me where the compressed JPEG image data starts and ends? I understand that JPEG files have 0xFFD8 and 0xFFD9 to mark the start and end of the image, but have come to find out that metadata is actually between those markers.
I'm using C#.
Thank you.
To do this properly you need to fully parse the JPEG/JFIF format and discard anything you don't want. Metadata is all kept in APP segments or trailers after the JPEG EOI, so presumably you will toss everything else. Full parsing of a JPEG/JFIF is not trivial, and for this I refer you to the JPEF/JFIF specification.
You can use the JpegSegmentReader class from my MetadataExtractor library to retrieve specific segments from a JPEG image.
I'm not sure if memory is the culprit here. I am trying to instantiate a GD image from data in memory (it previously came from a database). I try a call like this:
my $image = GD::Image->new($image_data);
$image comes back as undef. The POD for GD says that the constructor will return undef for cases of insufficient memory, so that's why I suspect memory.
The image data is in PNG format. The same thing happens if I call newFromPngData.
This works for very small images, like under 30K. However, slightly larger images, like ~70K will cause the problem. I wouldn't think that a 70K image should cause these problems, even after it is deflated.
This script is running under CGI through Apache 2.0, on OS 10.4, if that matters at all.
Are there any memory limitations imposed by Apache by default? Can they be increased?
Thanks for any insight!
EDIT: For clarification, the GD::Image object never gets created, so clearing out the $image_data from memory isn't really an option.
GD library eats many bytes per byte of image size. It's a well over a 10:1 ratio!
When a user uploads an image to our system, we start by checking the file size before loading it into a GD image. If it's over a threshold (1 Megabyte) we don't use it but instead report an error to the user.
If we really cared we could dump it to disk, use the command line "convert" tool to rescale it to a sane size, then load the output into the GD library and remove the temporary file.
convert -define jpeg:size=800x800 tmpfile.jpg -thumbnail '800x800' -
Will scale the image so it fits within an 800 x 800 square. It's longest edge is now 800px which should safely load. The above command will send the shrunk .jpg to STDOUT. The size= option should tell convert not to bother holding the huge image in memory, but just enough to scale to 800x800.
I've run into the same problem a few times.
One of my solutions was simply to increase the amount of memory available to my scripts. The other was to clear the buffer:
Original Script:
$src_img = imagecreatefromstring($userfile2);
imagecopyresampled($dst_img,$src_img,0,0,0,0,$thumb_width,$thumb_height,$origw,$origh);
Edited Script:
$src_img = imagecreatefromstring($userfile2);
imagecopyresampled($dst_img,$src_img,0,0,0,0,$thumb_width,$thumb_height,$origw,$origh);
imagedestroy($src_img);
By clearing out the memory of the first src_image, it freed up enough to handle more processing.