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

А все забыли про "файл" - который вставляется в папку сделанный из полиэтилена :) --WiLD

см. внимательно (Файл (значения)) ;) --Tpyvvikky 14:01, 12 февраля 2013 (UTC)

Определение

предлагаю определить файл, как поименованную упорядоченную последовательность данных. Текущее определение неполно, нечётко и самозависимо (блок - это что, файл без имени? как читать этот блок? а папка с документами - это что, не файл?) Mashiah 13:26, 11 сентября 2006 (UTC)

• Файл не обязательно является данными, в частности, в ряде случаев файл имеет смысл по факту своего существования (т.н. файловые флаги). Вопрос "что такое файл?" это известная кащенитская провокация в ru.os.cmp, т.к. никто до сих пор не смог дать точного определения.

Предлагаю:

1. собрать определения из разных источников
2. перечислить свойства файлов.

 #!George Shuklin 04:13, 21 ноября 2006 (UTC)

Хорошая идея. 82.151.108.111 17:43, 10 апреля 2010 (UTC)

Поддерживаю предложение. Мне нравится определение "Файл - совокупность данных, доступ к которой осуществляется по ее имени". --Savchenko Andrey 08:55, 23 декабря 2006 (UTC)

А кто сказал, что у файла есть имя? Доступ по номеру ничем не хуже (и во многих файловых системах был абсолютно нормальным). #!George Shuklin 23:05, 26 января 2007 (UTC)

Сейчас я вам расскажу, что такое файл! :) — Vano 20:39, 5 декабря 2007 (UTC)

Ну вот. В таком виде (по памяти) нам его давал Восков Л.С. на лекциях по системному ПО. Наиболее общее и выделяет суть. — Vano 21:15, 5 декабря 2007 (UTC)

---

Файл - совокупность данных, названных одним (общим) именем, и находящихся на носителе информации. 85.172.108.236 15:03, 21 марта 2009 (UTC)

Данных? А если данных нет? А как называются потоки у файлов на 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 от мелкософта должно быть достаточно убедительным [1]: 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. [2]

Вы процитировали всё, кроме последней строчки :) #!George Shuklin 04:56, 7 ноября 2007 (UTC)

• • Убедили ;) Tirthika 21:24, 7 ноября 2007 (UTC)

Атрибуты, ссылки и пр.

По моему мнению, это относится не к файлам, а к файловым системам. Предлагаю постепенно переместить это туда. — Vano 21:16, 5 декабря 2007 (UTC)

    Предлагаю сначала добавить "Архивный" в список атрибутов. - MaxT 18:35, 20 марта 2008 (UTC)

Атрибуты (без ссылок!)

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

Объект переменной длины называется файлом - последовательность произвольного числа бит, обладающих уникальным собственным названием и размещенная в дисковой памяти. 94.180.4.170 10:05, 10 января 2009 (UTC)

Файл - объект, который имеет имя и который можно читать и писать

Вообще, единственно что объединяет все различные определения файла это то, что у файла есть независящее от используещей его программы имя (хотя в plan9 пространство имен у каждого процесса свое, после импорта к объекту может обратиться любая программа), его можно читать и в него можно писать, можно открывать и закрывать. VladTc 10:05, 9 мая 2013 (UTC)

Первична файловая система, а не файл. — Monedula 14:59, 9 мая 2013 (UTC)

Не уловил мысли 92.100.154.242 20:13, 9 мая 2013 (UTC)

ФС - способ организовать доступ к файлам. VladTc 20:16, 9 мая 2013 (UTC)

Без файловой системы никаких файлов быть не может — только блоки данных. — Monedula 21:00, 9 мая 2013 (UTC)

Без пространства имен файлов, если точнее. Разницу можно почувствовать в plan9. Но как эта первичность соотносится с предложенным определение файла? VladTc 15:37, 11 мая 2013 (UTC)

У бумажной книги тоже есть имя. Книгу можно читать, а можно и писать. — Monedula 16:55, 11 мая 2013 (UTC)

Итого, книга - файл. 95.55.100.106 12:07, 12 мая 2013 (UTC)

RAID — одна ФС, несколько носителей

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