Files on unix are assigned to index-nodes which may vary in layout and content among differnt systems. Usually, there must be common elements across the different implementations. Which are those ?
Normally, the following elements should be available:
Filetype, 9 RWX permission bits
Number of references to the file
Owner's identity
Owner's group
File size in bytes
13 device addresses
last read date/time
last write date/time
last i-node modification date/time
Related
on Flyway deployment script name starts with a version.
What is the maximum length one can use? I see that on the table column holding the version is 50 character long
There are a number of limits:
Version must be 50 characters or less
Description must be 200 characters or less
Migration filenames must be compatible with any OS limit
Do you have a specific use case for a version string longer than 50 characters? We're in the middle of work for Flyway 7 and this is a chance for us to change the history table if there's a good reason to do so.
If you read the documentation located here, you'll find that the limit is not one from Flyway. Rather, your limit on the length of the version is based on the OS and it's limit on the size of a file name. You must ensure that you're incrementing your numbers in an appropriate order. However, as you can see in the docs, Flyway supports a wide variety of formats, and the length of your string defining the version number is not an issue you need to worry about.
Eg. for segmentation, 0000:FFFF is equivalent to 0001:FFEF (Just a hypothetical case, don't know if we really use these in programming or if these are reserved spaces)
(I am new to assembly programming. Specifically x86.)
Yes, this is allowed. In fact, not only is this legal, it's also frequently used for a feature known as shared memory.
0000:FFFF is equivalent to 0001:FFEF only in real mode, VM86 mode, or SMM mode. In these modes, by definition, paging is not enabled. In protected mode1 without paging, they are necessarily translated to different physical addresses because the segment offsets are different (FFFF vs. FFEF) but the segment base address is the same2. With paging, when the segment offsets get added to the segment base address (which could be zero), they may either point to the same virtual page or different virtual pages, but either way, the the least 12 significant bits of the page offsets would be different (because the least 12 significant bits of the segment offsets are different) and so they cannot be equivalent irrespective of how the page tables are set up.
In general, different addresses may translate to the same physical address. When the page offsets are different but the least significant 12 bits are same nonetheless, it is possible for the logical addresses to get translated to the same physical addresses when they point to pages of different sizes. Otherwise, if at least one of the least significant 12 bits is different in the virtual addresses, they cannot be equal in the physical address space.
In protected mode, the segment selector 0000'0000'0000'00XXb is used as null segment selector and cannot be accessed. But Let's assume for the sake of argument that it is accessible (or consider 0000'0000'0000'0100b vs. 0000'0000'0000'0101b instead).
They refer to the same segment because the segment selector indices (the most significant 13 bits of each selector) and table indicators (the third least signficant bit) are equal
I am using connect direct with scp and trying to send some pdf files from unix to mainframes.
On unix end, I have archive containing pdfs which I am simply renaming to ABC.XYZ.LMN.PQR (mainframe file name) and then sending to mainframe.
The archive contains variable length pdf files.
However, the requirement is:
For any variable length file mainframe needs to know the maximum possible length, of any record in the file. For e.g. say the LRECL is 1950.
How to include LRECL as well when the pdf files inside the archive file to be sent is of variable length ?
An alternative would be to transfer the files to a Unix System Services file (z/OS Unix) instead of a "traditional" z/OS dataset. Then the folks on the mainframe side could use their utilities to copy the file to a "traditional" mainframe dataset if that's what they need.
For Variable Blocked datasets Only! If your maximum record size is 1950 you will want to specify RECFM=VB,LRECL=1954 adding 4 bytes more than your maximum record. This 4 byte allowance is for the Record Descriptor Word (RDW). If you need to specify BLKSIZE then the minimum is the size of LRECL plus another 4 bytes.
So in your example, your JCL will have DCB parameters that looks like: RECFM=VB,LRECL=1954,BLKSIZE=1958
Ideally, for optimal storage, BLKSIZE should be set to the largest size that does not exceed the device specific recommendation. i.e. TAPE devices typically try to use BLKSIZE=32670 (32 * 1024K - 8 for RDW & BDW). Disk drives may vary but in our shop BLKSIZE=23476 is considered optimal.
Incorrect blocking factors can waste tremendous amounts of space. When in doubt, let your system defaults apply or consult with your local system guru's for their device specific recommendations.
I am writing an application which uses the DCM MKDIR, We save our images in little bigger name, but when I am trying to use the DCMMKDIR application, which is asking me to input file name max 8 characters.
Presently, I am planning to rename my Images starting from 1 to N. But remapping these images to known names(on the disk) will be bit difficult(I feel).
are there are any other methods/process to achieve the same.
The restriction of the filename to eight characters is derived from the DICOM Standard to ensure compatibility with applications that support e.g. only ISO 9660 as a file system for CDs.
About the naming you can have a look at the specifications the german CD Testat (http://www.dicom-cd.de/docs/DRG-RequirementsSpecification-2006.pdf). As a vendor you can be certified to conform to certain standards for interoperability of patient CDs which is currently the most common usage of DICOMDIRs.
The DICOMDIR file generated by DCMMKDIR is mainly a kind of index to tell an application, what DICOM files in a certain directory exist and this kind of file structure is usually more common for transfer media.
It is very common to use subdirectories to circumvent the restriction on max 8 length filenames. For example, a file could be 20110331/183421/000001 which would identify it properly with date, time and index without exceeding the somewhat arcane filename limit.
Is there a maximum lengh for a file extension? The longest one I've seen is .compiled (8 chars)
Useless Background
I'm creating a IHttpHandler to return image icons for a specific filename. I'm simply calling a FileImage.axd?ext=pptx. I'm generating the files on the fly using SHGetFileInfo similar to my post for WPF, then caching them locally in a folder with the filename 'pptx.png'. I'd like to validate the length and trim it to prevent a DoS type attack where someone would try to generate images for and infinite number of junk characters (eg FileImage.axd?ext=asdfasdfweqrsadfasdfwqe...).
As far as I know, there is no limit, except the maximum length of the file name. Extension is not treated specially except in FAT16.
I agree with Arkadiy - there is no formal limit now that the DOS 8.3 system is a thing of the past (or other similar, limited systems). I would say that the majority of the extensions I've seen are in the range 1-3; Java uses 4 for .java and 5 for .class. Your example with 8 is longer than I recall. If I were scoping, I'd aim for 'unlimited'; if that's not feasible, allow at least 16 characters - with the confident expectation that in fact 16 would be quite sufficient for current systems.