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, <valdis.kletnieks@xxxxxx> 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]=44318cacd823951e3359ae4b5dba06 b5383df1f4, 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 Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
