Обсуждение:Файл

message: А все забыли про "файл" - который вставляется в папку сделанный из полиэтилена :) --WiLD
replies: text: см. внимательно (Файл (значения)) ;) --Tpyvvikky 14:01, 12 февраля 2013 (UTC)

message: предлагаю определить файл, как поименованную упорядоченную последовательность данных. Текущее определение неполно, нечётко и самозависимо (блок - это что, файл без имени? как читать этот блок? а папка с документами - это что, не файл?) Mashiah 13:26, 11 сентября 2006 (UTC)
* Файл не обязательно является данными, в частности, в ряде случаев файл имеет смысл по факту своего существования (т.н. файловые флаги). Вопрос "что такое файл?" это известная кащенитская провокация в ru.os.cmp, т.к. никто до сих пор не смог дать точного определения.
Предлагаю:
# собрать определения из разных источников
# перечислить свойства файлов.
 #!George Shuklin 04:13, 21 ноября 2006 (UTC)
replies: text: Хорошая идея. 82.151.108.111 17:43, 10 апреля 2010 (UTC) 
Поддерживаю предложение. Мне нравится определение "Файл - совокупность данных, доступ к которой осуществляется по ее имени". --Savchenko Andrey 08:55, 23 декабря 2006 (UTC)

text: А кто сказал, что у файла есть имя? Доступ по номеру ничем не хуже (и во многих файловых системах был абсолютно нормальным). #!George Shuklin 23:05, 26 января 2007 (UTC)
replies: text: :Сейчас я вам расскажу, что такое файл! :) — Vano 20:39, 5 декабря 2007 (UTC)
replies: text: ::Ну вот. В таком виде (по памяти) нам его давал Восков Л.С. на лекциях по системному ПО. Наиболее общее и выделяет суть. — Vano 21:15, 5 декабря 2007 (UTC)
-----
Файл - совокупность данных, названных одним (общим) именем, и находящихся на носителе информации. 85.172.108.236 15:03, 21 марта 2009 (UTC)

text: Данных? А если данных нет? А как называются потоки у файлов на NTFS? (один файл, но несколько имён, указывающих на разные данные). А как называется файл, который не находится на носителе информации (/dev/*, /proc/*, etc)? #!George Shuklin 15:36, 21 марта 2009 (UTC)
* и куда это с чего это вдруг (ВНЕЗАПНО) "...на носителе информации" дели? -_о (файлы в ОЗУ уже хранятся, чтоль?) Tpyvvikky 00:30, 18 декабря 2010 (UTC)
=== Unix ===
 LSOF(8)                                                                LSOF(8)
 NAME
       lsof - list open files
 SYNOPSIS
       lsof  [  -?abChlnNOPRstUvVX  ]  [ -A A ] [ -c c ] [ +c c ] [ +|-d d ] [
       +|-D D ] [ +|-f [cfgGn] ] [ -F [f] ] [ -g [s] ] [ -i [i] ] [ -k k  ]  [
       +|-L  [l]  ]  [ +|-m m ] [ +|-M ] [ -o [o] ] [ -p s ] [ +|-r [t] ] [ -S
       [t] ] [ -T [t] ] [ -u s ] [ +|-w ] [ -x [fl] ]  [  -z  [z]  ]  [  --  ]
       [names]
 DESCRIPTION
       Lsof  revision  4.76  lists information about files opened by processes
       for the following UNIX dialects:
Выполняем
 $ lsof | grep -i x-chat
что мы видим:
каталог
 X-Chat    236 libc  cwd      DIR      14,3      272  2001499 /Applications/My/X-Chat Aqua
текстовый файл
 X-Chat    236 libc  txt      REG      14,3  4240132  2001535 /Applications/My/X-Chat Aqua/X-Chat Aqua.app/Contents/MacOS/X-Chat Aqua
Shared memory
 X-Chat    236 libc    3r  PSXSHM               4096          apple.shm.notification_center
Неименнованый PIPE
 X-Chat    236 libc   12     PIPE 0x2046a70    16384 
Сокет
 X-Chat    236 libc   25u    IPv4 0x208a228      0t0      TCP 192.168.1.3:49170->ircworld.ru:6667 (ESTABLISHED)
И это все файлы с точки зрения Unix
=== Свойства файлов ===
* файл может содержать в себе данные (а может и не содержать)
* файл может иметь одно или более имён (хардлинки), а может и не иметь имени вообще
* файл может иметь в себе пустые места (sparced)
* файл иногда может быть открыт fopen()
* файл иногда может быть закрыт fclose()
* некоторые файлы можно читать
* некоторые файлы можно fseek(), причём есть файлы, которые можно fseek() только вперёд
* некоторые файлы можно fwrite()
* У файла могут быть дополнительные потоки
* файл не обязательно где-то хранится (/dev/rand, dev/nul)
* файл не обязательно блочный (любое символьное устройство)
=== Об определении ===
Я выписал основные проблемы определений файлов в самой статье, надеюсь, это слегка поможет. #!George Shuklin 23:06, 26 января 2007 (UTC)
=== Структура статьи ===
Писать о файле - всё равно, что писать о компьютерах вообще - сумашедший объём данных.
Предположительная стркуктура статьи:
* Abstract
* Проблема точного определения
* Файл как объект файловой системы на носителе и файл как объект API.
* Всё - файл (концепция Unix)
* Типы файлов (символьные/блочные)
* Каталоги, структура дерева каталогов
* Свойства файлов как объектов файловой системы (атрибуты, sparced, хардлинки, и т.д.)
* Свойства файлов как объектов файлового АПИ (чтение/запись/fseek).
* Файлы устройств: в unix, в windows
* UNC-путь в Windows NT
* Файлы-контейнеры (архивы, loopback, ISO и т.д.)
* Проблемы сериализации данных в файл
* Версии файлов
* Файловые системы (обзор)
  #!George Shuklin 10:25, 1 марта 2007 (UTC)
=== требования к именам файлов ===
не согласен с отменой правки по поводу запрещённых символов в именах файлов. Цитирую по Библии MS-DOS Стивена Симрина: "Стpочные буквы в MS-DOS  интеpпpетиpуются как заглавные, поэтому  имя команды  и  паpаметpы  командной  стpоки  (в частности, имя файла) могут набиpаться  как  маленькими,  так  и  большими  буквами  (можно  вводить комбинацию из  стpочных и  заглавных букв)." Кроме того, приведенный мной список запрещённых символов был полным, а не то, что видим в данный момент. Возможно насчёт первой половины таблицы я загнул, но если отбросить запрещённые и упарвляющие символы (с кодом 0 - 31) - мы это и получим. Хотя можно конечно написать и так (цитата по Симрину):
Для обpазования имени файла может использоваться только  опpеделенный
набоp символов:
   буквы алфавита
   цифpы от 0 до 9
   специальные символы: $ # @ % ( ) - { } ` ' _ ^ ~
Возможно, чтобы избежать неоправданного расширения статьи, стоит вообще ограничиться фразой "Помимо ограничений файловой системы, интерфейсы операционной системы дополнительно ограничивают набор символов, который допустим при работе с файлами."
Tirthika 00:21, 7 ноября 2007 (UTC)
* Вы говорите о файловых вызовах (т.е. API). В этом случае просто все буквы приводятся к верхнему регистру (и вызывать функции работы с файлами можно действительно с любыми буквами). Если _создать_ файлы с маленькими буквами (diskedit или другая OS), то их будет невозможно прочитать из дос или выполнить любую операцию (известная проблема с записанными из виндов сидюками). Сейчас попробую найти источник... #!George Shuklin 04:52, 7 ноября 2007 (UTC) Во. KB от мелкософта должно быть достаточно убедительным : All characters in the MS-DOS character set must be in uppercase letters in accordance with the 8.3 file naming convention. И вот тоже: 
FAT Naming Convention
FAT uses the traditional 8.3 file naming convention and all filenames must be created with the ASCII character set. The name of a file or directory can be up to eight characters long, then a period (.) separator, and up to a three character extension. The name must start with either a letter or number and can contain any characters except for the following: 
   . " / \ [ ] : ; | = ,
				
If any of these characters are used, unexpected results may occur. The name cannot contain any spaces. 
The following names are reserved: 
   CON, AUX, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3, PRN, NUL
				
All characters will be converted to uppercase. 
Вы процитировали всё, кроме последней строчки :) #!George Shuklin 04:56, 7 ноября 2007 (UTC)
** Убедили ;) Tirthika 21:24, 7 ноября 2007 (UTC)
thread_title:  Определение 

message: LSOF(8)                                                                LSOF(8)
 NAME
       lsof - list open files
 SYNOPSIS
       lsof  [  -?abChlnNOPRstUvVX  ]  [ -A A ] [ -c c ] [ +c c ] [ +|-d d ] [
       +|-D D ] [ +|-f [cfgGn] ] [ -F [f] ] [ -g [s] ] [ -i [i] ] [ -k k  ]  [
       +|-L  [l]  ]  [ +|-m m ] [ +|-M ] [ -o [o] ] [ -p s ] [ +|-r [t] ] [ -S
       [t] ] [ -T [t] ] [ -u s ] [ +|-w ] [ -x [fl] ]  [  -z  [z]  ]  [  --  ]
       [names]
 DESCRIPTION
       Lsof  revision  4.76  lists information about files opened by processes
       for the following UNIX dialects:
Выполняем
 $ lsof | grep -i x-chat
что мы видим:
каталог
 X-Chat    236 libc  cwd      DIR      14,3      272  2001499 /Applications/My/X-Chat Aqua
текстовый файл
 X-Chat    236 libc  txt      REG      14,3  4240132  2001535 /Applications/My/X-Chat Aqua/X-Chat Aqua.app/Contents/MacOS/X-Chat Aqua
Shared memory
 X-Chat    236 libc    3r  PSXSHM               4096          apple.shm.notification_center
Неименнованый PIPE
 X-Chat    236 libc   12     PIPE 0x2046a70    16384 
Сокет
 X-Chat    236 libc   25u    IPv4 0x208a228      0t0      TCP 192.168.1.3:49170->ircworld.ru:6667 (ESTABLISHED)
И это все файлы с точки зрения Unix
thread_title:  Unix 

message: * файл может содержать в себе данные (а может и не содержать)
* файл может иметь одно или более имён (хардлинки), а может и не иметь имени вообще
* файл может иметь в себе пустые места (sparced)
* файл иногда может быть открыт fopen()
* файл иногда может быть закрыт fclose()
* некоторые файлы можно читать
* некоторые файлы можно fseek(), причём есть файлы, которые можно fseek() только вперёд
* некоторые файлы можно fwrite()
* У файла могут быть дополнительные потоки
* файл не обязательно где-то хранится (/dev/rand, dev/nul)
* файл не обязательно блочный (любое символьное устройство)
thread_title:  Свойства файлов 

message: Я выписал основные проблемы определений файлов в самой статье, надеюсь, это слегка поможет. #!George Shuklin 23:06, 26 января 2007 (UTC)
thread_title:  Об определении 

message: Писать о файле - всё равно, что писать о компьютерах вообще - сумашедший объём данных.
Предположительная стркуктура статьи:
* Abstract
* Проблема точного определения
* Файл как объект файловой системы на носителе и файл как объект API.
* Всё - файл (концепция Unix)
* Типы файлов (символьные/блочные)
* Каталоги, структура дерева каталогов
* Свойства файлов как объектов файловой системы (атрибуты, sparced, хардлинки, и т.д.)
* Свойства файлов как объектов файлового АПИ (чтение/запись/fseek).
* Файлы устройств: в unix, в windows
* UNC-путь в Windows NT
* Файлы-контейнеры (архивы, loopback, ISO и т.д.)
* Проблемы сериализации данных в файл
* Версии файлов
* Файловые системы (обзор)
  #!George Shuklin 10:25, 1 марта 2007 (UTC)
thread_title:  Структура статьи 

message: не согласен с отменой правки по поводу запрещённых символов в именах файлов. Цитирую по Библии MS-DOS Стивена Симрина: "Стpочные буквы в MS-DOS  интеpпpетиpуются как заглавные, поэтому  имя команды  и  паpаметpы  командной  стpоки  (в частности, имя файла) могут набиpаться  как  маленькими,  так  и  большими  буквами  (можно  вводить комбинацию из  стpочных и  заглавных букв)." Кроме того, приведенный мной список запрещённых символов был полным, а не то, что видим в данный момент. Возможно насчёт первой половины таблицы я загнул, но если отбросить запрещённые и упарвляющие символы (с кодом 0 - 31) - мы это и получим. Хотя можно конечно написать и так (цитата по Симрину):
Для обpазования имени файла может использоваться только  опpеделенный
набоp символов:
   буквы алфавита
   цифpы от 0 до 9
   специальные символы: $ # @ % ( ) - { } ` ' _ ^ ~
Возможно, чтобы избежать неоправданного расширения статьи, стоит вообще ограничиться фразой "Помимо ограничений файловой системы, интерфейсы операционной системы дополнительно ограничивают набор символов, который допустим при работе с файлами."
Tirthika 00:21, 7 ноября 2007 (UTC)
* Вы говорите о файловых вызовах (т.е. API). В этом случае просто все буквы приводятся к верхнему регистру (и вызывать функции работы с файлами можно действительно с любыми буквами). Если _создать_ файлы с маленькими буквами (diskedit или другая OS), то их будет невозможно прочитать из дос или выполнить любую операцию (известная проблема с записанными из виндов сидюками). Сейчас попробую найти источник... #!George Shuklin 04:52, 7 ноября 2007 (UTC) Во. KB от мелкософта должно быть достаточно убедительным : All characters in the MS-DOS character set must be in uppercase letters in accordance with the 8.3 file naming convention. И вот тоже: 
FAT Naming Convention
FAT uses the traditional 8.3 file naming convention and all filenames must be created with the ASCII character set. The name of a file or directory can be up to eight characters long, then a period (.) separator, and up to a three character extension. The name must start with either a letter or number and can contain any characters except for the following: 
   . " / \ [ ] : ; | = ,
				
If any of these characters are used, unexpected results may occur. The name cannot contain any spaces. 
The following names are reserved: 
   CON, AUX, COM1, COM2, COM3, COM4, LPT1, LPT2, LPT3, PRN, NUL
				
All characters will be converted to uppercase. 
Вы процитировали всё, кроме последней строчки :) #!George Shuklin 04:56, 7 ноября 2007 (UTC)
** Убедили ;) Tirthika 21:24, 7 ноября 2007 (UTC)
thread_title:  требования к именам файлов 

message: По моему мнению, это относится не к файлам, а к файловым системам. Предлагаю постепенно переместить это туда. — Vano 21:16, 5 декабря 2007 (UTC)
    Предлагаю сначала добавить "Архивный" в список атрибутов. - MaxT 18:35, 20 марта 2008 (UTC)
thread_title:  Атрибуты, ссылки и пр. 

message: сейчас всё это добавлено.но почему-то типы файловых систем для всех четырёх атрибутов одинаковы (?!). возникает два вопроса:
1. Может, стоит их объединить? и
2. Может, лучше вообще написать перед таблицей, что эти атрибуты присутствуют во всех файловых системах, и столбец убрать?  =p.s.a.= 10:59, 23 ноября 2008 (UTC)
Объект переменной длины называется файлом - последовательность произвольного числа бит, обладающих уникальным собственным названием и размещенная в дисковой памяти.  94.180.4.170 10:05, 10 января 2009 (UTC)
thread_title: Атрибуты (без ссылок!)

message: Вообще, единственно что объединяет все различные определения файла это то, что у файла есть независящее от используещей его программы имя (хотя в plan9 пространство имен у каждого процесса свое, после импорта к объекту может обратиться любая программа), его можно читать и в него можно писать, можно открывать и закрывать. 
VladTc 10:05, 9 мая 2013 (UTC)
replies: text: Первична файловая система, а не файл. — Monedula 14:59, 9 мая 2013 (UTC)
replies: text: : Не уловил мысли 92.100.154.242 20:13, 9 мая 2013 (UTC)

text: : ФС - способ организовать доступ к файлам. VladTc 20:16, 9 мая 2013 (UTC)
replies: text: :: Без файловой системы никаких файлов быть не может — только блоки данных. — Monedula 21:00, 9 мая 2013 (UTC)
replies: text: ::: Без пространства имен файлов, если точнее. Разницу можно почувствовать в plan9. Но как эта первичность соотносится с предложенным определение файла? VladTc 15:37, 11 мая 2013 (UTC)
replies: text: :::: У бумажной книги тоже есть имя. Книгу можно читать, а можно и писать. — Monedula 16:55, 11 мая 2013 (UTC)
replies: text: ::::: Итого, книга - файл. 95.55.100.106 12:07, 12 мая 2013 (UTC)
thread_title:  Файл - объект, который имеет имя и который можно читать и писать 

message: Т.е. автор утверждает, что RAID может иметь только одну файловую систему? Насколько это правильно? Ryzhkovdu (обс.) 20:46, 6 марта 2021 (UTC)
thread_title:  RAID — одна ФС, несколько носителей