Skip to main content
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: Text file size changes to 1 byte despite adding only 1 bit 🤔 (Read 748 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Text file size changes to 1 byte despite adding only 1 bit 🤔

 
  Hello I have a big IT existential questionâť“ Saw that an initial empty text file 0 byte in size, when I add only 1 bit (either a 1 or a 0)
  the size of the file changes  to 1 byte instead of 1 bit that supposedly I've just added. 

   At first I've speculated that because of the OSI model the OS adds or better said makes another 7 copy of that bit that makes them
  available for those famous 7 different OSI layer and so that 1 bit + 7 makes 8 bit so the file size shows 1 byte in the end.

   But now going further with my hypothesis that kinda make sense I've thought that having an empty 0 byte text file since it doesn't
  make any bits available for those 7 layers must be only somewhere at the physical layer on the disk and because of that you can't
  even send over the network a 0 byte empty file since on the network/transport layer doesn't have that bit copy so tried to verify this
  theory and indeed could not send it over the internet to filepost.io but worked with xmpp or pleroma.

  Now having mixed results I'm inclined to discard altogether my whole idea but now I'm back to square one  :o . So how really things go
 for real down there, from where it gets those extra bits if those 7 bits do not come from the OS's OSI layers? My other assumtion was
 that thunar file manager might show bytes instead of bits. Anyone has an idea what's going on with this bytes/bits? Thanks
 
 

Re: Text file size changes to 1 byte despite adding only 1 bit 🤔

Reply #1
The byte (8 bits) is the smallest addressable size of data.  There cant be file sizes other than byte aligned.  You cant add a bit of data, its going to be a byte.  c, assembler, and other programming languages access data as bytes (nothing smaller).  Individual bits can then be manipulated within code, but the data I/O is still by byte.

The byte is like the quantum of data, at least on standard/traditional "computer" hardware.

Re: Text file size changes to 1 byte despite adding only 1 bit 🤔

Reply #2
 
 Yes this answer of yours @dxrobertson  is somewhat revealing but still the question persists why? Why it allocates for each 1 bit another 7 bits even
 though those 7 bits do not have anything related with my first assumption linked with the OSI model.

  If we always have 8 bits or 1 byte as the smallest size aren't things inefficient? Why use an 8 bit cell when the raw data is just 1 bit
 in size? Also that 1 bit is copied thru each of those 8 smaller cells in order for data not get lost/corrupted or that bit is simply
 somewhere inside that 1 byte without any importance?

 If we have an 8GB folder full of pictures the raw data is in fact 8x smaller, meaning 1GB?

 And returning to my 0 byte text file, where it stores its metadata (time of creation/name/permissions/etc) if the size is simply 0 byte?


Re: Text file size changes to 1 byte despite adding only 1 bit 🤔

Reply #3
Getting into hardware now, which is beyond my full understanding.  But the byte data size extends into the underlying hardware.  The storage, bus activity, and whatever else is done by bytes within the CPU and related hardware.

It would be less efficient to have bit level processing as opposed to byte.   With bit, you would have to provide addressing down to a single bit instead of 8 bits/byte.  That would require much larger addressing registers and addresses.  I would think the data IO/transmission would be much slower having to account for each bit.

At the hardware level there is an error correction bit and associated routine to keep the data correct.  I have forgotten how all this works, from way back in college.

A bit turned on = 1.  Its stored in a byte as a byte 1 = 00000001. 

No, the 8GB is 8GB. 

The file attributes such as permissions, etc are stored in addition to the actual file contents, something about "inodes".  These attributes are stored/controlled by the file system.  You can use the stat command to view that info.


 


Re: Text file size changes to 1 byte despite adding only 1 bit 🤔

Reply #4
 
   Think I got it thanks so when we edit an empty text file and add a 1 or a 0 we add a byte not a bit so the system does not
  append anything to that data is just the way it structures it in bytes not in bits.

   Now switching to the ASLR for a moment (Address Space Layout Randomization), linux kernel  main executable randomization
  as example (ET_EXEC)  has 28 quality bits (guessed) how can it deal with 28 bits cos 28 doesn't divide by 8 so it gives 3.5 bytes.

   Is in fact the system allocates a little more like 32 bits or 4 byte in memory when talking about those 28 quality bits or how it deals
  with that? And tnx again!  :)



Re: Text file size changes to 1 byte despite adding only 1 bit 🤔

Reply #5
Sorry, cant offer any assistance with kernel addressing.  I get a headache just thinking about memory mapping,  virtualization, etc.

Re: Text file size changes to 1 byte despite adding only 1 bit 🤔

Reply #6

   Haha, no problem it's OK just trying to figure out some of the basics. Another one that intrigues me is why we are not using hex
 instead of binary. At the beginning in 1960  it was OK binary but why experimenting so little with decimal or hex. Would not be hex
 more efficient?
  
  From what I see at the moment we are amazed by the quantum computer but a hex based processor wouldn't be better?


Re: Text file size changes to 1 byte despite adding only 1 bit 🤔

Reply #7
One can use hexadecimal whenever they like.  Hex is merely an interpretation of the underlying binary format.  You look at binary and see 0s and 1s, difficult to understand.  "put on your HEX glasses"  and view the binary data as values from  0  to  F, for each "nibble" half byte; 00 to FF for the full byte. 

Hex values are from  0 to F; decimal 0 to 9, plus A to F for the 6 additional values a 4 bit nibble allows over decimal 0-9.

Traditional computer byte is represented in HEX as 2 HEX "digits"; 00-FF.

Re: Text file size changes to 1 byte despite adding only 1 bit 🤔

Reply #8

  That's interesting. But couldn't we make for example for the octa-core processor something like on core #1   0=0, 1=1 ; core #2  0=2, 1=3 ; core #3 0=4, 1=5........and last would be core #8 0=E, 1=F

  Conversely when the OS send data to be processed, an E for the core#8 would be send by the OS as being 0 and an F as 1. We would speculate the fact that the OS being smarter/more versatile than the limitations of the binary language of the processor, OS can interpret binary in hex and feed the processor its beloved ZEROES and ONES. Now I agree that for this thing to happen for a short time after reboot till the OS-CPU settles down to start talking binary -> hex and hex -> binary, more likely the system has to operate as we know it.

   The way is now, the OS despite the fact is way out more versatile it doesn't use the advantage of being versatile and still uses the very limited/inefficient binary language.

   This way we would not touch the binary part that our current processors are kinda forever in love with but from there upward the OS would speak hex that's more efficient.
 
   cos      0123456789ABCDEF                             means                                                         16 binary bytes 
   but same in data in binary is
  100100011010001010110011110001001101010111100110111110000       57 binary bytes (takes about 3.5x more space)

   My hopefully educated guess is that a quantum computer would be simply 2x weaker than a binary-hex polyglot OS (described above) and a classical machine would be 4x weaker..(just a raw appreciation)

   Also after watched this video i've learned that a hex processor would need 4x less transistors inside a CPU (that would be fully hex based)

   Now I'm no computer scientist but just a construction engineer so grain of salt is mandatory on this particular topic, just trying to use some common sense. @dxrobertson Tnx once again taking the time to figure out this less debated topics.