Thanks Manish, Jim.. Thanks Valdis, .. learnt good deal. I will check further regarding the file&tar example and revert back if further queries. Thanks again.
Best regards Sekar On Jan 18, 2018 2:38 AM, <[email protected]> wrote: > On Wed, 17 Jan 2018 21:35:13 +0530, inventsekar said: > > > On the header file, it defines the fs magic number as > > #define UX_MAGIC 0x58494e55 > > > > 1. which means, will it assign this magic number to ALL files created on > > this sample fs? That can't be so. Otherwise, why we need to define a > magic > > number? > > That's not a file magic number, that's a filesystem superblock magic > number. > > That appears just once in the filesystem, usually in/near the superblock. > It's only > reason for existence is so things like fsck can read in the superblock, > and do a: > > if (superblock.magic != UX_MAGIC) { > printf("I see no UX filesystem here!\n); > exit(1); > } > > > 2. I assume, magic number will be assigned to files by the tools which we > > use to create the files(like vi, cat, etc). Is this correct? > > No, it's scribbled into the superblock by mkfs > > > 3. It seems, windows files also have the magic numbers. let's say I copy > > some files from windows to Linux. We should have the common magic numbers > > between different Operating systems, so there won't be confusions. I > mean, > > is there any standards common for all os's files magic numbers?!? > > Well, since file magic numbers are different from filesystem magic numbers, > and a Windows box is probably never going to be able to mount an ext4 > filesystem(footnote *), it's probably mostly irrelevant. And things like > tar's magic number, > only matter to /usr/bin/tar and /usr/bin/file... > > See /usr/share/misc/magic (or wherever your system's /bin/file command > stashes > the file - that's the list of magic numbers that 'file' uses to do stuff > like this: > > % file /bin/bash ./bmap-1.0.20.tar.gz > /bin/bash: ELF 64-bit LSB shared object, x86-64, version 1 > (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for > GNU/Linux 3.2.0, BuildID[sha1]=44318cacd823951e3359ae4b5dba06b5383df1f4, > stripped > ./bmap-1.0.20.tar.gz: gzip compressed data, last modified: Tue Jan 23 > 17:40:23 2007, from Unix > > (blast from the past entry in there: > > ##---------------------------------------------------------- > -------------------- > ## $File: alliant,v 1.7 2009/09/19 16:28:07 christos Exp $ > ## alliant: file(1) magic for Alliant FX series a.out files > ## > ## If the FX series is the one that had a processor with a 68K-derived > ## instruction set, the "short" should probably become "beshort" and the > ## "long" should probably become "belong". > ## If it's the i860-based one, they should probably become either the > ## big-endian or little-endian versions, depending on the mode they ran > ## the 860 in.... > ## > 0 short 0420 0420 Alliant virtual executable > >2 short &0x0020 common library > >16 long >0 not stripped > 0 short 0421 0421 Alliant compact executable > >2 short &0x0020 common library > >16 long >0 not stripped > > The Alliant was a machine that I worked on at my previous job. I'm coming > up on 29 years in my current job, it's unclear whether there are any > Alliant > a.out files to be found anyplace.. > > Though the fact that it also knows about gzip files created on TOPS-20 is > pretty trippy too.... > > (footnote *) It's been attempted, and the filesystem gods did heavily > smite the programmer > for their arrogance. :) >
_______________________________________________ Kernelnewbies mailing list [email protected] https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
