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