文件是如何存儲的

Ⅰ 文件是以怎樣的形式（原理）保存在硬碟里的

從原理上講，硬碟保存文件就如同錄音磁帶、錄像磁帶保存音頻視頻一樣，都是磁記錄，無非一個是運動的磁帶，一個是旋轉的磁碟。
從形式上說，無論什麼性質的文件，保存到磁碟上的最終形式都是一連串的二進制數據，也就是類似於00010010101101001111001這樣的數據。

Ⅱ 在電腦上怎樣保存文件

電腦文件保存操作其實很簡單，只需要點擊「另存為」彈出對話框保存即可，也可以直接按住快捷鍵「ctrl」加「S」鍵進行保存文件。以電腦記事本的文件為例，具體操作方法如下：

1、在電腦記事本上輸入完內容之後，點擊左上角的「文件」按鈕；

2、在彈出的菜單欄裡面，點擊「另存為」這一選項，就會跳轉到另存為界面；



3、在另存為界面輸入文件名，以及把文檔類型設置為「txt」的格式即可；

4、或者在完成內容輸入以後，直接點擊快捷鍵「ctrl」加「S」鍵保存即可。

如果是word文檔或者是excel表格類的文件，其操作方法與記事本相似，也是點擊左上角的「文件」按鈕，在選擇「另存為」進行保存，同樣也可以使用快捷鍵「ctrl」加「S」進行保存。

Ⅲ 2020-12-02 硬碟如何存儲文件

系統中所有內容是以文件（文件夾是特殊的文件）存在的，而文件分為屬性（元信息）和內容兩部分，磁碟一部分被操作系統虛擬為塊用來存儲數據，同時也分出一部分虛擬為Inode用來存儲文件屬性，這樣磁碟就分為塊區和inode區。

扇區：磁碟存儲數據的最小物理單元，每個扇區很小512位元組左右。
讀取數據：OS要想讀取磁碟數據，首先讓磁頭徑向尋道（最慢），然後旋轉磁碟（較快），使磁頭到達目標扇區，開始讀取數據。

磁碟塊：OS日常工作中，一個扇區的512位元組數據很小，不足以支撐絕大部分工作場景，所以需要頻繁讀取單個扇區，而磁碟讀取數據速度相對CPU處理太慢了，所以讀磁碟時一次就多拿出幾個扇區（臨近的，無需耗費額外時間）的數據，於是在OS層面邏輯虛擬出磁碟塊（簇）的概念，一個磁碟塊一般對應8個連續扇區（也可4、16個等，由OS決定），這樣OS層面就使用磁碟塊作為最小數據存儲單元。
這樣的好處當然是更高效，缺點則是會？

inode：用於存儲文件的元信息（除名稱外的所有屬性，名稱存在文件夾的內容中）
Inode number is also known as index number. An inode is a unique number assigned to files and directories while it is created. The inode number will be unique to entire filesystem.

Disk inodes contain the following information:

Owner identifier
Type of file (regular, directory, character or block device)
Access permissions
Times and dates
· file creation time

· last file access time

· last inode modification time

Number of links to the file
Array of pointers to data blocks on disk
File size (in bytes, sometimes also in blocks)

文件：
上文提及文件屬性存在磁碟inode區的inode（每個都有編號）內，而內容存儲在塊區的塊中。

文件夾：
作為特殊文件，其組織文件及目錄，屬性也是存在inode內，而存儲的內容是一個包含多個{ 文件名:對應inode Id} 的列表，內容亦存在塊區的塊中。

這樣在OS中查看一個文件（比如/etc/fstab）的內容，大概是：
首先OS獲取到根目錄的inodeId >在inode區中讀取到其屬性（某項是內容所在塊）>在塊區讀取到根目錄內容>在內容中找到名為/etc對應發inodeId>/etc在inode區的屬性>讀取到塊中/etc的內容（包含/etc/fstab對應inodeId）>/etc/fstab Inode Id > 在inode區讀取到/etc/fstab屬性 >/etc/fstab塊。

可能有誤，望指點。

Within each file system, the mapping from names to blocks is handled through a structure called an i-node. There's a pool of these things near the "bottom" (lowest-numbered blocks) of each file system (the very lowest ones are used for housekeeping and labeling purposes we won't describe here). Each i-node describes one file. File data blocks (including directories) live above the i-nodes (in higher-numbered blocks).

Every i-node contains a list of the disk block numbers in the file it describes. (Actually this is a half-truth, only correct for small files, but the rest of the details aren't important here.) Note that the i-node does not contain the name of the file.

Names of files live in directory structures. A directory structure just maps names to i-node numbers. This is why, in Unix, a file can have multiple true names (or hard links); they're just multiple directory entries that happen to point to the same i-node.

refer: https://unix.stackexchange.com/questions/432655/why-does-using-indirect-pointers-in-inodes-not-incur-the-same-amount-of-space

less:by direct list blocks in node?.
large :by two-level indirect block
larger : multi-level indirect block.

The original hierarchy of the inodes levels works roughly like this:

You can store one or a few block numbers directly in the inode. This means you use a few bytes more for the inode, but for small files, you don't have to allocate a complete block, which is mostly empty.

The next level is one indirection: You allocate a block to store the block pointers. Only the address of this indirect block is stored in the inode. This doesn't use somehow "less space", and most filesystems, even early ones, worked like that (have a pointer near the inode/filename which points to a block, which stores the block numbers of the file).

But what do you do when the space in this block runs out? You have to allocate another block, but where do you store the reference to this block? You could just add those references to the inode, but to store largers files, the inode would get large. And you want small inodes, so as many as possible inodes can fit into a single block (less disk access to read more inodes).

So you use a two-level indirect block: You just add one pointer to the inode, then you have a whole block to store pointers to indirect blocks, and the indirect blocks store the block address of the file itself.

And so on, you can add higher-level indirect blocks, or stop at some stage, until you reach the maximal size of a file possible with the structure you want.

So the point is not "use up less space in total", but "use a scheme that uses blocks efficiently for the expected distribution a files wrt. to size, i.e. many small files, some larger files, and very few huge files".

Page tables on the other hand work very differently.

Edit

To answer the questions in the comment:

Data blocks are of fixed sizes (originally 512 bytes, IIRC), which is a multiple of the block size of the underlying harddisks. So data block size can't "decrease".

As I tried to describe above, the whole point of having the inodes not use up too much space is to make inode access faster (or, alternatively, make caching inodes use up less memory - back then when the unix file system with inodes was invented, computers had a lot less memory than today). It's not about somehow saving space in total. As you say yourself, everything has to be stored somewhere, and if it doesn't use up space at location X, it will use up space at location Y.

Just adding a variable number of block pointers to the inode is not practical, because the inode must take up a fixed amount of space - you want to use the inode number to calculate the block address and the offset inside the block where the inode information is stored. You can't do that if every inode has a different size. So there must be some form of indirection.

Page tables work differently because hardware implements them differently - that's just how it is. The hierarchy has a fixed depth, always the same (though sometimes configurable. And while reading a block from disk is slow, that doesn't matter for page tables. So the design issues are completely different.

http://www.cems.uwe.ac.uk/~irjohnso/coursenotes/lrc/internals/filestore/fs3.htm

Assuming, for the purposes of illustration, that each disk data block is 1024 bytes in size, then these ten data block pointers will allow files to be created that are up to 10 Kb in size. As you can see, for the large majority of files it should be possible to access the data with nothing more than a direct lookup required to find the data block that contains any particular data byte.

With this scheme, once a file has grown to 10 Kb, there are only three block pointers in the inode left to use, whatever the eventual size of the file. Obviously, some new arrangement must be found so that the three remaining block pointers will suffice for any realistic file size, while at the same time not degrading the data access time too much.

This goal is achieved by using the idea of indirect block pointers. Specifically, when an 11th data block needs to be allocated to the file, the 11th inode block pointer is used, but instead of pointing to the block which will contain the data, the 11th pointer is a single indirect pointer which points to a data block filled with a list of direct block pointers. In our example, if we assume that a data block number is a 32-bit value, then a list of 256 of them will fit into the single indirect block. This list will point directly to the data blocks for the next 256 Kb of our file. This means that with 11 block pointers in the inode, files of up to 266 Kb (10 + 256) can be created. True, it takes a little longer to access the data beyond the first 10 Kb in the file, but it takes only one extra disk block read to find the position on the disk of the required data.

For files bigger than 266 Kb the double indirect (12th) inode block pointer is used. This is the same idea as the previous inode pointer except that the double indirect pointer points to a list of pointers in a data block, each of which is itself a single indirect block pointer which points to a list of 256 direct block pointers. This means that the 12th inode block pointer gives access to the next 65536 Kb (256x256) of data in our file.

By now, you should be able to spot the pattern and see that when the file grows bigger than 64 Mb (actually 65802 Kb), the inode's 13th data block pointer will be used, but this time as a triple indirect pointer, which will give access to a staggering 16 Gb (256x256x256 Kb) of extra file space. A single file bigger than 16Gb sounds huge. However, even though the calculation we have just done suggests that this file size is possible with the inode layout as given, in fact there are other factors which limit the maximum size of a file to a smaller value than this. For example, the size of a file, in bytes, is stored separately in its inode in a field of type unsigned long. This is a 32-bit number which limits the size of a file to 4 Gb, so that 13 data block pointers in an inode really are enough.

10.4. How a file gets looked up
Now we can look at the file system from the top down. When you open a file (such as, say, /home/esr/WWW/ldp/fundamentals.xml) here is what happens:

Your kernel starts at the root of your Unix file system (in the root partition). It looks for a directory there called 『home』. Usually 『home』 is a mount point to a large user partition elsewhere, so it will go there. In the top-level directory structure of that user partition, it will look for a entry called 『esr』 and extract an i-node number. It will go to that i-node, notice that its associated file data blocks are a directory structure, and look up 『WWW』. Extracting that i-node, it will go to the corresponding subdirectory and look up 『ldp』. That will take it to yet another directory i-node. Opening that one, it will find an i-node number for 『fundamentals.xml』. That i-node is not a directory, but instead holds the list of disk blocks associated with the file.

The surface area of your disk, where it stores data, is divided up something like a dartboard — into circular tracks which are then pie-sliced into sectors. Because tracks near the outer edge have more area than those close to the spindle at the center of the disk, the outer tracks have more sector slices in them than the inner ones. Each sector (or disk block ) has the same size, which under modern Unixes is generally 1 binary K (1024 8-bit bytes). Each disk block has a unique address or disk block number .

Unix divides the disk into disk partitions . Each partition is a continuous span of blocks that's used separately from any other partition, either as a file system or as swap space. The original reasons for partitions had to do with crash recovery in a world of much slower and more error-prone disks; the boundaries between them rece the fraction of your disk likely to become inaccessible or corrupted by a random bad spot on the disk. Nowadays, it's more important that partitions can be declared read-only (preventing an intruder from modifying critical system files) or shared over a network through various means we won't discuss here. The lowest-numbered partition on a disk is often treated specially, as a boot partition where you can put a kernel to be booted.

Each partition is either swap space (used to implement virtual memory ) or a file system used to hold files. Swap-space partitions are just treated as a linear sequence of blocks. File systems, on the other hand, need a way to map file names to sequences of disk blocks. Because files grow, shrink, and change over time, a file's data blocks will not be a linear sequence but may be scattered all over its partition (from wherever the operating system can find a free block when it needs one). This scattering effect is called fragmentation .

Within each file system, the mapping from names to blocks is handled through a structure called an i-node . There's a pool of these things near the "bottom" (lowest-numbered blocks) of each file system (the very lowest ones are used for housekeeping and labeling purposes we won't describe here). Each i-node describes one file. File data blocks (including directories) live above the i-nodes (in higher-numbered blocks).

Every i-node contains a list of the disk block numbers in the file it describes. (Actually this is a half-truth, only correct for small files, but the rest of the details aren't important here.) Note that the i-node does not contain the name of the file.

Names of files live in directory structures . A directory structure just maps names to i-node numbers. This is why, in Unix, a file can have multiple true names (or hard links ); they're just multiple directory entries that happen to point to the same i-node.

In the simplest case, your entire Unix file system lives in just one disk partition. While you'll see this arrangement on some small personal Unix systems, it's unusual. More typical is for it to be spread across several disk partitions, possibly on different physical disks. So, for example, your system may have one small partition where the kernel lives, a slightly larger one where OS utilities live, and a much bigger one where user home directories live.

The only partition you'll have access to immediately after system boot is your root partition , which is (almost always) the one you booted from. It holds the root directory of the file system, the top node from which everything else hangs.

The other partitions in the system have to be attached to this root in order for your entire, multiple-partition file system to be accessible. About midway through the boot process, your Unix will make these non-root partitions accessible. It will mount each one onto a directory on the root partition.

For example, if you have a Unix directory called <tt class="filename">/usr</tt>, it is probably a mount point to a partition that contains many programs installed with your Unix but not required ring initial boot.

Ⅳ 怎樣將文件保存在文件夾中

1、如果微信收到文件，滑鼠右鍵點擊文件，然後選擇另存為。

Ⅳ 計算機是怎樣存儲文件的呢

DOS的組成及啟動過程:引導程序：磁碟格式化時，將引導程序復制到軟盤的0道1扇區（硬碟的DOS分區的1柱面1扇區）；啟動時，由ROM將引導程序裝入內存（後者將DOS其餘部分裝入內存）

IO.SYS（IBMBIO.COM）：與基本輸入輸出系統（BIOS）的介面程序.

MSDOS.SYS（IBMDOS.COM）：為DOS的核心，提供文件目錄管理、內存管理、對實時鍾的訪問、字元設備輸入輸出等功能.

2.可執行文件：包含了計算機執行特定任務的程序指令，如
字處理程序。擴展名為.com 和.exe

3 3.3 計算機如何存儲文件數據
􀂃 磁技術和光技術
􀂃 磁存儲通過磁化磁碟或磁帶表面上細小的粒子來存儲數據。
在數據沒有變化時，粒子方向不會變化。磁設備成為長期，
但可更改的存儲介質

光存儲設備：把數據存儲
為細小的亮點或黑點，用
反射的激光來讀取數據

Ⅵ 電腦如何保存文件

具體操作步驟如下：

以Word為例：

1、首先打開電腦，點擊打開需要編輯的Word。

Ⅶ 存儲器對文件是怎樣存儲的機制是什麽

存儲器分為內存儲器（簡稱內存或主存）、外存儲器（簡稱外存或輔存）。外存儲器一般也可作為輸入/輸出設備。計算機把要執行的程序和數據存入內存中，內存一般由半導體器構成。半導體存儲器可分為三大類：隨機存儲器、只讀存儲器、特殊存儲器。
RAM
RAM是隨機存取存儲器（Random Access Memory），其特點是可以讀寫，存取任一單元所需的時間相同，通電是存儲器內的內容可以保持，斷電後，存儲的內容立即消失。RAM可分為動態（Dynamic RAM）和靜態（Static RAM）兩大類。所謂動態隨機存儲器DRAM是用MOS電路和電容來作存儲元件的。由於電容會放電，所以需要定時充電以維持存儲內容的正確，例如互隔2ms刷新一次，因此稱這為動態存儲器。所謂靜態隨機存儲器SRAM是用雙極型電路或MOS電路的觸發器來作存儲元件的，它沒有電容放電造成的刷新問題。只要有電源正常供電，觸發器就能穩定地存儲數據。DRAM的特點是集成密度高，主要用於大容量存儲器。SRAM的特點是存取速度快，主要用於調整緩沖存儲器。
ROM
ROM是只讀存儲器（Read Only Memory），它只能讀出原有的內容，不能由用戶再寫入新內容。原來存儲的內容是由廠家一次性寫放的，並永久保存下來。ROM可分為可編程（Programmable）ROM、可擦除可編程（Erasable Programmable）ROM、電擦除可編程（Electrically Erasable Programmable）ROM。如，EPROM存儲的內容可以通過紫外光照射來擦除，這使它的內可以反復更改。
特殊固態存儲器
包括電荷耦合存儲器、磁泡存儲器、電子束存儲器等，它們多用於特殊領域內的信息存儲。
此外，描述內、外存儲容量的常用單位有：
①位/比特（bit）：這是內存中最小的單位，二進制數序列中的一個0或一個1就是一比比特，在電腦中，一個比特對應著一個晶體管。
②位元組（B、Byte）：是計算機中最常用、最基本的存在單位。一個位元組等於8個比特，即1 Byte＝8bit。
③千位元組（KB、Kilo Byte）：電腦的內存容量都很大，一般都是以千位元組作單位來表示。1KB＝1024Byte。
④兆位元組（MB Mega Byte）：90年代流行微機的硬碟和內存等一般都是以兆位元組（MB）為單位。1 MB＝1024KB。
⑤吉位元組（GB、Giga Byte）：目前市場流行的微機的硬碟已經達到4.3GB、6.4GB、8.1GB、12G、13GB等規格。1GB＝1024MB。
⑥太位元組（TB、Tera byte）：1TB＝1024GB。
（三）輸入/輸出設備
輸入設備是用來接受用戶輸入的原始數據和程序，並將它們變為計算機能識別的二進制存入到內存中。常用的輸入設備有鍵盤、滑鼠、掃描儀、光筆等。
輸出設備用於將存入在內存中的由計算機處理的結果轉變為人們能接受的形式輸出。常用的輸出設備有顯示器、列印機、繪圖儀等。
（四）匯流排
匯流排是一組為系統部件之間數據傳送的公用信號線。具有匯集與分配數據信號、選擇發送信號的部件與接收信號的部件、匯流排控制權的建立與轉移等功能。典型的微機計算機系統的結構如圖2-3所示，通常多採用單匯流排結構，一般按信號類型將匯流排分為三組，其中AB（Address Bus）為地址匯流排；DB(Data Bus)為數據匯流排；CB（Control Bus）控制匯流排。
（五）微型計算機主要技術指標
①CPU類型：是指微機系統所採用的CPU晶元型號，它決定了微機系統的檔次。
②字長：是指CPU一次最多可同時傳送和處理的二進制位數，安長直接影響到計算機的功能、用途和應用范圍。如Pentium是64位字長的微處理器，即數據位數是64位，而它的定址位數是32位。
③時鍾頻率和機器周期：時鍾頻率又稱主頻，它是指CPU內部晶振的頻率，常用單位為兆（MHz），它反映了CPU的基本工作節拍。一個機器周期由若干個時鍾周期組成，在機器語言中，使用執行一條指令所需要的機器周期數來說明指令執行的速度。一般使用CPU類型和時鍾頻率來說明計算機的檔次。如Pentium III 500等。
④運算速度：是指計算機每秒能執行的指令數。單位有MIPS（每秒百萬條指令）、MFLOPS（秒百萬條浮點指令）
⑤存取速度：是指存儲器完成一次讀取或寫存操作所需的時間，稱為存儲器的存取時間或訪問時間。而邊連續兩次或寫所需要的最短時間，稱為存儲周期。對於半導體存儲器來說，存取周期大約為幾十到幾百毫秒之間。它的快慢會影響到計算機的速度。
⑥內、外存儲器容量：是指內存存儲容量，即內容儲存器能夠存儲信息的位元組數。外儲器是可將程序和數據永久保存的存儲介質，可以說其容量是無限的。如硬碟、軟盤已是微機系統中不可缺少的外部設備。迄今為止，所有的計算機系統都是基於馮·諾依曼存儲程序的原理。內、外存容量越大，所能運行的軟體功能就越豐富。CPU的高速度和外存儲器的低速度是微機系統工作過程中的主要瓶頸現象，不過由於硬碟的存取速度不斷提高，目前這種現象已有所改善。