文件是如何存储的

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

从原理上讲，硬盘保存文件就如同录音磁带、录像磁带保存音频视频一样，都是磁记录，无非一个是运动的磁带，一个是旋转的磁盘。
从形式上说，无论什么性质的文件，保存到磁盘上的最终形式都是一连串的二进制数据，也就是类似于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的高速度和外存储器的低速度是微机系统工作过程中的主要瓶颈现象，不过由于硬盘的存取速度不断提高，目前这种现象已有所改善。