Re: FS

[Eugene Grosbein]

13 ноя 2005, воскресенье, в 21:27 KRAST, Sergey Yevtushenko написал(а):

SY>>> Хух. Ладно, приведу полный ответ: у тебя нет четкого определения,
SY>>> следовательно употребление упрощенного варианта ведет к неоднозначности,
SY>>> а что бы этого избежать и ты не пользуйся упрощениями.
EG>> Файловым API называется API из определения соответствующей FS.
EG>> Каково бы ни было итоговое определение FS, четкость понятия
EG>> файлового FS не изменится, поэтому упрощение допустимо.
SY> Теперь задумайся над тем, что API файловой системы и "файловый API" это
SY> часто
SY> разные вещи. Причем упрощением одно к другому не приводится.

Они не могут быть разными вещами, это одно и тоже по определению;
грубо говоря то, что ты называешь "файловым API" я называю API FS
(хотя не вполне то).

EG>>>> Прикладной софт не общается со структурами на носителе в норме,
EG>>>> он все видит "через призму" API. Весь компьютер со всеми потрохами
EG>>>> включая железки и системный софт оправдан только работой прикладного
EG>>>> софта.
SY>>> Это все понятно, но это не повод вносить API именно в FS. В равной мере
SY>>> можно оставить его там, где он есть сейчас - в операционной системе.
EG>> Прикладной софт и так не видит структур носителя, если из его понятия FS
EG>> убрать еще и API с его структурами, то для прикладного софта
EG>> в этом понятии ничего не останется.
SY> Во-первых, останенется, поскольку есть вполне конкретные ограничения
SY> каждой
SY> конкретной FS.

Hе понял, что именно останется.

SY> Во-вторых, зачем прикладному софту знать API FS, если система
SY> ему и так предоставляет файловый API?

Это и есть API файловой системы.

EG>>>> У прикладного софта нет возможностей использовать заложенные
EG>>>> в структурах потенции. Во главу угла ставится потребности прикладного
EG>>>> софта.
SY>>> Hепонятно тогда зачем ты пытаешься включать внутренние структуры FS в
SY>>> рассмотрение.
EG>> Окажутся лишними - можно выкинуть. Пока это не очевидно.
SY> Бритва Оккама настоятельно рекомендует не умножать сущности сверх
SY> необходимого. Одно из практических следствий - добавление новой сущности
SY> делается только тогда, когда без нее невозможно обойтись.

Бритва Оккама лишь указывает, что сущность надо выкинуть,
когда доказана избыточность её существования. Пока этого не доказано.

EG>>>>>> Что касается FAT, то насколько мне известно, поддержка её полна
EG>>>>>> достаточно, чтобы считать имеющиеся различия несущественными.
SY>>>>> Согласно твоему определению это будут разные FS, поскольку они имеют
SY>>>>> разный
SY>>>>> API.
EG>>>> Строго говоря, да. Hо afaik различия эти несущественны.
SY>>> Что значит "несущественны"? Ты пробовал воспроизвести функциональность
SY>>> виндового CreateFile юниксовыми средствами?
EG>> Что, виндовый CreateFile на FAT может что-то существенно другое
EG>> с точки зрения userland, чем msdos(4) в FreeBSD?
SY> Давай ты возьмешь и почитаешь описание CreateFile.

Hекогда и негде (да и незачем). Так может или нет, и если да, что что именно?

EG>>>> Когда идет речь об объектах FS и API, работающем с ними,
EG>>>> то речь идет об объектах, видимых программам и соответствующем API.
SY>>> Хорошо. В таком случае сравнение, например, файловых систем в винде,
SY>>> полуоси и
SY>>> юнихах теряет смысл, поскольку все три набора API различны и как бы
SY>>> похожи не
SY>>> были FS реализованые в этих системах, говорить об их одинаковости не
SY>>> получится
SY>>> ни при каких условиях.
EG>> Вот.
SY> Теперь объясни, какой смысл в твоем определении, если оно даже не
SY> позволяет
SY> определить, одинаковые FS или нет?

Оно позволяет определить, одинаковы ли FS в смысле этого
определения или нет. И не запрещает сравнивать компоненты FS по-отдельности.

EG>>>> И зачем нужно определение FS, если в результате FS можно поменять
EG>>>> на "одинаковую", а прикладной софт перестанет работать. Hа мой взгляд,
EG>>>> эта FS существенно другая получается.
SY>>> Во-первых, "одинаковость" не предполагает одинаковые возможности для
SY>>> прикладного софта.
EG>> И зачем прикладному софту определение, называющее системы
EG>> одинаковыми и при этом одинаковые возможности не обещающее?
SY> Твой подход точно так же не решает этой проблемы. Более того, две
SY> последовательные, совместимые сверху вниз версии FS, в одной и той же
SY> системе,
SY> твое определение называет строго разными. Что, вобщем-то, не соответствует
SY> привычному пониманию обратной совместимости.

А не надо смешивать понятия обратной совместимости, которое никто не мешает
ввести на множестве FS с понятием строгой идентичности.

Eugene
--
Что делать?! Мир стоит на воровстве!..
Воруют в Самарканде и в Хиве,
В Ширазе, в Тегеране и в Стамбуле
И даже - страшно вымолвить - в Москве!..

[Alexander Andrusenko]

SY> Бритва Оккама настоятельно рекомендует не умножать сущности сверх
SY> необходимого. Одно из практических следствий - добавление новой

SY> сущности делается только тогда, когда без нее невозможно обойтись.
EG> Бритва Оккама лишь указывает, что сущность надо выкинуть,
EG> когда доказана избыточность её существования. Пока этого не доказано.

Ок, попробуем сыграть по твоим правилам. Допустим (я так не считаю, но
допустим), ты прав и API действительно является частью файловой системы.
Тогда вводим новое понятие - файловая структура. Определяем файл как элемент
файловой структуры. Определяем файловое API как набор функций для доступа к
файлам. Опеределяем файловую систему как совокупность файловой структуры и
файлового API.

Все определения есть, противоречий и зацикленности нету. Правда, введена еще
одна сущность, но попробуй докажи ее избыточность :)

[Vadim Goncharov]

Hi Eugene Grosbein!

On Tue, 15 Nov 2005 13:05:19 +0300; Eugene Grosbein wrote about 'Re: FS':

EG>>>>> Прикладной софт не общается со структурами на носителе в норме,
EG>>>>> он все видит "через призму" API. Весь компьютер со всеми потрохами
EG>>>>> включая железки и системный софт оправдан только работой прикладного
EG>>>>> софта.
SY>>>> Это все понятно, но это не повод вносить API именно в FS. В равной мере
SY>>>> можно оставить его там, где он есть сейчас - в операционной системе.
EG>>> Прикладной софт и так не видит структур носителя, если из его понятия FS
EG>>> убрать еще и API с его структурами, то для прикладного софта
EG>>> в этом понятии ничего не останется.
SY>> Во-первых, останенется, поскольку есть вполне конкретные ограничения

SY>> каждой конкретной FS.
EG> Hе понял, что именно останется.

Например, ограничение на длину файла.

SY>> Во-вторых, зачем прикладному софту знать API FS, если система
SY>> ему и так предоставляет файловый API?

EG> Это и есть API файловой системы.

Уже повторялось. API для FAT в винде и в юниксе разный. Так тчо он не
может принадлежать FS.

EG>>>>> У прикладного софта нет возможностей использовать заложенные
EG>>>>> в структурах потенции. Во главу угла ставится потребности прикладного
EG>>>>> софта.
SY>>>> Hепонятно тогда зачем ты пытаешься включать внутренние структуры FS в
SY>>>> рассмотрение.
EG>>> Окажутся лишними - можно выкинуть. Пока это не очевидно.
SY>> Бритва Оккама настоятельно рекомендует не умножать сущности сверх
SY>> необходимого. Одно из практических следствий - добавление новой сущности
SY>> делается только тогда, когда без нее невозможно обойтись.

EG> Бритва Оккама лишь указывает, что сущность надо выкинуть,
EG> когда доказана избыточность её существования. Пока этого не доказано.

/упал под стол/ И давно ли? Может определение бритвы перечитать?

EG>>>>>>> Что касается FAT, то насколько мне известно, поддержка её полна
EG>>>>>>> достаточно, чтобы считать имеющиеся различия несущественными.
SY>>>>>> Согласно твоему определению это будут разные FS, поскольку они имеют
SY>>>>>> разный
SY>>>>>> API.
EG>>>>> Строго говоря, да. Hо afaik различия эти несущественны.
SY>>>> Что значит "несущественны"? Ты пробовал воспроизвести функциональность
SY>>>> виндового CreateFile юниксовыми средствами?
EG>>> Что, виндовый CreateFile на FAT может что-то существенно другое
EG>>> с точки зрения userland, чем msdos(4) в FreeBSD?
SY>> Давай ты возьмешь и почитаешь описание CreateFile.

EG> Hекогда и негде (да и незачем). Так может или нет, и если да, что что именно?

Я бы сказал "слив защитан", но так уж и быть, приведу текст в конце
письма.

EG>>>>> Когда идет речь об объектах FS и API, работающем с ними,
EG>>>>> то речь идет об объектах, видимых программам и соответствующем API.
SY>>>> Хорошо. В таком случае сравнение, например, файловых систем в винде,
SY>>>> полуоси и
SY>>>> юнихах теряет смысл, поскольку все три набора API различны и как бы
SY>>>> похожи не
SY>>>> были FS реализованые в этих системах, говорить об их одинаковости не
SY>>>> получится
SY>>>> ни при каких условиях.
EG>>> Вот.
SY>> Теперь объясни, какой смысл в твоем определении, если оно даже не
SY>> позволяет
SY>> определить, одинаковые FS или нет?

EG> Оно позволяет определить, одинаковы ли FS в смысле этого
EG> определения или нет. И не запрещает сравнивать компоненты FS по-отдельности.

"Узок их круг, страшно далеки они от народа".

EG>>>>> И зачем нужно определение FS, если в результате FS можно поменять
EG>>>>> на "одинаковую", а прикладной софт перестанет работать. Hа мой взгляд,
EG>>>>> эта FS существенно другая получается.
SY>>>> Во-первых, "одинаковость" не предполагает одинаковые возможности для
SY>>>> прикладного софта.
EG>>> И зачем прикладному софту определение, называющее системы
EG>>> одинаковыми и при этом одинаковые возможности не обещающее?
SY>> Твой подход точно так же не решает этой проблемы. Более того, две
SY>> последовательные, совместимые сверху вниз версии FS, в одной и той же
SY>> системе,
SY>> твое определение называет строго разными. Что, вобщем-то, не соответствует
SY>> привычному пониманию обратной совместимости.

EG> А не надо смешивать понятия обратной совместимости, которое никто не мешает
EG> ввести на множестве FS с понятием строгой идентичности.

Введи.

Далее следует описание CreateFile.

===
СreateFile

The CreateFile function creates or opens the following objects and
returns a handle that can be used to access the object:

· files
· pipes
· mailslots
· communications resources
· disk devices (Windows NT only)
· consoles
· directories (open only)

HANDLE CreateFile(

LPCTSTR lpFileName, // pointer to name of the file
DWORD dwDesiredAccess, // access (read-write) mode
DWORD dwShareMode, // share mode
LPSECURITY_ATTRIBUTES lpSecurityAttributes, //pointer to security attributes
DWORD dwCreationDistribution, // how to create
DWORD dwFlagsAndAttributes, // file attributes
HANDLE hTemplateFile // handle to file with attributes to copy
);

Parameters

lpFileName

Points to a null-terminated string that specifies the name of the object
(file, pipe, mailslot, communications resource, disk device, console, or
directory) to create or open.

If *lpFileName is a path, there is a default string size limit of
MAX_PATH characters. This limit is related to how the CreateFile
function parses paths.
Windows NT: You can use paths longer than MAX_PATH characters by calling
the wide (W) version of CreateFile and prepending "\\?\" to the path.
The "\\?\" tells the function to turn off path parsing. This lets you
use paths that are nearly 32,000 Unicode characters long. You must use
fully-qualified paths with this technique. This also works with UNC
names. The "\\?\" is ignored as part of the path. For example,
"\\?\C:\myworld\private" is seen as "C:\myworld\private", and
"\\?\UNC\tom_1\hotstuff\coolapps" is seen as
"\\tom_1\hotstuff\coolapps".

dwDesiredAccess

Specifies the type of access to the object. An application can obtain
read access, write access, read-write access, or device query access.
This parameter can be any combination of the following values.

Value Meaning
0 Specifies device query access to the object. An application can
query device attributes without accessing the device.
GENERIC_READ Specifies read access to the object. Data can be read
from the file and the file pointer can be moved. Combine with
GENERIC_WRITE for read-write access.
GENERIC_WRITE Specifies write access to the object. Data can be
written to the file and the file pointer can be moved. Combine with
GENERIC_READ for read-write access.

dwShareMode

Set of bit flags that specifies how the object can be shared. If
dwShareMode is 0, the object cannot be shared. Subsequent open
operations on the object will fail, until the handle is closed.
To share the object, use a combination of one or more of the following
values:

Value Meaning
FILE_SHARE_DELETE Windows NT only: Subsequent open operations on
the object will succeed only if delete access is requested.
FILE_SHARE_READ Subsequent open operations on the object will succeed
only if read access is requested.
FILE_SHARE_WRITE Subsequent open operations on the object will
succeed only if write access is requested.

lpSecurityAttributes

Pointer to a SECURITY_ATTRIBUTES structure that determines whether the
returned handle can be inherited by child processes. If
lpSecurityAttributes is NULL, the handle cannot be inherited.

Windows NT: The lpSecurityDescriptor member of the structure specifies a
security descriptor for the object. If lpSecurityAttributes is NULL, the
object gets a default security descriptor. The target file system must
support security on files and directories for this parameter to have an
effect on files.
Windows 95: The lpSecurityDescriptor member of the structure is ignored.

dwCreationDistribution

Specifies which action to take on files that exist, and which action to
take when files do not exist. For more information about this parameter,
see the Remarks section. This parameter must be one of the following
values:

Value Meaning
CREATE_NEW Creates a new file. The function fails if the specified
file already exists.
CREATE_ALWAYS Creates a new file. The function overwrites the file if
it exists.
OPEN_EXISTING Opens the file. The function fails if the file does not
exist.
See the Remarks section for a discussion of why you should use
the OPEN_EXISTING flag if you are using the CreateFile function for
devices, including the console.
OPEN_ALWAYS Opens the file, if it exists. If the file does not
exist, the function creates the file as if dwCreationDistribution were
CREATE_NEW.
TRUNCATE_EXISTING Opens the file. Once opened, the file is
truncated so that its size is zero bytes. The calling process must open
the file with at least GENERIC_WRITE access. The function fails if the
file does not exist.

dwFlagsAndAttributes

Specifies the file attributes and flags for the file.

Any combination of the following attributes is acceptable, except all
other file attributes override FILE_ATTRIBUTE_NORMAL.

Attribute Meaning
FILE_ATTRIBUTE_ARCHIVE The file should be archived. Applications use
this attribute to mark files for backup or removal.
FILE_ATTRIBUTE_COMPRESSED The file or directory is compressed. For
a file, this means that all of the data in the file is compressed. For a
directory, this means that compression is the default for newly created
files and subdirectories.
FILE_ATTRIBUTE_HIDDEN The file is hidden. It is not to be included in
an ordinary directory listing.
FILE_ATTRIBUTE_NORMAL The file has no other attributes set. This
attribute is valid only if used alone.
FILE_ATTRIBUTE_OFFLINE The data of the file is not immediately
available. Indicates that the file data has been physically moved to
offline storage.
FILE_ATTRIBUTE_READONLY The file is read only. Applications can read the
file but cannot write to it or delete it.
FILE_ATTRIBUTE_SYSTEM The file is part of or is used exclusively by
the operating system.
FILE_ATTRIBUTE_TEMPORARY The file is being used for temporary
storage. File systems attempt to keep all of the data in memory for
quicker access rather than flushing the data back to mass storage. A
temporary file should be deleted by the application as soon as it is no
longer needed.

Any combination of the following flags is acceptable.

Flag Meaning
FILE_FLAG_WRITE_THROUGH
Instructs the operating system to write through any intermediate
cache and go directly to disk. The operating system can still cache
write operations, but cannot lazily flush them.
FILE_FLAG_OVERLAPPED
Instructs the operating system to initialize the object, so
ReadFile, WriteFile, ConnectNamedPipe, and TransactNamedPipe operations
that take a significant amount of time to process return
ERROR_IO_PENDING. When the operation is finished, an event is set to the
signaled state.
When you specify FILE_FLAG_OVERLAPPED, the ReadFile and
WriteFile functions must specify an OVERLAPPED structure. That is, when
FILE_FLAG_OVERLAPPED is specified, an application must perform
overlapped reading and writing.
When FILE_FLAG_OVERLAPPED is specified, the operating system
does not maintain the file pointer. The file position must be passed as
part of the lpOverlapped parameter (pointing to an OVERLAPPED structure)
to the ReadFile and WriteFile functions.
This flag also enables more than one operation to be performed
simultaneously with the handle (a simultaneous read and write operation,
for example).
FILE_FLAG_NO_BUFFERING
Instructs the operating system to open the file with no
intermediate buffering or caching. This can provide performance gains in
some situations. An application must meet certain requirements when
working with files opened with FILE_FLAG_NO_BUFFERING:· File
access must begin at byte offsets within the file that are integer
multiples of the volume's sector size. · File access must be for
numbers of bytes that are integer multiples of the volume's sector size.
For example, if the sector size is 512 bytes, an application can request
reads and writes of 512, 1024, or 2048 bytes, but not of 335, 981, or
7171 bytes. · Buffer addresses for read and write operations must be
aligned on addresses in memory that are integer multiples of the
volume's sector size. One way to align buffers on integer multiples of
the volume sector size is to use VirtualAlloc to allocate the buffers.
It allocates memory that is aligned on addresses that are integer
multiples of the operating system's memory page size. Since both memory
page and volume sector sizes are powers of 2, this memory is also
aligned on addresses that are integer multiples of a volume's sector
size. An application can determine a volume's sector size by calling the
GetDiskFreeSpace function.
FILE_FLAG_RANDOM_ACCESS
Indicates that the file is accessed randomly. Windows can use
this as a hint to optimize file caching.
FILE_FLAG_SEQUENTIAL_SCAN
Indicates that the file is to be accessed sequentially from
beginning to end. Windows can use this as a hint to optimize file
caching. If an application moves the file pointer for random access,
optimum caching may not occur; however, correct operation is still
guaranteed.
Specifying this flag can increase performance for applications
that read large files using sequential access. Performance gains can be
even more noticeable for applications that read large files mostly
sequentially, but occasionally skip over small ranges of bytes.
FILE_FLAG_DELETE_ON_CLOSE
Indicates that the operating system is to delete the file
immediately after all of its handles have been closed, not just the
handle for which you specified FILE_FLAG_DELETE_ON_CLOSE. Subsequent
open requests for the file will fail, unless FILE_SHARE_DELETE is used.
FILE_FLAG_BACKUP_SEMANTICS
Windows NT only: Indicates that the file is being opened or
created for a backup or restore operation. The operating system ensures
that the calling process overrides file security checks, provided it has
the necessary permission to do so. The relevant permissions are
SE_BACKUP_NAME and SE_RESTORE_NAME.You can also set this flag to obtain
a handle to a directory. A directory handle can be passed to some Win32
functions in place of a file handle.
FILE_FLAG_POSIX_SEMANTICS
Indicates that the file is to be accessed according to POSIX
rules. This includes allowing multiple files with names, differing only
in case, for file systems that support such naming. Use care when using
this option because files created with this flag may not be accessible
by applications written for MS-DOS, Windows, or Windows NT.

If the CreateFile function opens the client side of a named pipe, the
dwFlagsAndAttributes parameter can also contain Security Quality of
Service information. When the calling application specifies the
SECURITY_SQOS_PRESENT flag, the dwFlagsAndAttributes parameter can
contain one or more of the following values:

Value Meaning
SECURITY_ANONYMOUS Specifies to impersonate the client at the
Anonymous impersonation level.
SECURITY_IDENTIFICATION Specifies to impersonate the client at the
Identification impersonation level.
SECURITY_IMPERSONATION Specifies to impersonate the client at the
Impersonation impersonation level.
SECURITY_DELEGATION Specifies to impersonate the client at the
Delegation impersonation level.
SECURITY_CONTEXT_TRACKING Specifies that the security tracking
mode is dynamic. If this flag is not specified, Security Tracking Mode
is static.
SECURITY_EFFECTIVE_ONLY Specifies that only the enabled aspects of the
client's security context are available to the server. If you do not
specify this flag, all aspects of the client's security context are
available.This flag allows the client to limit the groups and privileges
that a server can use while impersonating the client.

For more information, see Security.

hTemplateFile

Specifies a handle with GENERIC_READ access to a template file. The
template file supplies file attributes and extended attributes for the
file being created.
Windows 95: This value must be NULL. If you supply a handle under
Windows 95, the call fails and GetLastError returns ERROR_NOT_SUPPORTED.

Return Values

If the function succeeds, the return value is an open handle to the
specified file. If the specified file exists before the function call
and dwCreationDistribution is CREATE_ALWAYS or OPEN_ALWAYS, a call to
GetLastError returns ERROR_ALREADY_EXISTS (even though the function has
succeeded). If the file does not exist before the call, GetLastError
returns zero.
If the function fails, the return value is INVALID_HANDLE_VALUE. To get
extended error information, call GetLastError.

Remarks

Use the CloseHandle function to close an object handle returned by
CreateFile.
As noted above, specifying zero for dwDesiredAccess allows an
application to query device attributes without actually accessing the
device. This type of querying is useful, for example, if an application
wants to determine the size of a floppy disk drive and the formats it
supports without having a floppy in the drive.

Files

When creating a new file, the CreateFile function performs the following
actions:

· Combines the file attributes and flags specified by
dwFlagsAndAttributes with FILE_ATTRIBUTE_ARCHIVE.
· Sets the file length to zero.
· Copies the extended attributes supplied by the template file to
the new file if the hTemplateFile parameter is specified.

When opening an existing file, CreateFile performs the following
actions:

· Combines the file flags specified by dwFlagsAndAttributes with
existing file attributes. CreateFile ignores the file attributes
specified by dwFlagsAndAttributes.
· Sets the file length according to the value of
dwCreationDistribution.
· Ignores the hTemplateFile parameter.
· Ignores the lpSecurityDescriptor member of the
SECURITY_ATTRIBUTES structure if the lpSecurityAttributes parameter is
not NULL. The other structure members are used. The bInheritHandle
member is the only way to indicate whether the file handle can be
inherited.

If you are attempting to create a file on a floppy drive that does not
have a floppy disk or a CD-ROM drive that does not have a CD, the system
displays a message box asking the user to insert a disk or a CD,
respectively. To prevent the system from displaying this message box,
call the SetErrorMode function with SEM_FAILCRITICALERRORS.

Pipes

If CreateFile opens the client end of a named pipe, the function uses
any instance of the named pipe that is in the listening state. The
opening process can duplicate the handle as many times as required but,
once opened, the named pipe instance cannot be opened by another client.
The access specified when a pipe is opened must be compatible with the
access specified in the dwOpenMode parameter of the CreateNamedPipe
function. For more information about pipes, see Pipes.

Mailslots

If CreateFile opens the client end of a mailslot, the function returns
INVALID_HANDLE_VALUE if the mailslot client attempts to open a local
mailslot before the mailslot server has created it with the
CreateMailSlot function. For more information about mailslots, see
Mailslots.

Communications Resources

The CreateFile function can create a handle to a communications
resource, such as the serial port COM1. For communications resources,
the dwCreationDistribution parameter must be OPEN_EXISTING, and the
hTemplate parameter must be NULL. Read, write, or read-write access can
be specified, and the handle can be opened for overlapped I/O. For more
information about communications, see Communications.
Disk Devices
Windows NT: You can use the CreateFile function to open a disk drive or
a partition on a disk drive. The function returns a handle to the disk
device; that handle can be used with the DeviceIOControl function. The
following requirements must be met in order for such a call to succeed:

· The caller must have administrative privileges for the operation
to succeed on a hard disk drive.
· The lpFileName string should be of the form \\.\PHYSICALDRIVEx
to open the hard disk x. Hard disk numbers start at zero. For example:

String Meaning
\\.\PHYSICALDRIVE2 Obtains a handle to the third physical drive on
the user's computer.

· The lpFileName string should be \\.\x: to open a floppy drive x
or a partition x on a hard disk. For example:

String Meaning
\\.\A: Obtains a handle to drive A on the user's computer.
\\.\C: Obtains a handle to drive C on the user's computer.

Windows 95: This technique does not work for opening a logical drive. In
Windows 95, specifying a string in this form causes CreateFile to return
an error.

· The dwCreationDistribution parameter must have the OPEN_EXISTING
value.
· When opening a floppy disk or a partition on a hard disk, you
must set the FILE_SHARE_WRITE flag in the dwShareMode parameter.

Consoles

The CreateFile function can create a handle to console input (CONIN$).
If the process has an open handle to it as a result of inheritance or
duplication, it can also create a handle to the active screen buffer
(CONOUT$). The calling process must be attached to an inherited console
or one allocated by the AllocConsole function. For console handles, set
the CreateFile parameters as follows:

Parameters Value
lpFileName Use the CONIN$ value to specify console input and the
CONOUT$ value to specify console output.
CONIN$ gets a handle to the console's input buffer, even if the
SetStdHandle function redirected the standard input handle. To get the
standard input handle, use the GetStdHandle function.
CONOUT$ gets a handle to the active screen buffer, even if
SetStdHandle redirected the standard output handle. To get the standard
output handle, use GetStdHandle.
dwDesiredAccess GENERIC_READ | GENERIC_WRITE is preferred, but either
one can limit access.
dwShareMode If the calling process inherited the console or if a
child process should be able to access the console, this parameter must
be FILE_SHARE_READ | FILE_SHARE_WRITE.
lpSecurityAttributes If you want the console to be inherited, the
bInheritHandle member of the SECURITY_ATTRIBUTES structure must be TRUE.
dwCreationDistribution You should specify OPEN_EXISTING when using
CreateFile to open the console.
dwFlagsAndAttributes Ignored.
hTemplateFile Ignored.

The following list shows the effects of various settings of fwdAccess
and lpFileName.

lpFileName fwdAccess Result
CON GENERIC_READ Opens console for input.
CON GENERIC_WRITE Opens console for output.
CON GENERIC_READ\
GENERIC_WRITE Windows 95: Causes CreateFile to fail; GetLastError
returns ERROR_PATH_NOT_FOUND.Windows NT: Causes CreateFile to fail;
GetLastError returns ERROR_FILE_NOT_FOUND.

Directories

An application cannot create a directory with CreateFile; it must call
CreateDirectory or CreateDirectoryEx to create a directory.

Windows NT:

You can obtain a handle to a directory by setting the
FILE_FLAG_BACKUP_SEMANTICS flag. A directory handle can be passed to
some Win32 functions in place of a file handle.

Some file systems, such as NTFS, support compression for individual
files and directories. On volumes formatted for such a file system, a
new directory inherits the compression attribute of its parent
directory.

See Also

AllocConsole, CloseHandle, ConnectNamedPipe, CreateDirectory,
CreateDirectoryEx, CreateNamedPipe, DeviceIOControl, GetDiskFreeSpace,
GetOverlappedResult, GetStdHandle, OpenFile, OVERLAPPED, ReadFile,
SECURITY_ATTRIBUTES, SetErrorMode, SetStdHandle TransactNamedPipe,
VirtualAlloc, WriteFile

--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]

[Gleb Belyakov]

████ OS/2 ╠╣ello, Alexander!

Tuesday November 15 2005 09:43, Alexander Andrusenko wrote to me:

GB>> До котоpого момента jfs -- файловая система а когда пеpестает
GB>> ею быть?

AA> До тех пор, пока она полностью находится на одном носителе. Почему? По
AA> определению :)

А если я винты супеpклеем склею так что хеp pаздеpешь -- станет опять
файловой системой? :-)

AA> В чем разница? В том, что если при использовании нескольких винтов ты
AA> возьмешь один винт, вытащишь его из компа, и воткнешь в другой комп,
AA> то часть файлов этой нефайловой :) системы может стать там недоступна
AA> (если не повреждена) из-за отсутствия остальных винтов.

Hу как тебе сказать... Ты инстpукции вообще читаешь? Hу вот напpимеp о том,
что нельзя в микpоволновке кота сушить, или что нельзя в стиpальной машине
шмотки кpасить... Вот тут тоже в инстpукции сказано: нельзя винты по одному
таскать.

AA> Если файловая структура хранится на нескольких носителях, то это уже
AA> новая сущность - можешь называть ее, например, распределенная файловая
AA> система. Которая, конечно, много чем похожа на обычную файловую
AA> систему, но имеет и существенные отличия.

Hе... Распpеделенная это если ее по сеpвеpам pаспpеделить. А тут... В
кpайнем случае тянет на такой вот стpанный pейд.
Кстати о pейде... Беpем его (тот котоpый 1, кажется, ну тот котоpый винты в
один носитель клеит), и фоpматим чем-ньть типа fat32... Она от этого пеpестанет
быть файловой системой, по твоему опpеделению.

Gleb Belyakov Bye.
AKA REM [e-mail: rem...@mail.ru]
... √ Гpех пpедаваться унынию когда есть дpугие гpехи.

[Gleb Belyakov]

████ OS/2 ╠╣ello, Alexander!

Tuesday November 15 2005 09:43, Alexander Andrusenko wrote to Eugene Grosbein:

AA> системы. Тогда вводим новое понятие - файловая структура.
[... Ctrl-Y ...]
AA> Все определения есть, противоречий и зацикленности нету. Правда,
AA> введена еще одна сущность, но попробуй докажи ее избыточность :)

У меня есть сомнения, что это именно "еще одна сущность". Мне кажется, что
собеседники в этой эхе вообще склонны пеpемещаться по уpовням абстpакции
обсуждаемого не заботясь о том пойму ли их.
Здесь обсуждается как минимум две пpинципиально pазные сущности, котоpые
тем не менее споpщики называют одним и тем же названием. Файловая структура --
не еще одно понятие, а еще одно название одной из этих сущностей, и это
название пpосто снимает неопpеделенность.

Gleb Belyakov Bye.
AKA REM [e-mail: rem...@mail.ru]

... √ Кому на Руси жить хоpошо? Ведется pасследование...

[Eugene Grosbein]

15 ноя 2005, вторник, в 11:34 KRAST, Vadim Goncharov написал(а):

SY>>>>> Это все понятно, но это не повод вносить API именно в FS. В равной

SY>>>>> мере

SY>>>>> можно оставить его там, где он есть сейчас - в операционной системе.
EG>>>> Прикладной софт и так не видит структур носителя, если из его понятия

EG>>>> FS

EG>>>> убрать еще и API с его структурами, то для прикладного софта
EG>>>> в этом понятии ничего не останется.
SY>>> Во-первых, останенется, поскольку есть вполне конкретные ограничения
SY>>> каждой конкретной FS.
EG>> Hе понял, что именно останется.

VG> Hапример, ограничение на длину файла.

Ограничение на длину файла есть часть спецификации API FS. Hапомню, что
софт общается с файлами только через API.

SY>>> Во-вторых, зачем прикладному софту знать API FS, если система
SY>>> ему и так предоставляет файловый API?
EG>> Это и есть API файловой системы.

VG> Уже повторялось. API для FAT в винде и в юниксе разный. Так тчо он не
VG> может принадлежать FS.

Вот этот переход "разный => не может" не обоснован.

SY>>> Бритва Оккама настоятельно рекомендует не умножать сущности сверх
SY>>> необходимого. Одно из практических следствий - добавление новой сущности
SY>>> делается только тогда, когда без нее невозможно обойтись.
EG>> Бритва Оккама лишь указывает, что сущность надо выкинуть,
EG>> когда доказана избыточность её существования. Пока этого не доказано.

VG> /упал под стол/ И давно ли?

Всю жизнь.

VG> Может определение бритвы перечитать?

Перечитай: "... без необходимости".

SY>>>>>>> Согласно твоему определению это будут разные FS, поскольку они имеют
SY>>>>>>> разный
SY>>>>>>> API.
EG>>>>>> Строго говоря, да. Hо afaik различия эти несущественны.
SY>>>>> Что значит "несущественны"? Ты пробовал воспроизвести функциональность
SY>>>>> виндового CreateFile юниксовыми средствами?
EG>>>> Что, виндовый CreateFile на FAT может что-то существенно другое
EG>>>> с точки зрения userland, чем msdos(4) в FreeBSD?
SY>>> Давай ты возьмешь и почитаешь описание CreateFile.
EG>> Hекогда и негде (да и незачем). Так может или нет, и если да, что что

VG> именно?
VG> Я бы сказал "слив защитан",

Да ради бога. Еще я солью на предложение почитать описание
API файловых систем MAC OS и OS/2.

VG> но так уж и быть, приведу текст в конце
VG> письма.

Спасибо.

EG>> А не надо смешивать понятия обратной совместимости, которое никто не

VG> мешает

EG>> ввести на множестве FS с понятием строгой идентичности.

VG> Введи.

А оно мне надо?

VG> Далее следует описание CreateFile.

Спасибо еще раз. В отношении FAT возможности его отличаются
от msdos(4) несущественно imho.

Eugene
--
For the Colonel's Lady an' Judy O'Grady
Are sisters under their skins!

[Alexander Andrusenko]

GD> А если я винты супеpклеем склею так что хеp pаздеpешь -- станет
GD> опять файловой системой? :-)

Тогда надо дать определение носителя, которого пока тоже нет. Я считаю, что
от склеивания клеем два носителя не станут одним, а значит и файловой
системой jfs от такой операции не станет.

GB> Hу как тебе сказать... Ты инстpукции вообще читаешь? Hу вот
GB> напpимеp о том, что нельзя в микpоволновке кота сушить, или что
GB> нельзя в стиpальной машине шмотки кpасить...

Иногда читаю, иногда не читаю. Иногда, как в случае с jfs, вообще не
представляю о чем речь. Впрочем, уже представляю - вот она, польза от эхи!
:-)

GB> Вот тут тоже в инстpукции сказано: нельзя винты по одному таскать.

"Если нельзя, но очень хочется - то можно". Видишь, вот тебе и ограничение,
и отличие от файловой системы, данной в определении.Что лишний раз
доказывает, что это - не файловая система.

GB> Hе... Распpеделенная это если ее по сеpвеpам pаспpеделить. А тут...
В
GB> кpайнем случае тянет на такой вот стpанный pейд.

Гм... пусть будет "такой вот странный рейд" - хоть морковкой назови, только
в суп не клади, т.е. не говори, что это - файловая система.

GB> Кстати о pейде... Беpем его (тот котоpый 1, кажется, ну тот котоpый
GB> винты в один носитель клеит), и фоpматим чем-ньть типа fat32... Она
GB> от этого пеpестанет быть файловой системой, по твоему опpеделению.

Не понял... вроде бы в рейде нету такого. Но в любом случае это возвращает
нас к вопросу об определении носителя. Стоит ли рейдовый массив считать
одним носителем? Согласно моему определению получается, что да, и тогда
переконфигурация рейд-массива представляет собой уничтожение одного носителя
и создание из его "обломков" :) другого.

[Sergey Yevtushenko]

Tue Nov 15 2005 12:05, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>> Файловым API называется API из определения соответствующей FS.
EG>>> Каково бы ни было итоговое определение FS, четкость понятия
EG>>> файлового FS не изменится, поэтому упрощение допустимо.
SY>> Теперь задумайся над тем, что API файловой системы и "файловый API" это

SY>> часто разные вещи. Причем упрощением одно к другому не приводится.

EG> Они не могут быть разными вещами, это одно и тоже по определению;
EG> грубо говоря то, что ты называешь "файловым API" я называю API FS
EG> (хотя не вполне то).

Твое определение тут ни при чем, так что "по определению" тут не проходит.
Более того, это таки действительно разные вещи и если ты удосужишся
поинтересоваться вопросом, например, посмотрев в сорсы, то убедишься в этом
сам.

EG>>>>> Прикладной софт не общается со структурами на носителе в норме,
EG>>>>> он все видит "через призму" API. Весь компьютер со всеми потрохами
EG>>>>> включая железки и системный софт оправдан только работой прикладного
EG>>>>> софта.
SY>>>> Это все понятно, но это не повод вносить API именно в FS. В равной

SY>>>> мере можно оставить его там, где он есть сейчас - в операционной
SY>>>> системе.

EG>>> Прикладной софт и так не видит структур носителя, если из его понятия

EG>>> FS убрать еще и API с его структурами, то для прикладного софта

EG>>> в этом понятии ничего не останется.
SY>> Во-первых, останенется, поскольку есть вполне конкретные ограничения

SY>> каждой конкретной FS.

EG> Hе понял, что именно останется.

Прикладной софт все равно будет знать об FS, поскольку на разных FS имеются
свои ограничения.

SY>> Во-вторых, зачем прикладному софту знать API FS, если система
SY>> ему и так предоставляет файловый API?

EG> Это и есть API файловой системы.

Нет, конечно. API файловой системы это сильно другая вещь.

SY>>>> Hепонятно тогда зачем ты пытаешься включать внутренние структуры FS в
SY>>>> рассмотрение.
EG>>> Окажутся лишними - можно выкинуть. Пока это не очевидно.
SY>> Бритва Оккама настоятельно рекомендует не умножать сущности сверх
SY>> необходимого. Одно из практических следствий - добавление новой сущности
SY>> делается только тогда, когда без нее невозможно обойтись.

EG> Бритва Оккама лишь указывает, что сущность надо выкинуть,
EG> когда доказана избыточность её существования. Пока этого не доказано.

Традиционная формулировка звучит как "не следует привлекать новые сущности без
самой крайней на то необходимости". То есть изначально предполагается
минимальная модель.

EG>>>>>>> Что касается FAT, то насколько мне известно, поддержка её полна
EG>>>>>>> достаточно, чтобы считать имеющиеся различия несущественными.
SY>>>>>> Согласно твоему определению это будут разные FS, поскольку они имеют
SY>>>>>> разный
SY>>>>>> API.
EG>>>>> Строго говоря, да. Hо afaik различия эти несущественны.
SY>>>> Что значит "несущественны"? Ты пробовал воспроизвести функциональность
SY>>>> виндового CreateFile юниксовыми средствами?
EG>>> Что, виндовый CreateFile на FAT может что-то существенно другое
EG>>> с точки зрения userland, чем msdos(4) в FreeBSD?
SY>> Давай ты возьмешь и почитаешь описание CreateFile.

EG> Hекогда и негде (да и незачем). Так может или нет, и если да, что что
EG> именно?

Почему ты считаешь, что твое нежелание сходить на msdn.miscrosoft.com это
уважительная причина для того, что бы заставлять меня разбираться с тем, что
такое msdos(4) в FreeBSD? Тем более, что к файловому API это не имеет никакого
отношения.

SY>>>> Хорошо. В таком случае сравнение, например, файловых систем в винде,
SY>>>> полуоси и
SY>>>> юнихах теряет смысл, поскольку все три набора API различны и как бы
SY>>>> похожи не
SY>>>> были FS реализованые в этих системах, говорить об их одинаковости не
SY>>>> получится
SY>>>> ни при каких условиях.
EG>>> Вот.
SY>> Теперь объясни, какой смысл в твоем определении, если оно даже не

SY>> позволяет определить, одинаковые FS или нет?

EG> Оно позволяет определить, одинаковы ли FS в смысле этого
EG> определения или нет. И не запрещает сравнивать компоненты FS
EG> по-отдельности.

В смысле этого определения одинаковые файловые системы могут существовать
только в рамках одной операционки (а то и в рамках одной версии операционки).

EG>>>>> И зачем нужно определение FS, если в результате FS можно поменять
EG>>>>> на "одинаковую", а прикладной софт перестанет работать. Hа мой

EG>>>>> взгляд, эта FS существенно другая получается.

SY>>>> Во-первых, "одинаковость" не предполагает одинаковые возможности для
SY>>>> прикладного софта.
EG>>> И зачем прикладному софту определение, называющее системы
EG>>> одинаковыми и при этом одинаковые возможности не обещающее?
SY>> Твой подход точно так же не решает этой проблемы. Более того, две
SY>> последовательные, совместимые сверху вниз версии FS, в одной и той же
SY>> системе,
SY>> твое определение называет строго разными. Что, вобщем-то, не

SY>> соответствует привычному пониманию обратной совместимости.

EG> А не надо смешивать понятия обратной совместимости, которое никто не
EG> мешает ввести на множестве FS с понятием строгой идентичности.

Удачи.

*----------------------------------------------------------------------

[Sergey Yevtushenko]

Tue Nov 15 2005 10:34, Vadim Goncharov wrote to Eugene Grosbein:

VG> Далее следует описание CreateFile.

VG> ===
VG> СreateFile

[skip]

Тут не сказано самое главное (поскольку это подразумевается), а именно то, что
этот вызов атомарен. То есть можно одним вызовом создать (или открыть),
залочить, задать права доступа, режимы кеширования и записи и т.д. и т.п. и
при этом гарантировано не будет никаких race conditions.

*----------------------------------------------------------------------

[Eugene Grosbein]

15 ноя 2005, вторник, в 13:57 KRAST, Sergey Yevtushenko написал(а):

EG>> Они не могут быть разными вещами, это одно и тоже по определению;
EG>> грубо говоря то, что ты называешь "файловым API" я называю API FS
EG>> (хотя не вполне то).

SY> Твое определение тут ни при чем, так что "по определению" тут не проходит.
SY> Более того, это таки действительно разные вещи и если ты удосужишся
SY> поинтересоваться вопросом, например, посмотрев в сорсы, то убедишься в
SY> этом
SY> сам.

Я прекрасно понимаю, о чем ты говоришь. То, что я называею API FS
это не интерфейс между ядром и FS. Это интерфейс между прикладным
софтом и FS по определению.

EG>>>> Прикладной софт и так не видит структур носителя, если из его понятия
EG>>>> FS убрать еще и API с его структурами, то для прикладного софта
EG>>>> в этом понятии ничего не останется.
SY>>> Во-первых, останенется, поскольку есть вполне конкретные ограничения
SY>>> каждой конкретной FS.
EG>> Hе понял, что именно останется.

SY> Прикладной софт все равно будет знать об FS, поскольку на разных FS
SY> имеются
SY> свои ограничения.

Эти ограничения часть спецификации API.

SY>>> Во-вторых, зачем прикладному софту знать API FS, если система
SY>>> ему и так предоставляет файловый API?
EG>> Это и есть API файловой системы.

SY> Hет, конечно. API файловой системы это сильно другая вещь.

В предложеном определении файловой системы API называется API,
предоставляемый системой прикладному софту.

SY>>>>> Hепонятно тогда зачем ты пытаешься включать внутренние структуры FS в
SY>>>>> рассмотрение.
EG>>>> Окажутся лишними - можно выкинуть. Пока это не очевидно.
SY>>> Бритва Оккама настоятельно рекомендует не умножать сущности сверх
SY>>> необходимого. Одно из практических следствий - добавление новой сущности
SY>>> делается только тогда, когда без нее невозможно обойтись.
EG>> Бритва Оккама лишь указывает, что сущность надо выкинуть,
EG>> когда доказана избыточность её существования. Пока этого не доказано.

SY> Традиционная формулировка звучит как "не следует привлекать новые сущности
SY> без
SY> самой крайней на то необходимости". То есть изначально предполагается
SY> минимальная модель.

В матмоделировании пригодность модели является крайней необходимостью.

EG>>>>>>>> Что касается FAT, то насколько мне известно, поддержка её полна
EG>>>>>>>> достаточно, чтобы считать имеющиеся различия несущественными.
SY>>>>>>> Согласно твоему определению это будут разные FS, поскольку они имеют
SY>>>>>>> разный
SY>>>>>>> API.
EG>>>>>> Строго говоря, да. Hо afaik различия эти несущественны.
SY>>>>> Что значит "несущественны"? Ты пробовал воспроизвести функциональность
SY>>>>> виндового CreateFile юниксовыми средствами?
EG>>>> Что, виндовый CreateFile на FAT может что-то существенно другое
EG>>>> с точки зрения userland, чем msdos(4) в FreeBSD?
SY>>> Давай ты возьмешь и почитаешь описание CreateFile.

EG>> Hекогда и негде (да и незачем). Так может или нет, и если да, что что
EG>> именно?

SY> Почему ты считаешь, что твое нежелание сходить на msdn.miscrosoft.com это
SY> уважительная причина для того, что бы заставлять меня разбираться с тем,
SY> что
SY> такое msdos(4) в FreeBSD?

Тебе необязательно разбираться в этом. Вполне достаточно принять,
что приложение под FreeBSD на FAT может почти все из того, что Windows.
До тех пор, пока не появились свидетельства обратного; в таком случае,
раз различия окажутся существенны, то это получатся разные FS.

SY> Тем более, что к файловому API это не имеет никакого отношения.

Прямое, с точки зрения прикладного софта.

SY> В смысле этого определения одинаковые файловые системы могут существовать
SY> только в рамках одной операционки (а то и в рамках одной версии
SY> операционки).

Hу.

Eugene
--
И знатную леди от Джуди О'Греди
Hе сможет никто отличить.

[Dark Elf]

Best regards! Eugene!

15 Nov 05 19:00, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>> Они не могут быть разными вещами, это одно и тоже по

EG>>> определению; грубо говоря то, что ты называешь "файловым API" я
EG>>> называю API FS (хотя не вполне то).

SY>> Твое определение тут ни при чем, так что "по определению" тут не

SY>> проходит. Более того, это таки действительно разные вещи и если
SY>> ты удосужишся поинтересоваться вопросом, например, посмотрев в
SY>> сорсы, то убедишься в этом сам.
EG> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API FS
EG> это не интерфейс между ядром и FS. Это интерфейс между прикладным
EG> софтом и FS по определению.

Любым FS, т.е. файловое API.
Следовательно, оно не может быть пpивязанно к конкpетной FS.

Или пpикладной софт обpащается к КОHКРЕТHОЙ FS? И эти вызовы pазличны?

EG>>>>> Прикладной софт и так не видит структур носителя, если из его

EG>>>>> понятия FS убрать еще и API с его структурами, то для
EG>>>>> прикладного софта в этом понятии ничего не останется.

SY>>>> Во-первых, останенется, поскольку есть вполне конкретные

SY>>>> ограничения каждой конкретной FS.

EG>>> Hе понял, что именно останется.
SY>> Прикладной софт все равно будет знать об FS, поскольку на разных

SY>> FS имеются свои ограничения.
EG> Эти ограничения часть спецификации API.

Часть спецификации FS а не API.

SY>> Тем более, что к файловому API это не имеет никакого отношения.

EG> Прямое, с точки зрения прикладного софта.

С точки зpения пpикладного софта - её пофигу, к какой FS это относится.
Пpикладной софт обpащается к файловому API а не к API FS.

║ - Что-то у вас ванна очень сильно поцарапана.
║ Говорят, маньяки любят в них трупы расчленять.

Best regards! Dark Elf

[Eugene Grosbein]

15 ноя 2005, вторник, в 17:27 KRAST, Dark Elf написал(а):

EG>> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API FS
EG>> это не интерфейс между ядром и FS. Это интерфейс между прикладным
EG>> софтом и FS по определению.

DE> Любым FS, т.е. файловое API.
DE> Следовательно, оно не может быть пpивязанно к конкpетной FS.

Оно очень даже может быть привязано к конкретной FS.
Вообще-то я в самом начале треда сказал про ioctl.

DE> Или пpикладной софт обpащается к КОHКРЕТHОЙ FS? И эти вызовы pазличны?

Он может обращаться к конкретной FS. Этого вполне достаточно, чтобы
объявить API принадлежащим конкретной FS, даже если 99% API
одинаковы для всех FS. Чуть-чуть не считается.

EG>>>>>> Прикладной софт и так не видит структур носителя, если из его
EG>>>>>> понятия FS убрать еще и API с его структурами, то для
EG>>>>>> прикладного софта в этом понятии ничего не останется.
SY>>>>> Во-первых, останенется, поскольку есть вполне конкретные
SY>>>>> ограничения каждой конкретной FS.
EG>>>> Hе понял, что именно останется.
SY>>> Прикладной софт все равно будет знать об FS, поскольку на разных
SY>>> FS имеются свои ограничения.
EG>> Эти ограничения часть спецификации API.

DE> Часть спецификации FS а не API.

Софт видит FS только через API.

SY>>> Тем более, что к файловому API это не имеет никакого отношения.
EG>> Прямое, с точки зрения прикладного софта.

DE> С точки зpения пpикладного софта - её пофигу, к какой FS это относится.
DE> Пpикладной софт обpащается к файловому API а не к API FS.

Файловый API это и есть API FS.

Eugene
--
Hаучить не кланяться авторитетам, а исследовать их и сравнивать их поучения
с жизнью. Hаучить настороженно относиться к опыту бывалых людей, потому что
жизнь меняется необычайно быстро.

[Vadim Goncharov]

Hi Eugene Grosbein!

On Tue, 15 Nov 2005 16:15:10 +0300; Eugene Grosbein wrote about 'Re: FS':

SY>>>>>> Это все понятно, но это не повод вносить API именно в FS. В равной
SY>>>>>> мере
SY>>>>>> можно оставить его там, где он есть сейчас - в операционной системе.
EG>>>>> Прикладной софт и так не видит структур носителя, если из его понятия
EG>>>>> FS
EG>>>>> убрать еще и API с его структурами, то для прикладного софта
EG>>>>> в этом понятии ничего не останется.
SY>>>> Во-первых, останенется, поскольку есть вполне конкретные ограничения
SY>>>> каждой конкретной FS.
EG>>> Hе понял, что именно останется.
VG>> Hапример, ограничение на длину файла.

EG> Ограничение на длину файла есть часть спецификации API FS. Hапомню, что
EG> софт общается с файлами только через API.

И давно ли? Это ограничение поля длины файла в некоей структуре на диске.

SY>>>> Во-вторых, зачем прикладному софту знать API FS, если система
SY>>>> ему и так предоставляет файловый API?
EG>>> Это и есть API файловой системы.
VG>> Уже повторялось. API для FAT в винде и в юниксе разный. Так тчо он не
VG>> может принадлежать FS.

EG> Вот этот переход "разный => не может" не обоснован.

Потому что файловая система per se осталась одной и той же.

SY>>>> Бритва Оккама настоятельно рекомендует не умножать сущности сверх
SY>>>> необходимого. Одно из практических следствий - добавление новой сущности
SY>>>> делается только тогда, когда без нее невозможно обойтись.
EG>>> Бритва Оккама лишь указывает, что сущность надо выкинуть,
EG>>> когда доказана избыточность её существования. Пока этого не доказано.
VG>> /упал под стол/ И давно ли?

EG> Всю жизнь.

VG>> Может определение бритвы перечитать?

EG> Перечитай: "... без необходимости".

Передергивание в стиле "было бы величайшей ошибкой думать" (с) Ленин
На самом деле - Non sunt multiplicanda entia praeter necessitatem.
Бритва предлагает не вводить сущности, а не выкидывать, т.е. это ты
должен доказывать необходимость введения новой сущности.

SY>>>>>>>> Согласно твоему определению это будут разные FS, поскольку они имеют
SY>>>>>>>> разный
SY>>>>>>>> API.
EG>>>>>>> Строго говоря, да. Hо afaik различия эти несущественны.
SY>>>>>> Что значит "несущественны"? Ты пробовал воспроизвести функциональность
SY>>>>>> виндового CreateFile юниксовыми средствами?
EG>>>>> Что, виндовый CreateFile на FAT может что-то существенно другое
EG>>>>> с точки зрения userland, чем msdos(4) в FreeBSD?
SY>>>> Давай ты возьмешь и почитаешь описание CreateFile.
EG>>> Hекогда и негде (да и незачем). Так может или нет, и если да, что что
VG>> именно?
VG>> Я бы сказал "слив защитан",

EG> Да ради бога. Еще я солью на предложение почитать описание
EG> API файловых систем MAC OS и OS/2.

Тогда нахрена ты ввязываешься в спор?

EG>>> А не надо смешивать понятия обратной совместимости, которое никто не
VG>> мешает
EG>>> ввести на множестве FS с понятием строгой идентичности.
VG>> Введи.

EG> А оно мне надо?

Утверждаешь - изволь доказать.

VG>> Далее следует описание CreateFile.

EG> Спасибо еще раз. В отношении FAT возможности его отличаются
EG> от msdos(4) несущественно imho.

Где там в описании слово FAT ? Софтина вообще может не знать о
конкретной файловой системе - у ней тут общее API.

[Vadim Goncharov]

Hi Eugene Grosbein!

On Tue, 15 Nov 2005 19:00:14 +0300; Eugene Grosbein wrote about 'Re: FS':

EG> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API FS
EG> это не интерфейс между ядром и FS. Это интерфейс между прикладным
EG> софтом и FS по определению.

Такого не существует. Есть интерфейс между ядром и софтиной.

SY>>>> Во-вторых, зачем прикладному софту знать API FS, если система
SY>>>> ему и так предоставляет файловый API?
EG>>> Это и есть API файловой системы.
SY>> Hет, конечно. API файловой системы это сильно другая вещь.

EG> В предложеном определении файловой системы API называется API,
EG> предоставляемый системой прикладному софту.

Необоснованная привязка софта и АПИ к файловой системе.

SY>>>>>> Hепонятно тогда зачем ты пытаешься включать внутренние структуры FS в
SY>>>>>> рассмотрение.
EG>>>>> Окажутся лишними - можно выкинуть. Пока это не очевидно.
SY>>>> Бритва Оккама настоятельно рекомендует не умножать сущности сверх
SY>>>> необходимого. Одно из практических следствий - добавление новой сущности
SY>>>> делается только тогда, когда без нее невозможно обойтись.
EG>>> Бритва Оккама лишь указывает, что сущность надо выкинуть,
EG>>> когда доказана избыточность её существования. Пока этого не доказано.
SY>> Традиционная формулировка звучит как "не следует привлекать новые сущности
SY>> без
SY>> самой крайней на то необходимости". То есть изначально предполагается
SY>> минимальная модель.

EG> В матмоделировании пригодность модели является крайней необходимостью.

Смена тезиса.

EG>>>>>>>>> Что касается FAT, то насколько мне известно, поддержка её полна
EG>>>>>>>>> достаточно, чтобы считать имеющиеся различия несущественными.
SY>>>>>>>> Согласно твоему определению это будут разные FS, поскольку они имеют
SY>>>>>>>> разный
SY>>>>>>>> API.
EG>>>>>>> Строго говоря, да. Hо afaik различия эти несущественны.
SY>>>>>> Что значит "несущественны"? Ты пробовал воспроизвести функциональность
SY>>>>>> виндового CreateFile юниксовыми средствами?
EG>>>>> Что, виндовый CreateFile на FAT может что-то существенно другое
EG>>>>> с точки зрения userland, чем msdos(4) в FreeBSD?
SY>>>> Давай ты возьмешь и почитаешь описание CreateFile.
EG>>> Hекогда и негде (да и незачем). Так может или нет, и если да, что что
EG>>> именно?
SY>> Почему ты считаешь, что твое нежелание сходить на msdn.miscrosoft.com это
SY>> уважительная причина для того, что бы заставлять меня разбираться с тем,
SY>> что
SY>> такое msdos(4) в FreeBSD?

EG> Тебе необязательно разбираться в этом. Вполне достаточно принять,
EG> что приложение под FreeBSD на FAT может почти все из того, что Windows.
EG> До тех пор, пока не появились свидетельства обратного; в таком случае,
EG> раз различия окажутся существенны, то это получатся разные FS.

Не получатся. FS - это форматы структур на носителе. Точка.

SY>> Тем более, что к файловому API это не имеет никакого отношения.

EG> Прямое, с точки зрения прикладного софта.

Софт не обязан ничего знать о файловой системе. Он может вообще не
оперировать понятием "файл".

[George Hazan]

Приветствую, Vadim!
Вы писали Tue, 15 Nov 2005 13:48:47 +0000 (UTC) к Eugene Grosbein:

VG> Такого не существует. Есть интерфейс между ядром и софтиной.

Это бессмысленная фраза. Ядро (слой, подсистема ядра) предоставляет
интерфейс, а кто им там воспользуется - софтина, другая подсистема ядра,
вышележащий слой ядра - никакой разницы для провайдера интерфейса не
представляет.

--
С уважением, ghazan at postman.ru
Георгий Хазан.

[Sergey Yevtushenko]

Tue Nov 15 2005 18:00, Eugene Grosbein wrote to Sergey Yevtushenko:

SY>> Твое определение тут ни при чем, так что "по определению" тут не

SY>> проходит. Более того, это таки действительно разные вещи и если ты
SY>> удосужишся поинтересоваться вопросом, например, посмотрев в сорсы, то
SY>> убедишься в этом
SY>> сам.

EG> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API FS
EG> это не интерфейс между ядром и FS. Это интерфейс между прикладным
EG> софтом и FS по определению.

Этот API состоит из (минимум) двух независимых частей. Одна из них - та, что
видна непосредственно прикладному софту. Она не зависит от конкретной FS и не
является частью этой FS (хотя бы потому, что при замене FS эта часть остается
неизменной). Рассматривать ее как часть FS - значит заведомо создавать
неадекватную матмодель.

EG>>>>> Прикладной софт и так не видит структур носителя, если из его понятия
EG>>>>> FS убрать еще и API с его структурами, то для прикладного софта
EG>>>>> в этом понятии ничего не останется.
SY>>>> Во-первых, останенется, поскольку есть вполне конкретные ограничения
SY>>>> каждой конкретной FS.
EG>>> Hе понял, что именно останется.
SY>> Прикладной софт все равно будет знать об FS, поскольку на разных FS

SY>> имеются свои ограничения.

EG> Эти ограничения часть спецификации API.

Нет, конечно. Они часть конкретной реализации, а не спецификации API.

SY>>>> Во-вторых, зачем прикладному софту знать API FS, если система
SY>>>> ему и так предоставляет файловый API?
EG>>> Это и есть API файловой системы.
SY>> Hет, конечно. API файловой системы это сильно другая вещь.

EG> В предложеном определении файловой системы API называется API,

EG> предоставляемый системой прикладному софту.

См. выше.

SY>>>>>> Hепонятно тогда зачем ты пытаешься включать внутренние структуры FS

SY>>>>>> в рассмотрение.

EG>>>>> Окажутся лишними - можно выкинуть. Пока это не очевидно.
SY>>>> Бритва Оккама настоятельно рекомендует не умножать сущности сверх
SY>>>> необходимого. Одно из практических следствий - добавление новой

SY>>>> сущности делается только тогда, когда без нее невозможно обойтись.

EG>>> Бритва Оккама лишь указывает, что сущность надо выкинуть,
EG>>> когда доказана избыточность её существования. Пока этого не доказано.
SY>> Традиционная формулировка звучит как "не следует привлекать новые

SY>> сущности без

SY>> самой крайней на то необходимости". То есть изначально предполагается
SY>> минимальная модель.

EG> В матмоделировании пригодность модели является крайней необходимостью.

Пока ты не можешь обосновать необходимость включения внутренних структур, их
включать нельзя и модель остается пригодной.

EG>>> Hекогда и негде (да и незачем). Так может или нет, и если да, что что
EG>>> именно?
SY>> Почему ты считаешь, что твое нежелание сходить на msdn.miscrosoft.com

SY>> это уважительная причина для того, что бы заставлять меня разбираться с
SY>> тем, что

SY>> такое msdos(4) в FreeBSD?

EG> Тебе необязательно разбираться в этом. Вполне достаточно принять,
EG> что приложение под FreeBSD на FAT может почти все из того, что Windows.
EG> До тех пор, пока не появились свидетельства обратного; в таком случае,
EG> раз различия окажутся существенны, то это получатся разные FS.

Я уже упоминал то, что соответствующий вызов win32 является атомарным. Для
прикладного софта это существенно, причем проблемы, которые могут проявиться
при отсутствии атомарности, в общем случае на уровне приложения решить нельзя.
Обращаю твое внимание, что это не проблема FS как таковой и в целом обе
реализации FAT можно считать совместимыми и одинаковыми во всех практических
смыслах. В рамках твоего определения они всегда будут разными.

SY>> Тем более, что к файловому API это не имеет никакого отношения.

EG> Прямое, с точки зрения прикладного софта.

SY>> В смысле этого определения одинаковые файловые системы могут

SY>> существовать только в рамках одной операционки (а то и в рамках одной
SY>> версии операционки).

EG> Hу.

Я считаю, что такая модель неадекватна.

*----------------------------------------------------------------------

[Eugene Grosbein]

15 ноя 2005, вторник, в 16:48 KRAST, Vadim Goncharov написал(а):

EG>> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API FS
EG>> это не интерфейс между ядром и FS. Это интерфейс между прикладным
EG>> софтом и FS по определению.

VG> Такого не существует. Есть интерфейс между ядром и софтиной.

Это не мешает конкретным вызовам быть одновременно и интерфейсом
между FS и софтом.

SY>>>>> Во-вторых, зачем прикладному софту знать API FS, если система
SY>>>>> ему и так предоставляет файловый API?
EG>>>> Это и есть API файловой системы.
SY>>> Hет, конечно. API файловой системы это сильно другая вещь.
EG>> В предложеном определении файловой системы API называется API,
EG>> предоставляемый системой прикладному софту.

VG> Hеобоснованная привязка софта и АПИ к файловой системе.

В каком смысле необоснованная? Это же определение; напоминаю
что определить можно и отношение неравенства между i и -i.

EG>>>> Бритва Оккама лишь указывает, что сущность надо выкинуть,
EG>>>> когда доказана избыточность её существования. Пока этого не доказано.
SY>>> Традиционная формулировка звучит как "не следует привлекать новые

VG> сущности
SY>>> без

SY>>> самой крайней на то необходимости". То есть изначально предполагается
SY>>> минимальная модель.
EG>> В матмоделировании пригодность модели является крайней необходимостью.

VG> Смена тезиса.

Которого на который?

EG>> Тебе необязательно разбираться в этом. Вполне достаточно принять,
EG>> что приложение под FreeBSD на FAT может почти все из того, что Windows.
EG>> До тех пор, пока не появились свидетельства обратного; в таком случае,
EG>> раз различия окажутся существенны, то это получатся разные FS.

VG> Hе получатся. FS - это форматы структур на носителе. Точка.

Hичего подобного. С точки зрения прикладного софта этих структур,
как и самого носителя, может вообще не быть и ничего не изменится.
А только точка зрения софта и имеет значение, потому что только им
оправданы все остальные компоненты системы.

SY>>> Тем более, что к файловому API это не имеет никакого отношения.
EG>> Прямое, с точки зрения прикладного софта.

VG> Софт не обязан ничего знать о файловой системе.

О структурах на носителе? Именно так.

VG> Он может вообще не оперировать понятием "файл".

А вот такому софту вообще фиолетовы тонкости файловых систем
и поэтому он фиолетов нам в этом обсуждении.

Eugene
--
Благословляем мы богов
За то, что сердце в человеке

[Eugene Grosbein]

15 ноя 2005, вторник, в 16:44 KRAST, Vadim Goncharov написал(а):

EG>> Ограничение на длину файла есть часть спецификации API FS. Hапомню, что
EG>> софт общается с файлами только через API.

VG> И давно ли? Это ограничение поля длины файла в некоей структуре на диске.

Софт не видит структур на диске (которого может вообще не быть),
софт видит структуры, возвращаемые ему посредством API.

SY>>>>> Во-вторых, зачем прикладному софту знать API FS, если система
SY>>>>> ему и так предоставляет файловый API?
EG>>>> Это и есть API файловой системы.

VG>>> Уже повторялось. API для FAT в винде и в юниксе разный. Так тчо он не
VG>>> может принадлежать FS.
EG>> Вот этот переход "разный => не может" не обоснован.

VG> Потому что файловая система per se осталась одной и той же.

Далеко не факт, это как раз и зависит от используемого определения
файловой системы. При предлагаемом изменилась.

VG> Бритва предлагает не вводить сущности, а не выкидывать, т.е. это ты
VG> должен доказывать необходимость введения новой сущности.

Я еще не говорил, что бритва Оккама не догма?
Hет необходимости доказывать введение новых сущностей при построении моделей.

EG>> Да ради бога. Еще я солью на предложение почитать описание
EG>> API файловых систем MAC OS и OS/2.

VG> Тогда нахрена ты ввязываешься в спор?

Я ввязываюсь? :-) По-моему, это ты ввязываешься :-))

EG>>>> А не надо смешивать понятия обратной совместимости, которое никто не
VG>>> мешает
EG>>>> ввести на множестве FS с понятием строгой идентичности.
VG>>> Введи.
EG>> А оно мне надо?

VG> Утверждаешь - изволь доказать.

Что именно я утверждаю?

VG>>> Далее следует описание CreateFile.
EG>> Спасибо еще раз. В отношении FAT возможности его отличаются
EG>> от msdos(4) несущественно imho.

VG> Где там в описании слово FAT ?

Прочитай пожалуйста тред, в который ввязываешься :-)
CreateFile в нем возникло именно в контексте FAT и совместимости
реализаций в FreeBSD и Windows.

VG> Софтина вообще может не знать о
VG> конкретной файловой системе - у ней тут общее API.

Hу да, ну да. Ты сам-то читал, что привел? Там половина не работает на FAT.

Eugene
--
Hе зная страхов и желаний,
Благословляем мы богов

[Michael Baryshnikov]

Hello, Alexander!

Tuesday November 15 2005 09:43, Alexander Andrusenko wrote to Gleb Belyakov:

GB>> Так. Беpем jfs. Она может находиться на одном pазделе (единый
GB>> носитель) или на нескольких на одном винте (единый носитель), или
GB>> на нескольких котоpые находятся на нескольких винтах (нет носителя
GB>> как _единой сущности_).
GB>> До котоpого момента jfs -- файловая система а когда пеpестает ею
GB>> быть?

AA> До тех пор, пока она полностью находится на одном носителе. Почему? По
AA> определению :)

Это плохое определение, неверное. Файловая система там единая, независимо от
количества винтов.

AA> В чем разница? В том, что если при использовании нескольких винтов ты

AA> возьмешь один винт, вытащишь его из компа, и воткнешь в другой комп, то
AA> часть файлов этой нефайловой :) системы может стать там недоступна (если не
AA> повреждена) из-за отсутствия остальных винтов.

Hет. Hе будет. Если ОПЕРАЦИОHHАЯ система их не испортит.

AA> Если файловая структура хранится на нескольких носителях, то это уже новая
AA> сущность - можешь называть ее, например, распределенная файловая система.
AA> Которая, конечно, много чем похожа на обычную файловую систему, но имеет и
AA> существенные отличия.

Hет. Файловая система та же самая, то, что ДАHHЫЕ распределены по нескольким
носителям - никак не меняет свойств ФАЙЛОВОЙ СИСТЕМЫ.

Rest begards...oh, sorry, best regards, Michael

... OUCH! I got my floppy caught in my PKZipper!

[Michael Baryshnikov]

Hello, Alexander!

Tuesday November 15 2005 13:17, Alexander Andrusenko wrote to Gleb Belyakov:

GB>> Кстати о pейде... Беpем его (тот котоpый 1, кажется, ну тот котоpый
GB>> винты в один носитель клеит), и фоpматим чем-ньть типа fat32... Она
GB>> от этого пеpестанет быть файловой системой, по твоему опpеделению.

AA> Hе понял... вроде бы в рейде нету такого.

Здрассте. А "стрип" что такое?

AA> Hо в любом случае это возвращает нас к вопросу об определении носителя.

А хрен ли его определять? Вот Глеб, 10 мессагами раньше, сказал, что - это я.
Меня можно определить абсолютно однозначно.

Rest begards...oh, sorry, best regards, Michael

... Preserve yeast. It's the only culture some people have.

[Eugene Grosbein]

15 ноя 2005, вторник, в 17:59 KRAST, Sergey Yevtushenko написал(а):

EG>> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API FS
EG>> это не интерфейс между ядром и FS. Это интерфейс между прикладным
EG>> софтом и FS по определению.

SY> Этот API состоит из (минимум) двух независимых частей. Одна из них - та,
SY> что
SY> видна непосредственно прикладному софту. Она не зависит от конкретной FS и
SY> не
SY> является частью этой FS (хотя бы потому, что при замене FS эта часть
SY> остается
SY> неизменной).

Она, разумеется, зависит от FS и нет препятствий для нее поменяться
при смене структуры. Hапример, пополниться новыми методами либо
измениться старым.

EG>> В матмоделировании пригодность модели является крайней необходимостью.

SY> Пока ты не можешь обосновать необходимость включения внутренних структур,
SY> их
SY> включать нельзя и модель остается пригодной.

Это "нельзя" ниоткуда не следует. Бритва Оккама не догма.
И пока избыточность внутренних структур в модели неочевидна,
включить их не помешает. Всегда можно переиграть и убрать потом.

EG>> Тебе необязательно разбираться в этом. Вполне достаточно принять,
EG>> что приложение под FreeBSD на FAT может почти все из того, что Windows.
EG>> До тех пор, пока не появились свидетельства обратного; в таком случае,
EG>> раз различия окажутся существенны, то это получатся разные FS.

SY> Я уже упоминал то, что соответствующий вызов win32 является атомарным. Для
SY> прикладного софта это существенно, причем проблемы, которые могут
SY> проявиться
SY> при отсутствии атомарности, в общем случае на уровне приложения решить
SY> нельзя.

В таком случае это разные FS.

SY> Обращаю твое внимание, что это не проблема FS как таковой и в целом обе
SY> реализации FAT можно считать совместимыми и одинаковыми во всех
SY> практических
SY> смыслах.

Ты определись, либо они одинаковы во всех практических смыслах,
либо софт, используя одну из них может сделать нечто, чего принципиально
не может сделать с другой - и тогда они существенно различны.

Eugene
--

За то, что сердце в человеке

Hе вечно будет трепетать

[Sergey Yevtushenko]

Wed Nov 16 2005 01:12, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API FS
EG>>> это не интерфейс между ядром и FS. Это интерфейс между прикладным
EG>>> софтом и FS по определению.
SY>> Этот API состоит из (минимум) двух независимых частей. Одна из них - та,
SY>> что
SY>> видна непосредственно прикладному софту. Она не зависит от конкретной FS

SY>> и не

SY>> является частью этой FS (хотя бы потому, что при замене FS эта часть
SY>> остается
SY>> неизменной).

EG> Она, разумеется, зависит от FS

Докажи.

EG> и нет препятствий для нее поменяться
EG> при смене структуры. Hапример, пополниться новыми методами либо
EG> измениться старым.

Эти изменения отразятся на файловом API в целом и не будут свойством
конкретной FS.

EG>>> В матмоделировании пригодность модели является крайней необходимостью.
SY>> Пока ты не можешь обосновать необходимость включения внутренних

SY>> структур, их включать нельзя и модель остается пригодной.

EG> Это "нельзя" ниоткуда не следует. Бритва Оккама не догма.
EG> И пока избыточность внутренних структур в модели неочевидна,
EG> включить их не помешает. Всегда можно переиграть и убрать потом.

А не надо откладывать на потом.

SY>> Я уже упоминал то, что соответствующий вызов win32 является атомарным.

SY>> Для прикладного софта это существенно, причем проблемы, которые могут

SY>> проявиться
SY>> при отсутствии атомарности, в общем случае на уровне приложения решить
SY>> нельзя.

EG> В таком случае это разные FS.

Нет, конечно. Это разные системы - да, но насчет "разные FS" это еще только
предстоит обосновать.

SY>> Обращаю твое внимание, что это не проблема FS как таковой и в целом обе
SY>> реализации FAT можно считать совместимыми и одинаковыми во всех
SY>> практических
SY>> смыслах.

EG> Ты определись, либо они одинаковы во всех практических смыслах,
EG> либо софт, используя одну из них может сделать нечто, чего принципиально
EG> не может сделать с другой - и тогда они существенно различны.

Как только исключается API, так "одинаковость во всех практических смыслах"
становится вполне достижимой на практике. А то, что софт _в разных_ системах
имеет разные возможности, так это обусловлено операционкой, а не FS.

*----------------------------------------------------------------------

[Vadim Goncharov]

Hi George Hazan!

On Tue, 15 Nov 2005 14:06:59 +0000 (UTC); George Hazan wrote about 'Re: FS':

VG>> Такого не существует. Есть интерфейс между ядром и софтиной.

GH> Это бессмысленная фраза. Ядро (слой, подсистема ядра) предоставляет
GH> интерфейс, а кто им там воспользуется - софтина, другая подсистема ядра,
GH> вышележащий слой ядра - никакой разницы для провайдера интерфейса не
GH> представляет.

Есть. Существуют интерфейсы, которые рассчитаны на использование в ядре,
а не в юзерлэнде. Дизайн у них из-за этого разный.

[Vadim Goncharov]

Hi Eugene Grosbein!

On Tue, 15 Nov 2005 21:46:44 +0300; Eugene Grosbein wrote about 'Re: FS':

EG>>> Ограничение на длину файла есть часть спецификации API FS. Hапомню, что
EG>>> софт общается с файлами только через API.
VG>> И давно ли? Это ограничение поля длины файла в некоей структуре на диске.

EG> Софт не видит структур на диске (которого может вообще не быть),
EG> софт видит структуры, возвращаемые ему посредством API.

Хорош воду в ступе толочь. Опять все упирается в API. А файл - он-то
лежит в неопределяемой API части - на носителе.

SY>>>>>> Во-вторых, зачем прикладному софту знать API FS, если система
SY>>>>>> ему и так предоставляет файловый API?
EG>>>>> Это и есть API файловой системы.
VG>>>> Уже повторялось. API для FAT в винде и в юниксе разный. Так тчо он не
VG>>>> может принадлежать FS.
EG>>> Вот этот переход "разный => не может" не обоснован.
VG>> Потому что файловая система per se осталась одной и той же.

EG> Далеко не факт, это как раз и зависит от используемого определения
EG> файловой системы. При предлагаемом изменилась.

Предлагаемое определение неверно.

VG>> Бритва предлагает не вводить сущности, а не выкидывать, т.е. это ты
VG>> должен доказывать необходимость введения новой сущности.

EG> Я еще не говорил, что бритва Оккама не догма?

Так. Только этого еще не хватало.

EG> Hет необходимости доказывать введение новых сущностей при построении моделей.

Ненавязчивое такое передергивание с "излишних" на "новых".

EG>>> Да ради бога. Еще я солью на предложение почитать описание
EG>>> API файловых систем MAC OS и OS/2.
VG>> Тогда нахрена ты ввязываешься в спор?

EG> Я ввязываюсь? :-) По-моему, это ты ввязываешься :-))

EG>>>>> А не надо смешивать понятия обратной совместимости, которое никто не
VG>>>> мешает
EG>>>>> ввести на множестве FS с понятием строгой идентичности.
VG>>>> Введи.
EG>>> А оно мне надо?
VG>> Утверждаешь - изволь доказать.

EG> Что именно я утверждаю?

Это к отмазкам "оно мне надо?". Раз уж взялся понимать обратную
совместимость, которую в твоей модели еще надо вводтиь - так вводи.

VG>>>> Далее следует описание CreateFile.
EG>>> Спасибо еще раз. В отношении FAT возможности его отличаются
EG>>> от msdos(4) несущественно imho.
VG>> Где там в описании слово FAT ?

EG> Прочитай пожалуйста тред, в который ввязываешься :-)
EG> CreateFile в нем возникло именно в контексте FAT и совместимости
EG> реализаций в FreeBSD и Windows.

Так и я о том же. API, вот незадача, к FS-то толком и не привязано.

VG>> Софтина вообще может не знать о
VG>> конкретной файловой системе - у ней тут общее API.

EG> Hу да, ну да. Ты сам-то читал, что привел? Там половина не работает на FAT.

Так и я о том же на каждом собрании. Где это пресловутое файловое API
конкретной FS ?

[Vadim Goncharov]

Hi Eugene Grosbein!

On Tue, 15 Nov 2005 21:54:28 +0300; Eugene Grosbein wrote about 'Re: FS':

EG>>> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API FS
EG>>> это не интерфейс между ядром и FS. Это интерфейс между прикладным
EG>>> софтом и FS по определению.
VG>> Такого не существует. Есть интерфейс между ядром и софтиной.

EG> Это не мешает конкретным вызовам быть одновременно и интерфейсом
EG> между FS и софтом.

А в общем случае необязательно. Модель должна учитывать более общие
случаи.

SY>>>>>> Во-вторых, зачем прикладному софту знать API FS, если система
SY>>>>>> ему и так предоставляет файловый API?
EG>>>>> Это и есть API файловой системы.
SY>>>> Hет, конечно. API файловой системы это сильно другая вещь.
EG>>> В предложеном определении файловой системы API называется API,
EG>>> предоставляемый системой прикладному софту.
VG>> Hеобоснованная привязка софта и АПИ к файловой системе.

EG> В каком смысле необоснованная? Это же определение; напоминаю
EG> что определить можно и отношение неравенства между i и -i.

"Паровоз есть мяукающий зверь". Нравится определение?

EG>>>>> Бритва Оккама лишь указывает, что сущность надо выкинуть,
EG>>>>> когда доказана избыточность её существования. Пока этого не доказано.
SY>>>> Традиционная формулировка звучит как "не следует привлекать новые
VG>> сущности
SY>>>> без
SY>>>> самой крайней на то необходимости". То есть изначально предполагается
SY>>>> минимальная модель.
EG>>> В матмоделировании пригодность модели является крайней необходимостью.
VG>> Смена тезиса.

EG> Которого на который?

С Бритвы на матмодели.

EG>>> Тебе необязательно разбираться в этом. Вполне достаточно принять,
EG>>> что приложение под FreeBSD на FAT может почти все из того, что Windows.
EG>>> До тех пор, пока не появились свидетельства обратного; в таком случае,
EG>>> раз различия окажутся существенны, то это получатся разные FS.
VG>> Hе получатся. FS - это форматы структур на носителе. Точка.

EG> Hичего подобного. С точки зрения прикладного софта этих структур,
EG> как и самого носителя, может вообще не быть и ничего не изменится.

Ладно, приведу аналогию, может понятнее станет. Коммуникационный
протокол есть структуры в сети + API, предоставляемое софту для досутпа
к нему. В результате имеем кучу разных протоколв TCP. Абсурд, правда?

EG> А только точка зрения софта и имеет значение, потому что только им
EG> оправданы все остальные компоненты системы.

(1)

SY>>>> Тем более, что к файловому API это не имеет никакого отношения.
EG>>> Прямое, с точки зрения прикладного софта.
VG>> Софт не обязан ничего знать о файловой системе.

EG> О структурах на носителе? Именно так.

Только к определению FS это имеет очень отдаленное отношение.

VG>> Он может вообще не оперировать понятием "файл".

EG> А вот такому софту вообще фиолетовы тонкости файловых систем
EG> и поэтому он фиолетов нам в этом обсуждении.

См. (1)

[Eugene Grosbein]

16 ноя 2005, среда, в 01:43 KRAST, Vadim Goncharov написал(а):

EG>>>> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API FS
EG>>>> это не интерфейс между ядром и FS. Это интерфейс между прикладным
EG>>>> софтом и FS по определению.
VG>>> Такого не существует. Есть интерфейс между ядром и софтиной.
EG>> Это не мешает конкретным вызовам быть одновременно и интерфейсом
EG>> между FS и софтом.

VG> А в общем случае необязательно. Модель должна учитывать более общие
VG> случаи.

Когда отдельная FS вводит новые вызовы, которых нет в других FS это
более общий случай. А когда не вводит своих отдельных это более частный.
И когда поддерживает все "традиционные" вызовы это частный случай,
а в общем может часть и не поддерживать. Вот модель и учитывает
как общие, так и частные случаи.

VG>>> Hеобоснованная привязка софта и АПИ к файловой системе.
EG>> В каком смысле необоснованная? Это же определение; напоминаю
EG>> что определить можно и отношение неравенства между i и -i.

VG> "Паровоз есть мяукающий зверь". Hравится определение?

Аналогии сосут. Повторяю вопрос: в каком смысле необоснованная?

EG>>>>>> Бритва Оккама лишь указывает, что сущность надо выкинуть,
EG>>>>>> когда доказана избыточность её существования. Пока этого не доказано.
SY>>>>> Традиционная формулировка звучит как "не следует привлекать новые
VG>>> сущности
SY>>>>> без
SY>>>>> самой крайней на то необходимости". То есть изначально предполагается
SY>>>>> минимальная модель.
EG>>>> В матмоделировании пригодность модели является крайней необходимостью.
VG>>> Смена тезиса.
EG>> Которого на который?

VG> С Бритвы на матмодели.

Это не смена тезиса, это возвращение разговора в основное русло.
А по бритве я уже высказался.

EG>>>> Тебе необязательно разбираться в этом. Вполне достаточно принять,
EG>>>> что приложение под FreeBSD на FAT может почти все из того, что Windows.
EG>>>> До тех пор, пока не появились свидетельства обратного; в таком случае,
EG>>>> раз различия окажутся существенны, то это получатся разные FS.
VG>>> Hе получатся. FS - это форматы структур на носителе. Точка.
EG>> Hичего подобного. С точки зрения прикладного софта этих структур,
EG>> как и самого носителя, может вообще не быть и ничего не изменится.

VG> Ладно, приведу аналогию, может понятнее станет. Коммуникационный
VG> протокол есть структуры в сети + API, предоставляемое софту для досутпа
VG> к нему. В результате имеем кучу разных протоколв TCP. Абсурд, правда?

Протокол TCP определен в RFC и дополнительного определения к нему
строить не надо.

EG>> А только точка зрения софта и имеет значение, потому что только им
EG>> оправданы все остальные компоненты системы.

VG> (1)

SY>>>>> Тем более, что к файловому API это не имеет никакого отношения.
EG>>>> Прямое, с точки зрения прикладного софта.
VG>>> Софт не обязан ничего знать о файловой системе.
EG>> О структурах на носителе? Именно так.

VG> Только к определению FS это имеет очень отдаленное отношение.

Что "это"?

VG>>> Он может вообще не оперировать понятием "файл".
EG>> А вот такому софту вообще фиолетовы тонкости файловых систем
EG>> и поэтому он фиолетов нам в этом обсуждении.

VG> См. (1)

Ok, разжую еще: имеет значение только точка зрения софта, использующего
файлы и файловые системы.

Eugene
--
Все любят естественный наркотик

[Dark Elf]

Best regards! Eugene!

15 Nov 05 20:29, Eugene Grosbein wrote to Dark Elf:

EG>>> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API

EG>>> FS это не интерфейс между ядром и FS. Это интерфейс между
EG>>> прикладным софтом и FS по определению.

DE>> Любым FS, т.е. файловое API.
DE>> Следовательно, оно не может быть пpивязанно к конкpетной FS.

EG> Оно очень даже может быть привязано к конкретной FS.
EG> Вообще-то я в самом начале треда сказал про ioctl.

Эти ни необходимое и не достаточное условие. Как pаз это и является лишней
сущностью.

DE>> Или пpикладной софт обpащается к КОHКРЕТHОЙ FS?

DE>> И эти вызовы pазличны?
EG> Он может обращаться к конкретной FS. Этого вполне достаточно, чтобы
EG> объявить API принадлежащим конкретной FS, даже если 99% API
EG> одинаковы для всех FS. Чуть-чуть не считается.

Ты намеpенно не ответил на пеpвый вопpос?

EG>>>>>>> Прикладной софт и так не видит структур носителя, если из

EG>>>>>>> его понятия FS убрать еще и API с его структурами, то для

EG>>>>>>> прикладного софта в этом понятии ничего не останется.
SY>>>>>> Во-первых, останенется, поскольку есть вполне конкретные
SY>>>>>> ограничения каждой конкретной FS.
EG>>>>> Hе понял, что именно останется.
SY>>>> Прикладной софт все равно будет знать об FS, поскольку на

SY>>>> разных FS имеются свои ограничения.

EG>>> Эти ограничения часть спецификации API.
DE>> Часть спецификации FS а не API.

EG> Софт видит FS только через API.

Всё таки, я настаиваю на том, что, с целью единообpазия, пpикладной софт
общается с файловым API, как пpавило, независящим от FS. А вот файловое API уже
может взаимодействовать с API FS. Впpочем, как и с дpугим API. Т.е. служет
обычным пеpедастом вызовов, т.е. вpапеpом.

SY>>>> Тем более, что к файловому API это не имеет никакого отношения.
EG>>> Прямое, с точки зрения прикладного софта.
DE>> С точки зpения пpикладного софта - её пофигу, к какой FS это

DE>> относится. Пpикладной софт обpащается к файловому API а не к API
DE>> FS.
EG> Файловый API это и есть API FS.

В таком случае это API должно отличаться, в зависимости от FS. Чего мы не
наблюдаем в действительности. Значит твоё утвеpждение невеpно.

║ Любовь - это рыбалка. не клюет - сматывай удочки.

Best regards! Dark Elf

[Eugene Grosbein]

15 ноя 2005, вторник, в 23:21 KRAST, Sergey Yevtushenko написал(а):

SY>>> Этот API состоит из (минимум) двух независимых частей. Одна из них - та,
SY>>> что
SY>>> видна непосредственно прикладному софту. Она не зависит от конкретной FS
SY>>> и не
SY>>> является частью этой FS (хотя бы потому, что при замене FS эта часть
SY>>> остается
SY>>> неизменной).

EG>> Она, разумеется, зависит от FS

SY> Докажи.

Hапример, при замене FFS на FAT перестает работать mknod()
Метод, на FS возвращающий ошибку в любом случае, нет смысла считать
определенным на этой FS.

Либо наоборот, новая FS может предоставлять дополнительный сервис
через новые возможности ioctl().

EG>> и нет препятствий для нее поменяться
EG>> при смене структуры. Hапример, пополниться новыми методами либо
EG>> измениться старым.

SY> Эти изменения отразятся на файловом API в целом и не будут свойством
SY> конкретной FS.

Эти новые возможности ioctl() могут работать только на одной FS,
а на остальных возвращать EOPNOTSUPP. Фактически это свойство конкретной FS.
Модель должна включать в себя и такой случай.

SY>>> Я уже упоминал то, что соответствующий вызов win32 является атомарным.
SY>>> Для прикладного софта это существенно, причем проблемы, которые могут
SY>>> проявиться
SY>>> при отсутствии атомарности, в общем случае на уровне приложения решить
SY>>> нельзя.
EG>> В таком случае это разные FS.

SY> Hет, конечно. Это разные системы - да, но насчет "разные FS" это еще
SY> только
SY> предстоит обосновать.

SY>>> Обращаю твое внимание, что это не проблема FS как таковой и в целом обе
SY>>> реализации FAT можно считать совместимыми и одинаковыми во всех
SY>>> практических
SY>>> смыслах.
EG>> Ты определись, либо они одинаковы во всех практических смыслах,
EG>> либо софт, используя одну из них может сделать нечто, чего принципиально

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

EG>> не может сделать с другой - и тогда они существенно различны.

^^^^^^^^^^^^^^^^^^^^^^^^^
SY> Как только исключается API, так "одинаковость во всех практических
SY> смыслах"
SY> становится вполне достижимой на практике.

Hеясно, какие "практические смыслы" остаются у прикладного софта,
лишенного API. И какие еще нужны обоснования различности файловых систем,
определенных как предложено, после подчеркнутого.

Eugene
--
Устав от вечных упований,
Устав от радостных пиров

[Eugene Grosbein]

16 ноя 2005, среда, в 01:33 KRAST, Vadim Goncharov написал(а):

EG>>>> Ограничение на длину файла есть часть спецификации API FS. Hапомню, что
EG>>>> софт общается с файлами только через API.
VG>>> И давно ли? Это ограничение поля длины файла в некоей структуре на

VG>>> диске.

EG>> Софт не видит структур на диске (которого может вообще не быть),
EG>> софт видит структуры, возвращаемые ему посредством API.

VG> Хорош воду в ступе толочь. Опять все упирается в API. А файл - он-то
VG> лежит в неопределяемой API части - на носителе.

Прикладному софту это фиолетово, где он лежит. API сказало ENOSPC,
значит писать сейчас нельзя, а есть там место на физическом носителе
и есть ли сам носитель в реальности уже неважно софтинке.

VG> Предлагаемое определение неверно.

Еще один. Определение не может быть верным или не верным.

EG>> Hет необходимости доказывать введение новых сущностей при построении

VG> моделей.
VG> Hенавязчивое такое передергивание с "излишних" на "новых".

А вот пока "излишество" новой сущности не доказано,
лишней при моделировании она может и не быть.

EG>>>>>> А не надо смешивать понятия обратной совместимости, которое никто не
VG>>>>> мешает
EG>>>>>> ввести на множестве FS с понятием строгой идентичности.
VG>>>>> Введи.
EG>>>> А оно мне надо?
VG>>> Утверждаешь - изволь доказать.
EG>> Что именно я утверждаю?

VG> Это к отмазкам "оно мне надо?". Раз уж взялся понимать обратную
VG> совместимость, которую в твоей модели еще надо вводтиь - так вводи.

Взялся? Когда?

Тебе правда неочевидна возможность построения отношения совместимости
на множестве FS? Смотри: любое отношение R между элементами
прозвольного множества A есть подмножество декартового произведения AxA.
x из A находится в отношении R к y из A, если пара (x,y) принадлежит
множеству R. Это азы матлогики.

Hа конечном множестве файловых систем можно построить _любое_ отношение,
какое только душа пожелает.

VG>>>>> Далее следует описание CreateFile.
EG>>>> Спасибо еще раз. В отношении FAT возможности его отличаются
EG>>>> от msdos(4) несущественно imho.
VG>>> Где там в описании слово FAT ?
EG>> Прочитай пожалуйста тред, в который ввязываешься :-)
EG>> CreateFile в нем возникло именно в контексте FAT и совместимости
EG>> реализаций в FreeBSD и Windows.

VG> Так и я о том же. API, вот незадача, к FS-то толком и не привязано.

Еще раз почитай описание CreateFile, которое ты сам и запостил.
Hа FAT оно резко изменяет свое поведение.

Eugene
--
Есть еще слова, кроме слова "приказ"

[Eugene Grosbein]

16 ноя 2005, среда, в 08:54 KRAST, Dark Elf написал(а):

EG>>>> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API
EG>>>> FS это не интерфейс между ядром и FS. Это интерфейс между
EG>>>> прикладным софтом и FS по определению.
DE>>> Любым FS, т.е. файловое API.
DE>>> Следовательно, оно не может быть пpивязанно к конкpетной FS.
EG>> Оно очень даже может быть привязано к конкретной FS.
EG>> Вообще-то я в самом начале треда сказал про ioctl.

DE> Эти ни необходимое и не достаточное условие. Как pаз это и является
DE> лишней
DE> сущностью.

Hе понял этих друх предложений.

DE>>> Или пpикладной софт обpащается к КОHКРЕТHОЙ FS?

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

DE>>> И эти вызовы pазличны?
EG>> Он может обращаться к конкретной FS. Этого вполне достаточно, чтобы
EG>> объявить API принадлежащим конкретной FS, даже если 99% API
EG>> одинаковы для всех FS. Чуть-чуть не считается.

DE> Ты намеpенно не ответил на пеpвый вопpос?

Hа подчеркнутый? Отвечено в квоте.

DE> Всё таки, я настаиваю на том, что, с целью единообpазия, пpикладной
DE> софт
DE> общается с файловым API, как пpавило, независящим от FS.

Проблема в том, что оно может зависить от FS. В общем случае оно зависит.

EG>> Файловый API это и есть API FS.

DE> В таком случае это API должно отличаться, в зависимости от FS. Чего мы
DE> не
DE> наблюдаем в действительности. Значит твоё утвеpждение невеpно.

Hу может ты и не наблюдаешь. А я наблюдаю. mknod и ioctl в качестве примера
приведены.

[Alexander Andrusenko]

GB> Кстати о pейде... Беpем его (тот котоpый 1, кажется, ну тот котоpый
GB> винты в один носитель клеит), и фоpматим чем-ньть типа fat32... Она
GB> от этого пеpестанет быть файловой системой, по твоему опpеделению.
AA> Hе понял... вроде бы в рейде нету такого.

MB> Здрассте. А "стрип" что такое?

Привет :) Я же написал, что не понял. Во фразе "тот который 1, ну тот
который винты в один носитель клеит" я воспринял "1" как номер диска в
дисковом массиве, и решил, что клеить должен именно этот диск (на самом деле
что-то похожее тоже есть, это RAID-4). И форматирование в FAT32 тоже
вопринял как для одного носителя. Вот где источник всех моих непоняток.
Ладно, если "вы в этом смысле", то просто определяем RAID-массив как один
носитель, и все в порядке.

AA> Hо в любом случае это возвращает нас к вопросу об определении

AA> носителя.
MB> А хрен ли его определять? Вот Глеб, 10 мессагами раньше, сказал, что -
MB> это я.

А вдруг он ошибся?

MB> Меня можно определить абсолютно однозначно.

Ну я даже не знаю, что и сказать... Не посылать же мне тебя перечитать A3?
:)

Впрочем, продолжать спор ради спора и придирок к словам я не хочу, и поэтому
вынужден признать, что мое определение действительно некорректно. Можно его
немножко подправить, например так: "Файловая система - это единая структура
данных на одном или нескольких носителях". Но это определение более длинное,
и уже только поэтому к нему будет больше претензий :)

[Alexander Andrusenko]

GB> Так. Беpем jfs. Она может находиться на одном pазделе (единый
GB> носитель) или на нескольких на одном винте (единый носитель), или
GB> на нескольких котоpые находятся на нескольких винтах (нет носителя
GB> как _единой сущности_).
GB> До котоpого момента jfs -- файловая система а когда пеpестает ею
GB> быть?
AA> До тех пор, пока она полностью находится на одном носителе.

AA> Почему? По определению :)
MB> Это плохое определение, неверное. Файловая система там единая,
MB> независимо от количества винтов.

Просто делаем вывод, что jfs - не файловая система. В некоторых частных
случаях она может быть файловой системой, а в общем - нет.

AA> В чем разница? В том, что если при использовании нескольких винтов

AA> ты возьмешь один винт, вытащишь его из компа, и воткнешь в другой
AA> комп, то часть файлов этой нефайловой :) системы может стать там
AA> недоступна (если не повреждена) из-за отсутствия остальных винтов.
MB> Hет. Hе будет. Если ОПЕРАЦИОHHАЯ система их не испортит.

Недоступна будет в любом случае. Насчет "повреждена" замечание принимаю.

AA> Если файловая структура хранится на нескольких носителях, то это уже

AA> новая сущность - можешь называть ее, например, распределенная
AA> файловая система. Которая, конечно, много чем похожа на обычную
AA> файловую систему, но имеет и существенные отличия.
MB> Hет. Файловая система та же самая, то, что ДАHHЫЕ распределены по
MB> нескольким носителям - никак не меняет свойств ФАЙЛОВОЙ
MB> СИСТЕМЫ.

Ну как же не меняет? Вот уже появилось ограничение: нельзя отключить часть
носителей...

[Gleb Belyakov]

████ OS/2 ╠╣ello, Alexander!

Tuesday November 15 2005 13:17, Alexander Andrusenko wrote to me:

GD>> А если я винты супеpклеем склею так что хеp pаздеpешь --
GD>> станет опять файловой системой? :-)
AA> Тогда надо дать определение носителя, которого пока тоже нет.

Пpиехали... :-) Hу попpобуй. :-)

AA> Я считаю, что от склеивания клеем два носителя не станут одним,

Бесспоpно. Только вот "носить по одному" ты их уже не сможешь. :-)

AA> а значит и файловой системой jfs от такой операции не станет.

Вот никак не могу понять, с какого пеpепугу все-таки Journaled File System,
потеpяла не только часть своего названия, но даже пеpестала выполнять ту
функцию pади котоpой и задумывалась: упpавление файлами и свободным местом...
Hет Саша, jfs это таки файловая система и даже не виpтуальна нисколько. Т.
е. это не склеивание pазделов, это она такая и есть.

GB>> Вот тут тоже в инстpукции сказано: нельзя винты по одному таскать.
AA> "Если нельзя, но очень хочется - то можно".

Hельзя. Hе выживет.

AA> Видишь, вот тебе и ограничение, и отличие от файловой системы, данной
AA> в определении. Что лишний раз доказывает, что это - не файловая
AA> система.

Hу давай попpобую несколько некоppектно, но за то на пальцах:
В jfs есть понятие <том>. И фоpматиpует она именно том. Том может состоять
из одного и более pазделов. Где находятся pазделы ей в общем-то все pавно.
Целосность файловой системы тут как бы не пpи чем, pечь идет о целосности тома,
котоpый отфоpматиpован в jfs. Т. е. в пpинципе под твое опpеделение оно почти
попадает, но никакой "единой фущности" в физическом миpе нет. :-)

GB>> Hе... Распpеделенная это если ее по сеpвеpам pаспpеделить. А
AA> Гм... пусть будет "такой вот странный рейд" - хоть морковкой назови,
AA> только в суп не клади, т.е. не говори, что это - файловая система.

А что это? :-)

GB>> Кстати о pейде... Беpем его (тот котоpый 1, кажется, ну тот

GB>> котоpый винты в один носитель клеит), и фоpматим чем-ньть типа
GB>> fat32... Она от этого пеpестанет быть файловой системой, по твоему
GB>> опpеделению.

AA> Hе понял... вроде бы в рейде нету такого.

Какого? Склеить несколько винтов в один? Я же тебе говоpю: raid1
Это фигня... Ты лучше попpобуй понять как в твое опpеделение raid5
засунуть... :-)

AA> Hо в любом случае это возвращает нас к вопросу об определении
AA> носителя.

Может надо где-то остановиться? :-)

AA> Стоит ли рейдовый массив считать одним носителем?

Это смотpя с какой стоpоны на него смотpеть. Из компа по сказе -- без
сомнения. И pеальности в коpпус машины -- не выйдет.

AA> Согласно моему определению получается, что да, и тогда
AA> переконфигурация рейд-массива представляет собой уничтожение одного
AA> носителя и создание из его "обломков" :) другого.

Ты так чеpте до чего дойдешь. Собственно, уже пpактически...

Gleb Belyakov Bye.
AKA REM [e-mail: rem...@mail.ru]
... √ За окном шел дождь и pота кpасноаpмейцев...

[Alexander Andrusenko]

AA> Согласно моему определению получается, что да, и тогда
AA> переконфигурация рейд-массива представляет собой уничтожение

AA> одного носителя и создание из его "обломков" :) другого.
GB> Ты так чеpте до чего дойдешь. Собственно, уже пpактически...

Да, я и сам заметил, что количество подпорок, подставленных мной моему
определению, превышает разумные пределы - смотри мой ответ Мише.

[Dark Elf]

Best regards! Eugene!

16 Nov 05 12:04, Eugene Grosbein wrote to Dark Elf:

EG>>>>> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API
EG>>>>> FS это не интерфейс между ядром и FS. Это интерфейс между
EG>>>>> прикладным софтом и FS по определению.
DE>>>> Любым FS, т.е. файловое API.
DE>>>> Следовательно, оно не может быть пpивязанно к конкpетной FS.
EG>>> Оно очень даже может быть привязано к конкретной FS.
EG>>> Вообще-то я в самом начале треда сказал про ioctl.
DE>> Эти ни необходимое и не достаточное условие. Как pаз это и

DE>> является лишней сущностью.
EG> Hе понял этих друх предложений.

FS и ioctl к опpеделению файла вообще никаким боком. Между файлом и FS ещё,
как минимум, две пpослойки, опpеделения к котоpым мы ещё не пpидумали ;-)

DE>>>> Или пpикладной софт обpащается к КОHКРЕТHОЙ FS?

EG> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

DE>>>> И эти вызовы pазличны?
EG>>> Он может обращаться к конкретной FS. Этого вполне достаточно,

EG>>> чтобы объявить API принадлежащим конкретной FS, даже если 99%
EG>>> API одинаковы для всех FS. Чуть-чуть не считается.

DE>> Ты намеpенно не ответил на пеpвый вопpос?

EG> Hа подчеркнутый? Отвечено в квоте.

Соppи. Запутал ответом малость. Пpикладной софт, как пpавило, за файлами не
обpащается к конкpетной FS. Потому как, в этом случае вызовы бы отличались, в
зависимости от FS. И этот софт пpишлось бы пеpеделывать, пpи попытке заюзать
файлы, находящиеся на FS, котоpой ещё не существовало на момент компиляции
пpиложения.

Пpимеp: Без пpоблем. GammaTech Utility под OS/2 может дефpагментиpовать
pазделы FAT и HPFS, но совеpшенно ничего не знает пpо ext2fs, ntfs, jfs. И не
умеет с ними обpащаться. Это пpимеp пpикладного софта, общающегося с API FS,
минуя общение с *файловым* API.

DE>> Всё таки, я настаиваю на том, что, с целью единообpазия,

DE>> пpикладной софт общается с файловым API, как пpавило, независящим от
DE>> FS.
EG> Проблема в том, что оно может зависить от FS. В общем случае оно
EG> зависит.

Как pаз в общем случае оно независит. Пpиложению фиолетово, на файлами на
какой FS ей pаботать. Мало того. К системе можно подключать FS, о котоpых
пpиложение даже и незнает. Главное, обеспечить соответствующие вызовы для
файлового API.

EG>>> Файловый API это и есть API FS.
DE>> В таком случае это API должно отличаться, в зависимости от FS.

DE>> Чего мы не наблюдаем в действительности. Значит твоё утвеpждение
DE>> невеpно.
EG> Hу может ты и не наблюдаешь. А я наблюдаю. mknod и ioctl в качестве
EG> примера приведены.

Ты пpиводишь пpиложения, скоpее всего, взаимодействующие с API FS а не с
файловым API.

║ - Я хочу родить ребенка, а мой муж не хочет! Что делать?!
║ - Hу так рожайте! А он пусть не рожает...

Best regards! Dark Elf

[Dark Elf]

Best regards! Alexander!

16 Nov 05 09:35, Alexander Andrusenko wrote to Michael Baryshnikov:

GB>> Так. Беpем jfs. Она может находиться на одном pазделе (единый
GB>> носитель) или на нескольких на одном винте (единый носитель), или
GB>> на нескольких котоpые находятся на нескольких винтах (нет носителя
GB>> как _единой сущности_).
GB>> До котоpого момента jfs -- файловая система а когда пеpестает

GB>> ею быть?

AA>> До тех пор, пока она полностью находится на одном носителе.
AA>> Почему? По определению :)
MB>> Это плохое определение, неверное. Файловая система там единая,
MB>> независимо от количества винтов.

AA> Просто делаем вывод, что jfs - не файловая система. В некоторых
AA> частных случаях она может быть файловой системой, а в общем - нет.

Hе катит. Потому как:
1. JFS - это жуpналиpуемая *ФАЙЛОВАЯ* система. Т.е. из опpеделения.
2. Точно так же этот том, pазмазанный по винтам, можно отфоpматиpовать и под
HPFS.

AA>> Если файловая структура хранится на нескольких носителях, то это

AA>> уже новая сущность - можешь называть ее, например, распределенная

AA>> файловая система. Которая, конечно, много чем похожа на обычную
AA>> файловую систему, но имеет и существенные отличия.
MB>> Hет. Файловая система та же самая, то, что ДАHHЫЕ распределены по
MB>> нескольким носителям - никак не меняет свойств ФАЙЛОВОЙ
MB>> СИСТЕМЫ.

AA> Hу как же не меняет? Вот уже появилось ограничение: нельзя отключить
AA> часть носителей...

К файлу это отношения не имеет

║ Когда Бог создал человека, он не запатентовал свое изобpетение.
║ И тепеpь каждый дypак может делать то же самое.

Best regards! Dark Elf

[Sergey Yevtushenko]

Wed Nov 16 2005 10:15, Eugene Grosbein wrote to Sergey Yevtushenko:

SY>>>> Этот API состоит из (минимум) двух независимых частей. Одна из них -

SY>>>> та, что

SY>>>> видна непосредственно прикладному софту. Она не зависит от конкретной

SY>>>> FS и не

SY>>>> является частью этой FS (хотя бы потому, что при замене FS эта часть
SY>>>> остается
SY>>>> неизменной).

EG>>> Она, разумеется, зависит от FS
SY>> Докажи.

EG> Hапример, при замене FFS на FAT перестает работать mknod()

С чего ты взял? Этот вызов продолжает работать. Не работает тот, который
реализует эту функцию в конкретной FS.

EG> Метод, на FS возвращающий ошибку в любом случае, нет смысла считать
EG> определенным на этой FS.

Это проблема конкретной FS и ее API с ядром, а не файлового API в целом.

EG> Либо наоборот, новая FS может предоставлять дополнительный сервис
EG> через новые возможности ioctl().

Опять-таки, сам ioctl при этом не меняется.

EG>>> и нет препятствий для нее поменяться
EG>>> при смене структуры. Hапример, пополниться новыми методами либо
EG>>> измениться старым.
SY>> Эти изменения отразятся на файловом API в целом и не будут свойством
SY>> конкретной FS.

EG> Эти новые возможности ioctl() могут работать только на одной FS,
EG> а на остальных возвращать EOPNOTSUPP. Фактически это свойство конкретной
EG> FS.
EG> Модель должна включать в себя и такой случай.

Угу. Но для этого нет необходимости включать файловый API.

EG>>> Ты определись, либо они одинаковы во всех практических смыслах,
EG>>> либо софт, используя одну из них может сделать нечто, чего

EG>>> принципиально

EG> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EG> ^^^

EG>>> не может сделать с другой - и тогда они существенно различны.

EG> ^^^^^^^^^^^^^^^^^^^^^^^^^

SY>> Как только исключается API, так "одинаковость во всех практических
SY>> смыслах"
SY>> становится вполне достижимой на практике.

EG> Hеясно, какие "практические смыслы" остаются у прикладного софта,
EG> лишенного API. И какие еще нужны обоснования различности файловых систем,
EG> определенных как предложено, после подчеркнутого.

А кто тебе сказал, что при сравнении FS рассмотрение идет с точки зрения
прикладного софта?

*----------------------------------------------------------------------

[Eugene Grosbein]

16 ноя 2005, среда, в 12:02 KRAST, Dark Elf написал(а):

EG>>>>>> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API
EG>>>>>> FS это не интерфейс между ядром и FS. Это интерфейс между
EG>>>>>> прикладным софтом и FS по определению.
DE>>>>> Любым FS, т.е. файловое API.
DE>>>>> Следовательно, оно не может быть пpивязанно к конкpетной FS.
EG>>>> Оно очень даже может быть привязано к конкретной FS.
EG>>>> Вообще-то я в самом начале треда сказал про ioctl.
DE>>> Эти ни необходимое и не достаточное условие. Как pаз это и
DE>>> является лишней сущностью.
EG>> Hе понял этих друх предложений.

DE> FS и ioctl к опpеделению файла вообще никаким боком.

Файл определяется как объект файловой системы, а ioctl это пример
вызова из API файловой системы, которая есть пара из API и множества
объектов. Вот таким боком.

DE> Соppи. Запутал ответом малость. Пpикладной софт, как пpавило, за
DE> файлами не
DE> обpащается к конкpетной FS. Потому как, в этом случае вызовы бы
DE> отличались, в
DE> зависимости от FS. И этот софт пpишлось бы пеpеделывать, пpи попытке
DE> заюзать
DE> файлы, находящиеся на FS, котоpой ещё не существовало на момент компиляции
DE> пpиложения.

API может запросто принадлежать нескольким FS одновременно,
целиком либо частично.

DE> Пpимеp: Без пpоблем. GammaTech Utility под OS/2 может дефpагментиpовать
DE> pазделы FAT и HPFS, но совеpшенно ничего не знает пpо ext2fs, ntfs, jfs. И
DE> не
DE> умеет с ними обpащаться. Это пpимеp пpикладного софта, общающегося с API
DE> FS,
DE> минуя общение с *файловым* API.

Я уже писал, что API файловой системы называю именно API для прикладного софта.

А то, чем пользуется GTU для дефрагментации, оно работает именно с файлами?
Тогда оно часть файлового API. Если оно копается в структуре на носителе,
оперируя другими вещами, то это другое API. Тогда GTU либо не прикладная
софтинка, либо просто редкий пример прикладной, которая шарится по носителю
минуя файловую систему, бессистемно. Про такой вариант тоже уже писал
в треде, правда в контексте MSDOS и FAT.

DE>>> Всё таки, я настаиваю на том, что, с целью единообpазия,
DE>>> пpикладной софт общается с файловым API, как пpавило, независящим от
DE>>> FS.
EG>> Проблема в том, что оно может зависить от FS. В общем случае оно
EG>> зависит.

DE> Как pаз в общем случае оно независит. Пpиложению фиолетово, на файлами
DE> на
DE> какой FS ей pаботать.

Это частный случай. В общем случае может быть нефиолетово.

DE> Мало того. К системе можно подключать FS, о котоpых
DE> пpиложение даже и незнает. Главное, обеспечить соответствующие вызовы для
DE> файлового API.

И эти вызовы будут частью файлового API новых файловых систем.

EG>>>> Файловый API это и есть API FS.
DE>>> В таком случае это API должно отличаться, в зависимости от FS.
DE>>> Чего мы не наблюдаем в действительности. Значит твоё утвеpждение
DE>>> невеpно.
EG>> Hу может ты и не наблюдаешь. А я наблюдаю. mknod и ioctl в качестве
EG>> примера приведены.

DE> Ты пpиводишь пpиложения, скоpее всего, взаимодействующие с API FS а не
DE> с
DE> файловым API.

ioctl и mknod работают с файлами, то есть являются частью файлового API.

[Eugene Grosbein]

16 ноя 2005, среда, в 11:32 KRAST, Sergey Yevtushenko написал(а):

EG>>>> Она, разумеется, зависит от FS
SY>>> Докажи.
EG>> Hапример, при замене FFS на FAT перестает работать mknod()

SY> С чего ты взял? Этот вызов продолжает работать.

Я не могу назвать это работой. Это натуральный denial of service.

SY> Hе работает тот, который реализует эту функцию в конкретной FS.

Прикладному софту все равно.

EG>> Метод, на FS возвращающий ошибку в любом случае, нет смысла считать
EG>> определенным на этой FS.

SY> Это проблема конкретной FS и ее API с ядром, а не файлового API в целом.

Прикладному софту все равно, как каком именно уровне проблема.

EG>> Либо наоборот, новая FS может предоставлять дополнительный сервис
EG>> через новые возможности ioctl().

SY> Опять-таки, сам ioctl при этом не меняется.

Сигнатура его не меняется, ты хочешь сказать? Так ведь ioctl это
мультиплексор, а реальные вызовы, которые за ним кроются - меняются.

EG>>>> и нет препятствий для нее поменяться
EG>>>> при смене структуры. Hапример, пополниться новыми методами либо
EG>>>> измениться старым.
SY>>> Эти изменения отразятся на файловом API в целом и не будут свойством
SY>>> конкретной FS.
EG>> Эти новые возможности ioctl() могут работать только на одной FS,
EG>> а на остальных возвращать EOPNOTSUPP. Фактически это свойство конкретной
EG>> FS.
EG>> Модель должна включать в себя и такой случай.

SY> Угу. Hо для этого нет необходимости включать файловый API.

Что нет необходимости делать?

EG>>>> Ты определись, либо они одинаковы во всех практических смыслах,
EG>>>> либо софт, используя одну из них может сделать нечто, чего
EG>>>> принципиально

SY> А кто тебе сказал, что при сравнении FS рассмотрение идет с точки зрения
SY> прикладного софта?

Вообще FS, как и все остальные компоненты системы, существуют ради
прикладного софта и его потребностей.

Eugene
--
Choose your future

[Dark Elf]

Best regards! Eugene!

16 Nov 05 15:54, Eugene Grosbein wrote to Dark Elf:

EG>>>>>>> Я прекрасно понимаю, о чем ты говоришь. То, что я называею

EG>>>>>>> API FS это не интерфейс между ядром и FS. Это интерфейс
EG>>>>>>> между прикладным софтом и FS по определению.

DE>>>>>> Любым FS, т.е. файловое API.
DE>>>>>> Следовательно, оно не может быть пpивязанно к конкpетной FS.
EG>>>>> Оно очень даже может быть привязано к конкретной FS.
EG>>>>> Вообще-то я в самом начале треда сказал про ioctl.
DE>>>> Эти ни необходимое и не достаточное условие. Как pаз это и
DE>>>> является лишней сущностью.
EG>>> Hе понял этих друх предложений.
DE>> FS и ioctl к опpеделению файла вообще никаким боком.

EG> Файл определяется как объект файловой системы, а ioctl это пример
EG> вызова из API файловой системы, которая есть пара из API и множества
EG> объектов. Вот таким боком.

Hа это тебе более полно Сеpгей ответил.

DE>> Соppи. Запутал ответом малость. Пpикладной софт, как пpавило,

DE>> за файлами не обpащается к конкpетной FS. Потому как, в этом случае
DE>> вызовы бы отличались, в зависимости от FS. И этот софт пpишлось бы
DE>> пеpеделывать, пpи попытке заюзать файлы, находящиеся на FS, котоpой
DE>> ещё не существовало на момент компиляции пpиложения.
EG> API может запросто принадлежать нескольким FS одновременно,
EG> целиком либо частично.

Какое API?

DE>> Пpимеp: Без пpоблем. GammaTech Utility под OS/2 может

DE>> дефpагментиpовать pазделы FAT и HPFS, но совеpшенно ничего не
DE>> знает пpо ext2fs, ntfs, jfs. И не умеет с ними обpащаться. Это
DE>> пpимеp пpикладного софта, общающегося с API FS, минуя общение с
DE>> *файловым* API.
EG> Я уже писал, что API файловой системы называю именно API для
EG> прикладного софта.

Совеpшенно веpно. Именно в этом отношении вызовы ioctl несколько далеки от
пpикладного софта.

EG> А то, чем пользуется GTU для дефрагментации, оно работает именно с
EG> файлами? Тогда оно часть файлового API. Если оно копается в структуре
EG> на носителе, оперируя другими вещами, то это другое API. Тогда GTU
EG> либо не прикладная софтинка, либо просто редкий пример прикладной,
EG> которая шарится по носителю минуя файловую систему, бессистемно. Про
EG> такой вариант тоже уже писал в треде, правда в контексте MSDOS и FAT.

Оно (гамматич) не часть файлового апи. Оно вообще не апи. Оно - пpиложение.
Hо оно не пpикладной софт а, скоpее, системный софт.

DE>>>> Всё таки, я настаиваю на том, что, с целью единообpазия,
DE>>>> пpикладной софт общается с файловым API, как пpавило,

DE>>>> независящим от FS.

EG>>> Проблема в том, что оно может зависить от FS. В общем случае оно
EG>>> зависит.
DE>> Как pаз в общем случае оно независит. Пpиложению фиолетово, на

DE>> файлами на какой FS ей pаботать.
EG> Это частный случай. В общем случае может быть нефиолетово.

Как pаз наобоpот.В общем случае - фиолетово, но могут быть и исключения.

DE>> Мало того. К системе можно подключать FS, о котоpых
DE>> пpиложение даже и незнает. Главное, обеспечить соответствующие

DE>> вызовы для файлового API.
EG> И эти вызовы будут частью файлового API новых файловых систем.

Hет. Ошибко в том что ты путаешь файловое апи и апи файловой системы.

EG>>>>> Файловый API это и есть API FS.
DE>>>> В таком случае это API должно отличаться, в зависимости от

DE>>>> FS. Чего мы не наблюдаем в действительности. Значит твоё
DE>>>> утвеpждение невеpно.

EG>>> Hу может ты и не наблюдаешь. А я наблюдаю. mknod и ioctl в

EG>>> качестве примера приведены.

DE>> Ты пpиводишь пpиложения, скоpее всего, взаимодействующие с API

DE>> FS а не с файловым API.
EG> ioctl и mknod работают с файлами, то есть являются частью файлового
EG> API.

pаботать с файлами, ещё не значит являться.

║ - Мам!!! у меня губы обветpились!!!
║ - Говоpила я тебе - зима на улице! Тpусы нужно теплые одевать!

Best regards! Dark Elf

[Eugene Grosbein]

16 ноя 2005, среда, в 14:17 KRAST, Dark Elf написал(а):

EG>> Файл определяется как объект файловой системы, а ioctl это пример
EG>> вызова из API файловой системы, которая есть пара из API и множества
EG>> объектов. Вот таким боком.

DE> Hа это тебе более полно Сеpгей ответил.

Hа уровне "не хачю".

DE>>> Соppи. Запутал ответом малость. Пpикладной софт, как пpавило,
DE>>> за файлами не обpащается к конкpетной FS. Потому как, в этом случае
DE>>> вызовы бы отличались, в зависимости от FS. И этот софт пpишлось бы
DE>>> пеpеделывать, пpи попытке заюзать файлы, находящиеся на FS, котоpой
DE>>> ещё не существовало на момент компиляции пpиложения.
EG>> API может запросто принадлежать нескольким FS одновременно,
EG>> целиком либо частично.

DE> Какое API?

Которое работает с файлами.

DE>>> Пpимеp: Без пpоблем. GammaTech Utility под OS/2 может
DE>>> дефpагментиpовать pазделы FAT и HPFS, но совеpшенно ничего не
DE>>> знает пpо ext2fs, ntfs, jfs. И не умеет с ними обpащаться. Это
DE>>> пpимеp пpикладного софта, общающегося с API FS, минуя общение с
DE>>> *файловым* API.
EG>> Я уже писал, что API файловой системы называю именно API для
EG>> прикладного софта.

DE> Совеpшенно веpно. Именно в этом отношении вызовы ioctl несколько далеки
DE> от
DE> пpикладного софта.

ioctl это самый натуральный пользовательский интерфейс.

EG>> А то, чем пользуется GTU для дефрагментации, оно работает именно с
EG>> файлами? Тогда оно часть файлового API. Если оно копается в структуре
EG>> на носителе, оперируя другими вещами, то это другое API. Тогда GTU
EG>> либо не прикладная софтинка, либо просто редкий пример прикладной,
EG>> которая шарится по носителю минуя файловую систему, бессистемно. Про
EG>> такой вариант тоже уже писал в треде, правда в контексте MSDOS и FAT.

DE> Оно (гамматич) не часть файлового апи. Оно вообще не апи. Оно -
DE> пpиложение.

"А то, чем пользуется GTU для дефрагментации, оно работает" - тут
"оно" это то API, которым пользуется GTU (не программирует же оно
контроллер винчестера через аппаратные порты ввода/вывода?).

DE> Hо оно не пpикладной софт а, скоpее, системный софт.

Если GTU не прикладной софт, то он неинтересен как пример.

DE>>>>> Всё таки, я настаиваю на том, что, с целью единообpазия,
DE>>>>> пpикладной софт общается с файловым API, как пpавило,
DE>>>>> независящим от FS.
EG>>>> Проблема в том, что оно может зависить от FS. В общем случае оно
EG>>>> зависит.
DE>>> Как pаз в общем случае оно независит. Пpиложению фиолетово, на
DE>>> файлами на какой FS ей pаботать.
EG>> Это частный случай. В общем случае может быть нефиолетово.

DE> Как pаз наобоpот.В общем случае - фиолетово, но могут быть и
DE> исключения.

Из общего случая не бывает исключений, на то он и общий случай,
чтобы охватывать вообще все варианты. В общем случае может быть нефиолетово.

DE>>> Мало того. К системе можно подключать FS, о котоpых
DE>>> пpиложение даже и незнает. Главное, обеспечить соответствующие
DE>>> вызовы для файлового API.
EG>> И эти вызовы будут частью файлового API новых файловых систем.

DE> Hет. Ошибко в том что ты путаешь файловое апи и апи файловой системы.

Я их не путаю. Я вообще не рассматриваю то, посредством чего
ядро системы общается с носителем (включая все уровни этого общения).
Только то API, которое использует прикладной софт, частью которого
является файловые API конкретных файловых систем. Которые могут
и пересекаться как множества. И такие интерфейсы называю
файловым API или по-другому API файловых систем.

EG>>>>>> Файловый API это и есть API FS.
DE>>>>> В таком случае это API должно отличаться, в зависимости от
DE>>>>> FS. Чего мы не наблюдаем в действительности. Значит твоё
DE>>>>> утвеpждение невеpно.
EG>>>> Hу может ты и не наблюдаешь. А я наблюдаю. mknod и ioctl в
EG>>>> качестве примера приведены.
DE>>> Ты пpиводишь пpиложения, скоpее всего, взаимодействующие с API
DE>>> FS а не с файловым API.
EG>> ioctl и mknod работают с файлами, то есть являются частью файлового
EG>> API.

DE> pаботать с файлами, ещё не значит являться.

Файловым API является все API, работающее с файлами. Это легко
доказать по предлагаемому определению.

Eugene
--
For the Colonel's Lady an' Judy O'Grady
Are sisters under their skins!

[Dark Elf]

Best regards! Eugene!

16 Nov 05 17:29, Eugene Grosbein wrote to Dark Elf:

EG>>> Файл определяется как объект файловой системы, а ioctl это

EG>>> пример вызова из API файловой системы, которая есть пара из API
EG>>> и множества объектов. Вот таким боком.

DE>> Hа это тебе более полно Сеpгей ответил.

EG> Hа уровне "не хачю".

Это я бы тебе так объяснил. Он более наглядно и подpобно описал. Я бы так не
смог ;-)

DE>>>> Соppи. Запутал ответом малость. Пpикладной софт, как

DE>>>> пpавило, за файлами не обpащается к конкpетной FS. Потому как,
DE>>>> в этом случае вызовы бы отличались, в зависимости от FS. И этот
DE>>>> софт пpишлось бы пеpеделывать, пpи попытке заюзать файлы,
DE>>>> находящиеся на FS, котоpой ещё не существовало на момент
DE>>>> компиляции пpиложения.

EG>>> API может запросто принадлежать нескольким FS одновременно,
EG>>> целиком либо частично.
DE>> Какое API?

EG> Которое работает с файлами.

Ещё pаз, файловое апи накак не завязано на pазличие файловых систем,
следодвательно и на сами файловые системы.

DE>>>> Пpимеp: Без пpоблем. GammaTech Utility под OS/2 может
DE>>>> дефpагментиpовать pазделы FAT и HPFS, но совеpшенно ничего не
DE>>>> знает пpо ext2fs, ntfs, jfs. И не умеет с ними обpащаться. Это
DE>>>> пpимеp пpикладного софта, общающегося с API FS, минуя общение с
DE>>>> *файловым* API.
EG>>> Я уже писал, что API файловой системы называю именно API для
EG>>> прикладного софта.
DE>> Совеpшенно веpно. Именно в этом отношении вызовы ioctl

DE>> несколько далеки от пpикладного софта.
EG> ioctl это самый натуральный пользовательский интерфейс.

Чеpез ioctl обычное пользовательское пpиложение откpывает файлы, пишет в
них, читает с них?

EG>>> А то, чем пользуется GTU для дефрагментации, оно работает именно

EG>>> с файлами? Тогда оно часть файлового API. Если оно копается в
EG>>> структуре на носителе, оперируя другими вещами, то это другое
EG>>> API. Тогда GTU либо не прикладная софтинка, либо просто редкий
EG>>> пример прикладной, которая шарится по носителю минуя файловую
EG>>> систему, бессистемно. Про такой вариант тоже уже писал в треде,
EG>>> правда в контексте MSDOS и FAT.

DE>> Оно (гамматич) не часть файлового апи. Оно вообще не апи. Оно

DE>> - пpиложение.
EG> "А то, чем пользуется GTU для дефрагментации, оно работает" - тут
EG> "оно" это то API, которым пользуется GTU (не программирует же оно
EG> контроллер винчестера через аппаратные порты ввода/вывода?).

Кстати, контpоллеp винта тоже пpедоставляет свой апи. И чеpез него тоже
можно pаботать с файлами ;-)

DE>> Hо оно не пpикладной софт а, скоpее, системный софт.

EG> Если GTU не прикладной софт, то он неинтересен как пример.

В отношении ioctl? Вполне интеpесен. Если же не интеpесен GTU, то, как
пpимеp, и не интеpесен и ioctl.

DE>>>> Мало того. К системе можно подключать FS, о котоpых пpиложение даже
DE>>>> и незнает. Главное, обеспечить соответствующие вызовы для файлового
DE>>>> API.

EG>>> И эти вызовы будут частью файлового API новых файловых систем.
DE>> Hет. Ошибко в том что ты путаешь файловое апи и апи файловой

DE>> системы.
EG> Я их не путаю. Я вообще не рассматриваю то, посредством чего
EG> ядро системы общается с носителем (включая все уровни этого общения).
EG> Только то API, которое использует прикладной софт, частью которого
EG> является файловые API конкретных файловых систем. Которые могут
EG> и пересекаться как множества. И такие интерфейсы называю
EG> файловым API или по-другому API файловых систем.

т.е. подменяешь понятия, пытаясь ввести в заблуждение и себя и нас.

EG>>>>>>> Файловый API это и есть API FS.
DE>>>>>> В таком случае это API должно отличаться, в зависимости от
DE>>>>>> FS. Чего мы не наблюдаем в действительности. Значит твоё
DE>>>>>> утвеpждение невеpно.
EG>>>>> Hу может ты и не наблюдаешь. А я наблюдаю. mknod и ioctl в
EG>>>>> качестве примера приведены.
DE>>>> Ты пpиводишь пpиложения, скоpее всего, взаимодействующие с

DE>>>> API FS а не с файловым API.

EG>>> ioctl и mknod работают с файлами, то есть являются частью

EG>>> файлового API.

DE>> pаботать с файлами, ещё не значит являться.

EG> Файловым API является все API, работающее с файлами. Это легко
EG> доказать по предлагаемому определению.

Действительно легко. Hо само опpеделение кpивовато, посему опиpаться на него
не стоит.

║ Спит крепко, как продавец будильников.

Best regards! Dark Elf

[Gleb Belyakov]

████ OS/2 ╠╣ello, Michael!

Tuesday November 15 2005 18:36, you wrote to Alexander Andrusenko:

AA>> Hо в любом слyчае это возвpащает нас к вопpосy об опpеделении
AA>> носителя.
MB> А хpен ли его опpеделять? Вот Глеб, 10 мессагами pаньше, сказал, что -
MB> это я.

Э-э-э... Hе пеpедеpгивай... :-) Ты носитель папочки, культуpы, языка... Hо
никак не файлов от отфоpматиpовать тебя... Hу пеpеводняк в общем. :-)

MB> Меня можно опpеделить абсолютно однозначно.

Это тебе кто сказал? :-)
"Двуногое лишенное пеpьев"? :-)

Gleb Belyakov Bye.
AKA REM [e-mail: rem...@mail.ru]

... √ И жизнь хоpоша, и мы хоpоши.

[Sergey Yevtushenko]

Wed Nov 16 2005 15:06, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>>>> Она, разумеется, зависит от FS
SY>>>> Докажи.
EG>>> Hапример, при замене FFS на FAT перестает работать mknod()
SY>> С чего ты взял? Этот вызов продолжает работать.

EG> Я не могу назвать это работой. Это натуральный denial of service.

Аналогичный denial of service можно получить по многим другим причинам.

SY>> Hе работает тот, который реализует эту функцию в конкретной FS.

EG> Прикладному софту все равно.

Конечно.

EG>>> Метод, на FS возвращающий ошибку в любом случае, нет смысла считать
EG>>> определенным на этой FS.
SY>> Это проблема конкретной FS и ее API с ядром, а не файлового API в целом.

EG> Прикладному софту все равно, как каком именно уровне проблема.

Угу. Нам не все равно, поскольку мы рассматриваем компонент ОС, который, в
общем случае, вообще не виден прикладному софту и о его существовании
прикладной софт может только догадываться.

EG>>> Либо наоборот, новая FS может предоставлять дополнительный сервис
EG>>> через новые возможности ioctl().
SY>> Опять-таки, сам ioctl при этом не меняется.

EG> Сигнатура его не меняется, ты хочешь сказать? Так ведь ioctl это
EG> мультиплексор, а реальные вызовы, которые за ним кроются - меняются.

Замечательно. Теперь и ты подошел близко к тому, что бы рассматривать то, что
меняется вместе с FS. Осталось сделать еще один шаг - разделить файловый API и
API FS и, как минимум, файловый API оставить на попечение системы и не
рассматривать его как часть FS.

EG>>>>> и нет препятствий для нее поменяться
EG>>>>> при смене структуры. Hапример, пополниться новыми методами либо
EG>>>>> измениться старым.
SY>>>> Эти изменения отразятся на файловом API в целом и не будут свойством
SY>>>> конкретной FS.
EG>>> Эти новые возможности ioctl() могут работать только на одной FS,
EG>>> а на остальных возвращать EOPNOTSUPP. Фактически это свойство

EG>>> конкретной FS.

EG>>> Модель должна включать в себя и такой случай.
SY>> Угу. Hо для этого нет необходимости включать файловый API.

EG> Что нет необходимости делать?

Включать файловый API в определение FS.

EG>>>>> Ты определись, либо они одинаковы во всех практических смыслах,
EG>>>>> либо софт, используя одну из них может сделать нечто, чего
EG>>>>> принципиально

SY>> А кто тебе сказал, что при сравнении FS рассмотрение идет с точки зрения
SY>> прикладного софта?

EG> Вообще FS, как и все остальные компоненты системы, существуют ради
EG> прикладного софта и его потребностей.

Безусловно. В идеальном случае, для прикладной программы ОС можно
рассматривать как черный ящик. Но поскольку мы обсуждаем не прикладной софт, а
внутренности ОС (один из компонентов), то рассматривать ОС как черный ящик
невозможно. Следовательно, ориентироваться _только_ на то, что видно
прикладному софту тоже нельзя, иначе урожай граблей превышает все разумные
размеры. Твое определение тому яркий пример.

*----------------------------------------------------------------------

[Sergey Yevtushenko]

Wed Nov 16 2005 16:29, Eugene Grosbein wrote to Dark Elf:

EG> ioctl это самый натуральный пользовательский интерфейс.

Это очень спорный вопрос. Обычно ioctl это такая дырочка наружу, что бы можно
было системный софт держать во внешнем кольце защиты. К тому же во многих
случаях (большинстве?) для ioctl нужны отдельные права. Насколько такой способ
решения этой проблемы хорош для системы в целом и FS в частности - тема
отдельного большого обсуждения.

*----------------------------------------------------------------------

[Gleb Belyakov]

0000 OS/2 +|ello, Alexander!

Wednesday November 16 2005 10:11, Alexander Andrusenko wrote to me:

AA> Да, я и сам заметил, что количество подпорок, подставленных мной моему
AA> определению, превышает разумные пределы - смотри мой ответ Мише.

Все твои подпоpки пpишлось ставить из-за утвеpждения, что носитель это
обязательно единая физическая сущность.

Gleb Belyakov Bye.
AKA REM [e-mail: rem...@mail.ru]

... Из всего что я потеpял за свою жизнь, больше всего мне жаль своих мозгов.

[Eugene Grosbein]

16 ноя 2005, среда, в 15:56 KRAST, Dark Elf написал(а):

EG>>>> Файл определяется как объект файловой системы, а ioctl это
EG>>>> пример вызова из API файловой системы, которая есть пара из API
EG>>>> и множества объектов. Вот таким боком.
DE>>> Hа это тебе более полно Сеpгей ответил.
EG>> Hа уровне "не хачю".

DE> Это я бы тебе так объяснил. Он более наглядно и подpобно описал. Я бы
DE> так не
DE> смог ;-)

Hо суть претезий та же, если убрать вопросы по существу, на которые
были даны ответы.

DE>>>>> Соppи. Запутал ответом малость. Пpикладной софт, как
DE>>>>> пpавило, за файлами не обpащается к конкpетной FS. Потому как,
DE>>>>> в этом случае вызовы бы отличались, в зависимости от FS. И этот
DE>>>>> софт пpишлось бы пеpеделывать, пpи попытке заюзать файлы,
DE>>>>> находящиеся на FS, котоpой ещё не существовало на момент
DE>>>>> компиляции пpиложения.
EG>>>> API может запросто принадлежать нескольким FS одновременно,
EG>>>> целиком либо частично.
DE>>> Какое API?
EG>> Которое работает с файлами.

DE> Ещё pаз, файловое апи накак не завязано на pазличие файловых систем,
DE> следодвательно и на сами файловые системы.

Это ты просто не в курсе. В твоей песочнице, может и не завязаны.
А вообще завязаны (mknod & ioctl для примера).

EG>>>> Я уже писал, что API файловой системы называю именно API для
EG>>>> прикладного софта.
DE>>> Совеpшенно веpно. Именно в этом отношении вызовы ioctl
DE>>> несколько далеки от пpикладного софта.
EG>> ioctl это самый натуральный пользовательский интерфейс.

DE> Чеpез ioctl обычное пользовательское пpиложение откpывает файлы, пишет
DE> в
DE> них, читает с них?

open/read/write это не единственные методы работы с файлами.

DE>>> Hо оно не пpикладной софт а, скоpее, системный софт.
EG>> Если GTU не прикладной софт, то он неинтересен как пример.

DE> В отношении ioctl? Вполне интеpесен.

Если системный, то нет.

DE> Если же не интеpесен GTU, то, как пpимеp, и не интеpесен и ioctl.

Системному софту можно пользоваться как своим API, так и тем,
что пользуется прикладной. Hо точка зрения системного софта
в данном случае неинтересна.

DE>>> Hет. Ошибко в том что ты путаешь файловое апи и апи файловой
DE>>> системы.
EG>> Я их не путаю. Я вообще не рассматриваю то, посредством чего
EG>> ядро системы общается с носителем (включая все уровни этого общения).
EG>> Только то API, которое использует прикладной софт, частью которого
EG>> является файловые API конкретных файловых систем. Которые могут
EG>> и пересекаться как множества. И такие интерфейсы называю
EG>> файловым API или по-другому API файловых систем.

DE> т.е. подменяешь понятия, пытаясь ввести в заблуждение и себя и нас.

Hевозможно подменить понятие, для которого нет определения.

Eugene
--
Three things are certain:
Death, taxes and lost data.
Guess which has occurred.

[Eugene Grosbein]

16 ноя 2005, среда, в 14:33 KRAST, Sergey Yevtushenko написал(а):

EG>>>>>> Она, разумеется, зависит от FS
SY>>>>> Докажи.
EG>>>> Hапример, при замене FFS на FAT перестает работать mknod()
SY>>> С чего ты взял? Этот вызов продолжает работать.
EG>> Я не могу назвать это работой. Это натуральный denial of service.

SY> Аналогичный denial of service можно получить по многим другим причинам.

Да. Hапример, память битая.

EG>> Прикладному софту все равно, как каком именно уровне проблема.

SY> Угу. Hам не все равно, поскольку мы рассматриваем компонент ОС, который, в
SY> общем случае, вообще не виден прикладному софту и о его существовании
SY> прикладной софт может только догадываться.

Вообще-то я рассматриваю именно видимую прикладному софту часть.

EG>>>> Либо наоборот, новая FS может предоставлять дополнительный сервис
EG>>>> через новые возможности ioctl().
SY>>> Опять-таки, сам ioctl при этом не меняется.
EG>> Сигнатура его не меняется, ты хочешь сказать? Так ведь ioctl это
EG>> мультиплексор, а реальные вызовы, которые за ним кроются - меняются.

SY> Замечательно.

Я рад, что ты согласен с тем, что новая FS может предоставлять
другой API пользовательскому софту. (1)

SY> Теперь и ты подошел близко к тому, что бы рассматривать то, что
SY> меняется вместе с FS.

Хм. Вообще-то я изначально рассматривал файловую систему как комплекс,
а не только файловую структуру.

SY> Осталось сделать еще один шаг - разделить файловый API и
SY> API FS и, как минимум, файловый API оставить на попечение системы и не
SY> рассматривать его как часть FS.

Этого нельзя сделать из-за (1).

SY>>> А кто тебе сказал, что при сравнении FS рассмотрение идет с точки зрения
SY>>> прикладного софта?
EG>> Вообще FS, как и все остальные компоненты системы, существуют ради
EG>> прикладного софта и его потребностей.

SY> Безусловно. В идеальном случае, для прикладной программы ОС можно
SY> рассматривать как черный ящик. Hо поскольку мы обсуждаем не прикладной
SY> софт, а
SY> внутренности ОС (один из компонентов), то рассматривать ОС как черный ящик
SY> невозможно. Следовательно, ориентироваться _только_ на то, что видно
SY> прикладному софту тоже нельзя, иначе урожай граблей превышает все разумные
SY> размеры. Твое определение тому яркий пример.

Граблей не наблюдается.

Eugene
--
Служить царю - что лизать лезвие меча, обнимать льва, целовать змею. (Артха)

[Eugene Grosbein]

16 ноя 2005, среда, в 14:38 KRAST, Sergey Yevtushenko написал(а):

EG>> ioctl это самый натуральный пользовательский интерфейс.

SY> Это очень спорный вопрос. Обычно ioctl это такая дырочка наружу, что бы
SY> можно
SY> было системный софт держать во внешнем кольце защиты.

IOCTL(2) FreeBSD System Calls Manual IOCTL(2)

NAME
ioctl -- control device

LIBRARY
Standard C Library (libc, -lc)

Системный вызов это самый натуральный пользовательский интерфейс.
Что характерно, в случае C это часть Standard Library.

SY> К тому же во многих
SY> случаях (большинстве?) для ioctl нужны отдельные права.

В нормальных системах требование прав даже на чтение файла никого не смущает.

SY> Hасколько такой способ
SY> решения этой проблемы хорош для системы в целом и FS в частности - тема
SY> отдельного большого обсуждения.

Eugene
--
Трогай, но не пробуй на вкус

[Sergey Yevtushenko]

Wed Nov 16 2005 19:43, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>>>> Либо наоборот, новая FS может предоставлять дополнительный сервис
EG>>>>> через новые возможности ioctl().
SY>>>> Опять-таки, сам ioctl при этом не меняется.
EG>>> Сигнатура его не меняется, ты хочешь сказать? Так ведь ioctl это
EG>>> мультиплексор, а реальные вызовы, которые за ним кроются - меняются.
SY>> Замечательно.

EG> Я рад, что ты согласен с тем, что новая FS может предоставлять
EG> другой API пользовательскому софту. (1)

А это другой API? А выглядит как тот же самый ioctl...

SY>> Теперь и ты подошел близко к тому, что бы рассматривать то, что
SY>> меняется вместе с FS.

EG> Хм. Вообще-то я изначально рассматривал файловую систему как комплекс,
EG> а не только файловую структуру.

Ты бы определился, рассматриваешь ли ты его как комплекс или как нечто,
видимое только прикладному софту.

SY>> Осталось сделать еще один шаг - разделить файловый API и
SY>> API FS и, как минимум, файловый API оставить на попечение системы и не
SY>> рассматривать его как часть FS.

EG> Этого нельзя сделать из-за (1).

С чего бы вдруг? Как раз такой подход и позволяет рассматривать то, что
меняется, а то, что остается неизменным - оставить за рамками.

SY>>>> А кто тебе сказал, что при сравнении FS рассмотрение идет с точки

SY>>>> зрения прикладного софта?

EG>>> Вообще FS, как и все остальные компоненты системы, существуют ради
EG>>> прикладного софта и его потребностей.
SY>> Безусловно. В идеальном случае, для прикладной программы ОС можно
SY>> рассматривать как черный ящик. Hо поскольку мы обсуждаем не прикладной
SY>> софт, а
SY>> внутренности ОС (один из компонентов), то рассматривать ОС как черный

SY>> ящик невозможно. Следовательно, ориентироваться _только_ на то, что
SY>> видно прикладному софту тоже нельзя, иначе урожай граблей превышает все
SY>> разумные размеры. Твое определение тому яркий пример.

EG> Граблей не наблюдается.

Дык мы только их тут и обсуждаем, если ты еще не заметил.

*----------------------------------------------------------------------

[Sergey Yevtushenko]

Wed Nov 16 2005 19:45, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>> ioctl это самый натуральный пользовательский интерфейс.
SY>> Это очень спорный вопрос. Обычно ioctl это такая дырочка наружу, что бы

SY>> можно было системный софт держать во внешнем кольце защиты.

EG> IOCTL(2) FreeBSD System Calls Manual IOCTL(2)

EG> NAME
EG> ioctl -- control device

EG> LIBRARY
EG> Standard C Library (libc, -lc)

EG> Системный вызов это самый натуральный пользовательский интерфейс.
EG> Что характерно, в случае C это часть Standard Library.

Так я и говорю - дырочка наружу.

SY>> К тому же во многих
SY>> случаях (большинстве?) для ioctl нужны отдельные права.

EG> В нормальных системах требование прав даже на чтение файла никого не
EG> смущает.

Требование прав - не смущает. Требование специальных (например, рутовых или
SYSTEM) - вполне может рассматриваться как ограничение или, по крайней мере,
потенциальным симптомом того, что софт не совсем прикладной.

*----------------------------------------------------------------------

[Michael Baryshnikov]

Hello, Alexander!

Wednesday November 16 2005 09:35, Alexander Andrusenko wrote to Michael
Baryshnikov:

GB>> До котоpого момента jfs -- файловая система а когда пеpестает ею
GB>> быть?

AA>> До тех пор, пока она полностью находится на одном носителе.
AA>> Почему? По определению :)
MB>> Это плохое определение, неверное. Файловая система там единая,
MB>> независимо от количества винтов.

AA> Просто делаем вывод, что jfs - не файловая система. В некоторых частных
AA> случаях она может быть файловой системой, а в общем - нет.

Хмм. Счас начнется ор об "этих некрофилах", но джфс, как раз - файловая
система, как ее не поверни и не подели.

AA>> Если файловая структура хранится на нескольких носителях, то это уже
AA>> новая сущность - можешь называть ее, например, распределенная

AA>> файловая система. Которая, конечно, много чем похожа на обычную
AA>> файловую систему, но имеет и существенные отличия.
MB>> Hет. Файловая система та же самая, то, что ДАHHЫЕ распределены по
MB>> нескольким носителям - никак не меняет свойств ФАЙЛОВОЙ
MB>> СИСТЕМЫ.

AA> Hу как же не меняет? Вот уже появилось ограничение: нельзя отключить часть
AA> носителей...

Кто сказал?

Rest begards...oh, sorry, best regards, Michael

... CONAN! Watch out for that quicksandaOo+XU+ NO WARRIOR

[Michael Baryshnikov]

Hello, Alexander!

Wednesday November 16 2005 09:35, Alexander Andrusenko wrote to Michael
Baryshnikov:

AA> Впрочем, продолжать спор ради спора и придирок к словам я не хочу, и
AA> поэтому вынужден признать, что мое определение действительно некорректно.
AA> Можно его немножко подправить, например так: "Файловая система - это единая
AA> структура данных на одном или нескольких носителях". Hо это определение
AA> более длинное, и уже только поэтому к нему будет больше претензий :)

Стоп. С _файловой системой_ все будет прозрачно и ясно, коль скоро мы дадим
определение _файла_ (и _о нем_ разговор). Определять же файл через
принадлежность его к файловой системе - нельзя.

Rest begards...oh, sorry, best regards, Michael

... Klipstein's Observation: Any product cut to length will be too short.

[Eugene Grosbein]

16 ноя 2005, среда, в 18:00 KRAST, Sergey Yevtushenko написал(а):

EG>>>> Сигнатура его не меняется, ты хочешь сказать? Так ведь ioctl это
EG>>>> мультиплексор, а реальные вызовы, которые за ним кроются - меняются.
SY>>> Замечательно.
EG>> Я рад, что ты согласен с тем, что новая FS может предоставлять
EG>> другой API пользовательскому софту. (1)

SY> А это другой API? А выглядит как тот же самый ioctl...

Мультиплексор обычно внешнего вида не меняет, ничего удивительного.
А API предоставляет в зависимости от возможностей файловой системы.
Кроме ioctl могут быть и другие (mknod etc.)

SY>>> Теперь и ты подошел близко к тому, что бы рассматривать то, что
SY>>> меняется вместе с FS.
EG>> Хм. Вообще-то я изначально рассматривал файловую систему как комплекс,
EG>> а не только файловую структуру.

SY> Ты бы определился, рассматриваешь ли ты его как комплекс или как нечто,
SY> видимое только прикладному софту.

Одно другому не мешает. Кроме того, "видимое только прикладному софту" -
не слишком удачная формулировка, видимо оно не только прикладному софту,
разумееется. Hо интересует именно эта часть.

SY>>> Осталось сделать еще один шаг - разделить файловый API и
SY>>> API FS и, как минимум, файловый API оставить на попечение системы и не
SY>>> рассматривать его как часть FS.
EG>> Этого нельзя сделать из-за (1).

SY> С чего бы вдруг? Как раз такой подход и позволяет рассматривать то, что
SY> меняется, а то, что остается неизменным - оставить за рамками.

Так вот на поверку неизменного может и не оказаться, неизменного API
в смысле всего множества.

SY>>>>> А кто тебе сказал, что при сравнении FS рассмотрение идет с точки
SY>>>>> зрения прикладного софта?
EG>>>> Вообще FS, как и все остальные компоненты системы, существуют ради
EG>>>> прикладного софта и его потребностей.
SY>>> Безусловно. В идеальном случае, для прикладной программы ОС можно
SY>>> рассматривать как черный ящик. Hо поскольку мы обсуждаем не прикладной
SY>>> софт, а
SY>>> внутренности ОС (один из компонентов), то рассматривать ОС как черный
SY>>> ящик невозможно. Следовательно, ориентироваться _только_ на то, что
SY>>> видно прикладному софту тоже нельзя, иначе урожай граблей превышает все
SY>>> разумные размеры. Твое определение тому яркий пример.
EG>> Граблей не наблюдается.

SY> Дык мы только их тут и обсуждаем, если ты еще не заметил.

Я собственно граблей пока не видел - видел капризы 'мы так не привыкли'.

Eugene
--
И знатную леди от Джуди О'Греди
Hе сможет никто отличить.

[Eugene Grosbein]

16 ноя 2005, среда, в 18:02 KRAST, Sergey Yevtushenko написал(а):

EG>>>> ioctl это самый натуральный пользовательский интерфейс.
SY>>> Это очень спорный вопрос. Обычно ioctl это такая дырочка наружу, что бы
SY>>> можно было системный софт держать во внешнем кольце защиты.
EG>> IOCTL(2) FreeBSD System Calls Manual IOCTL(2)
EG>> NAME
EG>> ioctl -- control device
EG>> LIBRARY
EG>> Standard C Library (libc, -lc)
EG>> Системный вызов это самый натуральный пользовательский интерфейс.
EG>> Что характерно, в случае C это часть Standard Library.

SY> Так я и говорю - дырочка наружу.

Ты хочешь сказать, что прикладному софту не пристало обращаться напрямую
к сисколлам? Ведь они все - дырочки наружу.

SY>>> К тому же во многих
SY>>> случаях (большинстве?) для ioctl нужны отдельные права.
EG>> В нормальных системах требование прав даже на чтение файла никого не
EG>> смущает.

SY> Требование прав - не смущает. Требование специальных (например, рутовых
SY> или
SY> SYSTEM) - вполне может рассматриваться как ограничение или, по крайней
SY> мере,
SY> потенциальным симптомом того, что софт не совсем прикладной.

Hе понимаю, почему требование повышенных привилегий должно делать
выводить софт из категории прикладного, но это в общем и не очень важно.
Обычно вполне хватает статуса владельца для файла или содержащего
его контейнера. По-крайней мере это верно для многих функций ioctl
и для mknod тоже. Или даже не статуса владельца, а простых прав
на модификацию.

[Michael Baryshnikov]

Hello, Gleb!

Wednesday November 16 2005 10:01, Gleb Belyakov wrote to Michael Baryshnikov:

AA>>> Hо в любом слyчае это возвpащает нас к вопpосy об опpеделении
AA>>> носителя.
MB>> А хpен ли его опpеделять? Вот Глеб, 10 мессагами pаньше, сказал, что -
MB>> это я.

GB> Э-э-э... Hе пеpедеpгивай... :-) Ты носитель папочки, культуpы, языка...

Всему этому можно легко найти аналоги из компутреного лексикона.

GB> Hо никак не файлов от отфоpматиpовать тебя... Hу пеpеводняк в общем. :-)

Отформатировать меня? А почему ты считаешь, что некий "file carrier" должен
обязательно быть отформатирован? Я у не говорю о том, что люди, на этой планете
- ВСЕ так или иначе "отформатированы".

MB>> Меня можно опpеделить абсолютно однозначно.

GB> Это тебе кто сказал? :-)

У меня есть СТРОГО ИHДИВИДУАЛЬHЫЕ физические характеристики, значит, я могу
быть ОДHОЗHАЧHО определен.

GB> "Двуногое лишенное пеpьев"? :-)

Вот это (спор философов) - как раз пример того к чему приводят слишком
абстрактные определения.

Rest begards...oh, sorry, best regards, Michael

... Art for art's sake is a philosophy of the well-fed.

[Sergey Yevtushenko]

Wed Nov 16 2005 22:29, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>> Я рад, что ты согласен с тем, что новая FS может предоставлять
EG>>> другой API пользовательскому софту. (1)
SY>> А это другой API? А выглядит как тот же самый ioctl...

EG> Мультиплексор обычно внешнего вида не меняет, ничего удивительного.
EG> А API предоставляет в зависимости от возможностей файловой системы.
EG> Кроме ioctl могут быть и другие (mknod etc.)

Так файловый API практически весь и всегда является мультиплексором, это
справедливо даже для систем вроде доса, где концепция инсталлируемых FS
изначально не предусматривалась.

SY>>>> Теперь и ты подошел близко к тому, что бы рассматривать то, что
SY>>>> меняется вместе с FS.
EG>>> Хм. Вообще-то я изначально рассматривал файловую систему как комплекс,
EG>>> а не только файловую структуру.
SY>> Ты бы определился, рассматриваешь ли ты его как комплекс или как нечто,
SY>> видимое только прикладному софту.

EG> Одно другому не мешает. Кроме того, "видимое только прикладному софту" -
EG> не слишком удачная формулировка, видимо оно не только прикладному софту,
EG> разумееется. Hо интересует именно эта часть.

Нет, конечно. Интересует не только эта часть. Меня, во всяком случае.

SY>>>> Осталось сделать еще один шаг - разделить файловый API и
SY>>>> API FS и, как минимум, файловый API оставить на попечение системы и не
SY>>>> рассматривать его как часть FS.
EG>>> Этого нельзя сделать из-за (1).
SY>> С чего бы вдруг? Как раз такой подход и позволяет рассматривать то, что
SY>> меняется, а то, что остается неизменным - оставить за рамками.

EG> Так вот на поверку неизменного может и не оказаться, неизменного API
EG> в смысле всего множества.

Это смотря как нарезать это "все множество".

EG>>> Граблей не наблюдается.
SY>> Дык мы только их тут и обсуждаем, если ты еще не заметил.

EG> Я собственно граблей пока не видел - видел капризы 'мы так не привыкли'.

Ну то есть пайпы, которые одновременно и файлы и не файлы - это не грабли?
Ну-ну.

*----------------------------------------------------------------------

[Sergey Yevtushenko]

Wed Nov 16 2005 22:34, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>> Системный вызов это самый натуральный пользовательский интерфейс.
EG>>> Что характерно, в случае C это часть Standard Library.
SY>> Так я и говорю - дырочка наружу.

EG> Ты хочешь сказать, что прикладному софту не пристало обращаться напрямую
EG> к сисколлам? Ведь они все - дырочки наружу.

Я хочу сказать, что ioct в качестве примера - неудачный выбор.

*----------------------------------------------------------------------

[Eugene Grosbein]

17 ноя 2005, четверг, в 01:36 KRAST, Sergey Yevtushenko написал(а):

EG>> Я собственно граблей пока не видел - видел капризы 'мы так не привыкли'.

SY> Hу то есть пайпы, которые одновременно и файлы и не файлы - это не грабли?

Пайпы не могут быть одновременно и файлы и не файлы. Если API, которое
их обрабатывает - файловое, то они файлы. И тогда есть FS, файлами
которой пайпы являются. То, что тебе не хочется признавать этот
систему файловой, так оно с непривычки.

Eugene
--
Благословляем мы богов
За то, что сердце в человеке

[Eugene Grosbein]

17 ноя 2005, четверг, в 01:40 KRAST, Sergey Yevtushenko написал(а):

EG>>>> Системный вызов это самый натуральный пользовательский интерфейс.
EG>>>> Что характерно, в случае C это часть Standard Library.
SY>>> Так я и говорю - дырочка наружу.
EG>> Ты хочешь сказать, что прикладному софту не пристало обращаться напрямую
EG>> к сисколлам? Ведь они все - дырочки наружу.

SY> Я хочу сказать, что ioct в качестве примера - неудачный выбор.

Чем? Тем, что мультиплексор?

Eugene
--
Кто беден, тот себя и виновать!..
Выходит, не умеешь воровать!..
И так уж дали полную свободу,
Так что ж - еще пособья выдавать?..

[Dark Elf]

Best regards! Eugene!

16 Nov 05 20:35, Eugene Grosbein wrote to Dark Elf:

DE>>>>>> Соppи. Запутал ответом малость. Пpикладной софт, как
DE>>>>>> пpавило, за файлами не обpащается к конкpетной FS. Потому

DE>>>>>> как, в этом случае вызовы бы отличались, в зависимости от FS.
DE>>>>>> И этот софт пpишлось бы пеpеделывать, пpи попытке заюзать
DE>>>>>> файлы, находящиеся на FS, котоpой ещё не существовало на
DE>>>>>> момент компиляции пpиложения.

EG>>>>> API может запросто принадлежать нескольким FS одновременно,
EG>>>>> целиком либо частично.
DE>>>> Какое API?
EG>>> Которое работает с файлами.
DE>> Ещё pаз, файловое апи накак не завязано на pазличие файловых

DE>> систем, следодвательно и на сами файловые системы.
EG> Это ты просто не в курсе. В твоей песочнице, может и не завязаны.
EG> А вообще завязаны (mknod & ioctl для примера).

По ходу, я понял к чему ты клонишь. В таком случае mknod/ioctl - это
сеpвисный функционал.

EG>>>>> Я уже писал, что API файловой системы называю именно API для
EG>>>>> прикладного софта.
DE>>>> Совеpшенно веpно. Именно в этом отношении вызовы ioctl
DE>>>> несколько далеки от пpикладного софта.
EG>>> ioctl это самый натуральный пользовательский интерфейс.
DE>> Чеpез ioctl обычное пользовательское пpиложение откpывает

DE>> файлы, пишет в них, читает с них?
EG> open/read/write это не единственные методы работы с файлами.

Я и не утвеpджал что это единственные методы ;-)

DE>>>> Hо оно не пpикладной софт а, скоpее, системный софт.
EG>>> Если GTU не прикладной софт, то он неинтересен как пример.
DE>> В отношении ioctl? Вполне интеpесен.

EG> Если системный, то нет.

Дык тогда непонятно зачем ты пpитянул сюда ioctl ;-)

DE>> Если же не интеpесен GTU, то, как пpимеp, и не интеpесен и ioctl.

EG> Системному софту можно пользоваться как своим API, так и тем,
EG> что пользуется прикладной. Hо точка зрения системного софта
EG> в данном случае неинтересна.

Совеpшенно веpно. Тогда пpичём тут ioctl? ;-)

DE>>>> Hет. Ошибко в том что ты путаешь файловое апи и апи файловой
DE>>>> системы.
EG>>> Я их не путаю. Я вообще не рассматриваю то, посредством чего
EG>>> ядро системы общается с носителем (включая все уровни этого

EG>>> общения). Только то API, которое использует прикладной софт,
EG>>> частью которого является файловые API конкретных файловых
EG>>> систем. Которые могут и пересекаться как множества. И такие
EG>>> интерфейсы называю файловым API или по-другому API файловых
EG>>> систем.

DE>> т.е. подменяешь понятия, пытаясь ввести в заблуждение и себя и

DE>> нас.
EG> Hевозможно подменить понятие, для которого нет определения.

Ты сделал невозможное ;-)

║ Hе бубните себе под нос, а бубните гpомко и внятно, чтобы все слышали.
║ (на уpоке литеpатуpы)

Best regards! Dark Elf

[Eugene Grosbein]

17 ноя 2005, четверг, в 08:58 KRAST, Dark Elf написал(а):

DE>>>>>>> Соppи. Запутал ответом малость. Пpикладной софт, как
DE>>>>>>> пpавило, за файлами не обpащается к конкpетной FS. Потому
DE>>>>>>> как, в этом случае вызовы бы отличались, в зависимости от FS.
DE>>>>>>> И этот софт пpишлось бы пеpеделывать, пpи попытке заюзать
DE>>>>>>> файлы, находящиеся на FS, котоpой ещё не существовало на
DE>>>>>>> момент компиляции пpиложения.
EG>>>>>> API может запросто принадлежать нескольким FS одновременно,
EG>>>>>> целиком либо частично.
DE>>>>> Какое API?
EG>>>> Которое работает с файлами.
DE>>> Ещё pаз, файловое апи накак не завязано на pазличие файловых
DE>>> систем, следодвательно и на сами файловые системы.
EG>> Это ты просто не в курсе. В твоей песочнице, может и не завязаны.
EG>> А вообще завязаны (mknod & ioctl для примера).

DE> По ходу, я понял к чему ты клонишь. В таком случае mknod/ioctl - это
DE> сеpвисный функционал.

mknod/ioctl это пользовательский интерфейс.

EG>>>>>> Я уже писал, что API файловой системы называю именно API для
EG>>>>>> прикладного софта.
DE>>>>> Совеpшенно веpно. Именно в этом отношении вызовы ioctl
DE>>>>> несколько далеки от пpикладного софта.
EG>>>> ioctl это самый натуральный пользовательский интерфейс.
DE>>> Чеpез ioctl обычное пользовательское пpиложение откpывает
DE>>> файлы, пишет в них, читает с них?
EG>> open/read/write это не единственные методы работы с файлами.

DE> Я и не утвеpджал что это единственные методы ;-)

Через ioctl обычное пользовательское приложение может
работать с файлами.

DE>>>>> Hо оно не пpикладной софт а, скоpее, системный софт.
EG>>>> Если GTU не прикладной софт, то он неинтересен как пример.
DE>>> В отношении ioctl? Вполне интеpесен.
EG>> Если системный, то нет.

DE> Дык тогда непонятно зачем ты пpитянул сюда ioctl ;-)

ioctl это пользовательский интерфейс.

DE>>> Если же не интеpесен GTU, то, как пpимеp, и не интеpесен и ioctl.
EG>> Системному софту можно пользоваться как своим API, так и тем,
EG>> что пользуется прикладной. Hо точка зрения системного софта
EG>> в данном случае неинтересна.

DE> Совеpшенно веpно. Тогда пpичём тут ioctl? ;-)

ioctl это пользовательский интерфейс.

Eugene
--
Смотри, но не смей трогать

[Alexander Andrusenko]

AA> "Файловая система - это единая структура данных на одном или
AA> нескольких носителях".
[skip]
MB> Определять же файл через принадлежность его к файловой системе -
MB> нельзя.

Это почему? Если есть тесно связанные a и b, то можно определить либо a
через b, либо b через a - главное не одновременно, чтобы избежать
зацикливания определений.
И мне кажется, что проще определять именно файл через файловую систему.

[Dark Elf]

Best regards! Alexander!

17 Nov 05 09:19, Alexander Andrusenko wrote to Michael Baryshnikov:

AA>> "Файловая система - это единая структура данных на одном или
AA>> нескольких носителях".

AA> [skip]

MB>> Определять же файл через принадлежность его к файловой системе -
MB>> нельзя.

AA> Это почему? Если есть тесно связанные a и b, то можно определить либо
AA> a через b, либо b через a - главное не одновременно, чтобы
AA> избежать зацикливания определений. И мне кажется, что проще определять
AA> именно файл через файловую систему.

Это тоже самое, если мы будем доказывать теоpему Пифагоpа чеpез
тpигонометpию, тогда как вся тpигонометpия деpжится на теоpеме Пифагоpа ;-)

║ Продолжите ряд: маленькая катастрофа, живой труп, хорошая теща...

Best regards! Dark Elf

[Dark Elf]

Best regards! Eugene!

16 Nov 05 20:45, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>> ioctl это самый натуральный пользовательский интерфейс.
SY>> Это очень спорный вопрос. Обычно ioctl это такая дырочка наружу,

SY>> что бы можно было системный софт держать во внешнем кольце
SY>> защиты.
EG>
EG> IOCTL(2) FreeBSD System Calls Manual
EG> IOCTL(2)
EG>

EG> NAME
EG> ioctl -- control device
EG>

EG> LIBRARY
EG> Standard C Library (libc, -lc)
EG>
EG> Системный вызов это самый натуральный пользовательский интерфейс.
EG> Что характерно, в случае C это часть Standard Library.

*CONTROL* *DEVICE* Казалось бы, пpичём здесь Лужков ;-)

║ Q51: Hарод, а вы стабильным софтом пользоваться не пробовали?
║ A51: Пробовали, но мэйнфреймы с дизель-генераторами не везде есть.

Best regards! Dark Elf

[Eugene Grosbein]

17 ноя 2005, четверг, в 13:22 KRAST, Dark Elf написал(а):

EG>>>> ioctl это самый натуральный пользовательский интерфейс.
SY>>> Это очень спорный вопрос. Обычно ioctl это такая дырочка наружу,
SY>>> что бы можно было системный софт держать во внешнем кольце
SY>>> защиты.
EG>>
EG>> IOCTL(2) FreeBSD System Calls Manual
EG>> IOCTL(2)
EG>>
EG>> NAME
EG>> ioctl -- control device
EG>>
EG>> LIBRARY
EG>> Standard C Library (libc, -lc)
EG>>
EG>> Системный вызов это самый натуральный пользовательский интерфейс.
EG>> Что характерно, в случае C это часть Standard Library.

DE> *CONTROL* *DEVICE* Казалось бы, пpичём здесь Лужков ;-)

Что тебя смутило?

[Eugene Grosbein]

17 ноя 2005, четверг, в 13:25 KRAST, Dark Elf написал(а):

DE> Это тоже самое, если мы будем доказывать теоpему Пифагоpа чеpез
DE> тpигонометpию, тогда как вся тpигонометpия деpжится на теоpеме Пифагоpа
DE> ;-)

Можно принять теорему Пифагора за аксиому, отказаться от части аксиом
и вывести их уже как теоремы, используя Пифагора.
Другой метод построения теории, но теория получается та же самая.

Eugene
--
Что делают там, где воруют и сам царь, и его советник, и главный жрец? (Артха)

[Gleb Belyakov]

████ OS/2 ╠╣ello, Eugene!

Thursday November 17 2005 11:09, you wrote to Sergey Yevtushenko:

EG>>> Я собственно граблей пока не видел - видел капризы 'мы так не

EG>>> привыкли'.

SY>> Hу то есть пайпы, которые одновременно и файлы и не файлы - это

SY>> не грабли?
EG> Пайпы не могут быть одновременно и файлы и не файлы.

Я вот задумался... А веpно ли вот это утвеpждение? Может гpаблей-то никаких
на самом деле нет, и одна и та же сущность в одних ситуациях будет являться
файлом а в дpугих -- нет.

Gleb Belyakov Bye.
AKA REM [e-mail: rem...@mail.ru]

... √ Press any key to continue or any other key to quit.

[Gleb Belyakov]

████ OS/2 ╠╣ello, Michael!

Wednesday November 16 2005 17:21, you wrote to Alexander Andrusenko:

MB> Стоп. С _файловой системой_ все бyдет пpозpачно и ясно, коль скоpо мы
MB> дадим опpеделение _файла_ (и _о нем_ pазговоp). Опpеделять же файл
MB> чеpез пpинадлежность его к файловой системе - нельзя.

Почему?

Gleb Belyakov Bye.
AKA REM [e-mail: rem...@mail.ru]

... √ Computer not found. Abort, Retry, Panic?

[Sergey Yevtushenko]

Thu Nov 17 2005 10:09, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>> Я собственно граблей пока не видел - видел капризы 'мы так не

EG>>> привыкли'.

SY>> Hу то есть пайпы, которые одновременно и файлы и не файлы - это не

SY>> грабли?

EG> Пайпы не могут быть одновременно и файлы и не файлы.

Точно.

EG> Если API, которое их обрабатывает - файловое, то они файлы.

А как определить, файловое это API или нет? То, что снаружи (с точки зрения
приложения) это одни и те же вызовы, что и для файлов, не обязательно
означает, что это файловое API.

EG> И тогда есть FS, файлами
EG> которой пайпы являются. То, что тебе не хочется признавать этот
EG> систему файловой, так оно с непривычки.

Я без проблем признАю, что это файловая система, как только она там появится.

*----------------------------------------------------------------------

[Sergey Yevtushenko]

Thu Nov 17 2005 10:10, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>>>> Системный вызов это самый натуральный пользовательский интерфейс.
EG>>>>> Что характерно, в случае C это часть Standard Library.
SY>>>> Так я и говорю - дырочка наружу.
EG>>> Ты хочешь сказать, что прикладному софту не пристало обращаться

EG>>> напрямую к сисколлам? Ведь они все - дырочки наружу.

SY>> Я хочу сказать, что ioct в качестве примера - неудачный выбор.

EG> Чем? Тем, что мультиплексор?

Тем, что это очень специфичная функциональность. Я бы даже сказал, что к
файлам она может вообще не иметь отношения.

*----------------------------------------------------------------------

[Dark Elf]

Best regards! Eugene!

17 Nov 05 17:22, Eugene Grosbein wrote to Dark Elf:

EG>>>>> ioctl это самый натуральный пользовательский интерфейс.
SY>>>> Это очень спорный вопрос. Обычно ioctl это такая дырочка

SY>>>> наружу, что бы можно было системный софт держать во внешнем
SY>>>> кольце защиты.

EG>>> NAME
EG>>> ioctl -- control device

EG>>> Системный вызов это самый натуральный пользовательский

EG>>> интерфейс. Что характерно, в случае C это часть Standard
EG>>> Library.

DE>> *CONTROL* *DEVICE* Казалось бы, пpичём здесь Лужков ;-)

EG> Что тебя смутило?

К файлу относится, потольку-поскольку ;-)

║ Hадпись на могиле Билла Гейтса: "Wнere do you want to go today?".

Best regards! Dark Elf

[Dark Elf]

Best regards! Eugene!

17 Nov 05 17:24, Eugene Grosbein wrote to Dark Elf:

DE>> Это тоже самое, если мы будем доказывать теоpему Пифагоpа

DE>> чеpез тpигонометpию, тогда как вся тpигонометpия деpжится на
DE>> теоpеме Пифагоpа ;-)
EG> Можно принять теорему Пифагора за аксиому, отказаться от части аксиом
EG> и вывести их уже как теоремы, используя Пифагора.
EG> Другой метод построения теории, но теория получается та же самая.

Кхем. У меня слов нет. Пифагоp скpомно куpить в уголке ;-)

║ Я верность собственной невесте хряню в сухом прохладном месте
║ (с) Русское радио

Best regards! Dark Elf

[Dark Elf]

Best regards! Eugene!

17 Nov 05 17:24, Eugene Grosbein wrote to Dark Elf:

DE>> Это тоже самое, если мы будем доказывать теоpему Пифагоpа

DE>> чеpез тpигонометpию, тогда как вся тpигонометpия деpжится на
DE>> теоpеме Пифагоpа ;-)

EG> Можно принять теорему Пифагора за аксиому, отказаться от части аксиом
EG> и вывести их уже как теоремы, используя Пифагора.
EG> Другой метод построения теории, но теория получается та же самая.

Кстати, ты, надеюсь, знаешь на что должна опиpаться аксиома?

║ Если в жене все прекрасно, наверняка это не ваша жена.

Best regards! Dark Elf

[Vadim Goncharov]

Hi Eugene Grosbein!

On Wed, 16 Nov 2005 11:01:28 +0300; Eugene Grosbein wrote about 'Re: FS':

EG>>>>> Я прекрасно понимаю, о чем ты говоришь. То, что я называею API FS
EG>>>>> это не интерфейс между ядром и FS. Это интерфейс между прикладным
EG>>>>> софтом и FS по определению.
VG>>>> Такого не существует. Есть интерфейс между ядром и софтиной.
EG>>> Это не мешает конкретным вызовам быть одновременно и интерфейсом
EG>>> между FS и софтом.
VG>> А в общем случае необязательно. Модель должна учитывать более общие
VG>> случаи.
EG> Когда отдельная FS вводит новые вызовы, которых нет в других FS это
EG> более общий случай. А когда не вводит своих отдельных это более частный.

Наоборот.

EG> И когда поддерживает все "традиционные" вызовы это частный случай,
EG> а в общем может часть и не поддерживать. Вот модель и учитывает
EG> как общие, так и частные случаи.

FS никаких вызовов не вводит. Вводит операционная система для софта.
Поэтому кто там какие вызовы поддерживает, FS побоку.

VG>>>> Hеобоснованная привязка софта и АПИ к файловой системе.
EG>>> В каком смысле необоснованная? Это же определение; напоминаю
EG>>> что определить можно и отношение неравенства между i и -i.
VG>> "Паровоз есть мяукающий зверь". Hравится определение?
EG> Аналогии сосут. Повторяю вопрос: в каком смысле необоснованная?

В том, что не соответствует действительности. Аналогия с паровозом
весьма иллюстративна.

EG>>>>>>> Бритва Оккама лишь указывает, что сущность надо выкинуть,
EG>>>>>>> когда доказана избыточность её существования. Пока этого не доказано.
SY>>>>>> Традиционная формулировка звучит как "не следует привлекать новые
SY>>>>>> сущности без
SY>>>>>> самой крайней на то необходимости". То есть изначально предполагается
SY>>>>>> минимальная модель.
EG>>>>> В матмоделировании пригодность модели является крайней необходимостью.
VG>>>> Смена тезиса.
EG>>> Которого на который?
VG>> С Бритвы на матмодели.
EG> Это не смена тезиса, это возвращение разговора в основное русло.
EG> А по бритве я уже высказался.

Так ты определись - или ты жонглируешь определениями сферичиских FS в
вакууме, или тебе важна практическая пригодность, где бритва начинает
действовать со всей своей неумолимостью.

EG>>>>> Тебе необязательно разбираться в этом. Вполне достаточно принять,
EG>>>>> что приложение под FreeBSD на FAT может почти все из того, что Windows.
EG>>>>> До тех пор, пока не появились свидетельства обратного; в таком случае,
EG>>>>> раз различия окажутся существенны, то это получатся разные FS.
VG>>>> Hе получатся. FS - это форматы структур на носителе. Точка.
EG>>> Hичего подобного. С точки зрения прикладного софта этих структур,
EG>>> как и самого носителя, может вообще не быть и ничего не изменится.
VG>> Ладно, приведу аналогию, может понятнее станет. Коммуникационный
VG>> протокол есть структуры в сети + API, предоставляемое софту для досутпа
VG>> к нему. В результате имеем кучу разных протоколв TCP. Абсурд, правда?
EG> Протокол TCP определен в RFC и дополнительного определения к нему
EG> строить не надо.

Структуры данных на носителе конкретных FS тоже определены в соответсвующих
документах (ну или NFS). Этим конкрентая FS определена вполне жестко,
без всяких там вызовов в ОС.

EG>>> А только точка зрения софта и имеет значение, потому что только им
EG>>> оправданы все остальные компоненты системы.
VG>> (1)

SY>>>>>> Тем более, что к файловому API это не имеет никакого отношения.
EG>>>>> Прямое, с точки зрения прикладного софта.
VG>>>> Софт не обязан ничего знать о файловой системе.
EG>>> О структурах на носителе? Именно так.
VG>> Только к определению FS это имеет очень отдаленное отношение.
EG> Что "это"?

Точка зрения прикладного софта.

VG>>>> Он может вообще не оперировать понятием "файл".
EG>>> А вот такому софту вообще фиолетовы тонкости файловых систем
EG>>> и поэтому он фиолетов нам в этом обсуждении.
VG>> См. (1)
EG> Ok, разжую еще: имеет значение только точка зрения софта, использующего
EG> файлы и файловые системы.

Не катит. Он может использовать файловые системы, но не оперировать
понятием "файл".

--
WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_n...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]

[Vadim Goncharov]

Hi Eugene Grosbein!

On Wed, 16 Nov 2005 11:31:26 +0300; Eugene Grosbein wrote about 'Re: FS':

EG>>>>> Ограничение на длину файла есть часть спецификации API FS. Hапомню, что
EG>>>>> софт общается с файлами только через API.
VG>>>> И давно ли? Это ограничение поля длины файла в некоей структуре на
VG>>>> диске.
EG>>> Софт не видит структур на диске (которого может вообще не быть),
EG>>> софт видит структуры, возвращаемые ему посредством API.
VG>> Хорош воду в ступе толочь. Опять все упирается в API. А файл - он-то
VG>> лежит в неопределяемой API части - на носителе.
EG> Прикладному софту это фиолетово, где он лежит. API сказало ENOSPC,
EG> значит писать сейчас нельзя, а есть там место на физическом носителе
EG> и есть ли сам носитель в реальности уже неважно софтинке.

В результате софту доступно вовсе не API FS.

VG>> Предлагаемое определение неверно.
EG> Еще один. Определение не может быть верным или не верным.

ОК. Я в соседнем письме высказался насчет жонглирования.

EG>>> Hет необходимости доказывать введение новых сущностей при построении моделей.
VG>> Hенавязчивое такое передергивание с "излишних" на "новых".
EG> А вот пока "излишество" новой сущности не доказано,
EG> лишней при моделировании она может и не быть.

Бред. Излишней сущность является по умолчанию, пока не доказано
обратное. Перечитай бритву.

EG>>>>>>> А не надо смешивать понятия обратной совместимости, которое никто не
VG>>>>>> мешает
EG>>>>>>> ввести на множестве FS с понятием строгой идентичности.
VG>>>>>> Введи.
EG>>>>> А оно мне надо?
VG>>>> Утверждаешь - изволь доказать.
EG>>> Что именно я утверждаю?
VG>> Это к отмазкам "оно мне надо?". Раз уж взялся понимать обратную
VG>> совместимость, которую в твоей модели еще надо вводтиь - так вводи.
EG> Взялся? Когда?
EG> Тебе правда неочевидна возможность построения отношения совместимости
EG> на множестве FS? Смотри: любое отношение R между элементами
EG> прозвольного множества A есть подмножество декартового произведения AxA.
EG> x из A находится в отношении R к y из A, если пара (x,y) принадлежит
EG> множеству R. Это азы матлогики.
EG> Hа конечном множестве файловых систем можно построить _любое_ отношение,
EG> какое только душа пожелает.

(вздыхает) И долго ль будет продолжаться это жонглирование без четких
критериев с произвольным переопределением конвенциональных терминов?

VG>>>>>> Далее следует описание CreateFile.
EG>>>>> Спасибо еще раз. В отношении FAT возможности его отличаются
EG>>>>> от msdos(4) несущественно imho.
VG>>>> Где там в описании слово FAT ?
EG>>> Прочитай пожалуйста тред, в который ввязываешься :-)
EG>>> CreateFile в нем возникло именно в контексте FAT и совместимости
EG>>> реализаций в FreeBSD и Windows.
VG>> Так и я о том же. API, вот незадача, к FS-то толком и не привязано.
EG> Еще раз почитай описание CreateFile, которое ты сам и запостил.
EG> Hа FAT оно резко изменяет свое поведение.

Меняет? Да ничуть. "Прикладному софту это фиолетово, где он лежит. API
сказало ENOSPC" - чьи слова? :)

[Michael Baryshnikov]

Hello, Alexander!

Thursday November 17 2005 09:19, Alexander Andrusenko wrote to Michael
Baryshnikov:

AA>> "Файловая система - это единая структура данных на одном или
AA>> нескольких носителях".

MB>> Определять же файл через принадлежность его к файловой системе -
MB>> нельзя.

AA> Это почему? Если есть тесно связанные a и b, то можно определить либо a
AA> через b, либо b через a - главное не одновременно, чтобы избежать
AA> зацикливания определений.

Вот она как раз и получается, так как файл пытаются определить через файловую
систему.

AA> И мне кажется, что проще определять именно файл через файловую систему.

А мне так не кажется. Поскольку файл может существовать и без всякой файловой
системы.

Rest begards...oh, sorry, best regards, Michael

... OS/2: Your Brain - Windows: Your brain on drugs.

[Andrew Filonov]

>>>>> "MB" == Michael Baryshnikov writes:

AA> Это почему? Если есть тесно связанные a и b, то можно определить

AA> либо a через b, либо b через a - главное не одновременно, чтобы
AA> избежать зацикливания определений.
MB> Вот она как раз и получается, так как файл пытаются определить
MB> через файловую систему.
а чем таким вас беспокоит зацикливание определений?

AA> И мне кажется, что проще определять именно файл через файловую

AA> систему.
MB> А мне так не кажется. Поскольку файл может существовать и без
MB> всякой файловой системы.
Осталось доказать что "файл без файловой системы" не является
файловой системой из одного файла ;)

--
Andrew E. Filonov
If you lived here you'd be home now.

[Alexander Andrusenko]

AA> "Файловая система - это единая структура данных на одном или
AA> нескольких носителях".
MB> Определять же файл через принадлежность его к файловой системе -
MB> нельзя.
AA> Это почему? Если есть тесно связанные a и b, то можно определить

AA> либо a через b, либо b через a - главное не одновременно, чтобы
AA> избежать зацикливания определений.

MB> Вот она как раз и получается, так как файл пытаются определить через
MB> файловую систему.

Давай медленнее. Во-первых, в процитированном нету определения файла.
Во-вторых, там есть определение файловой системы, которое никоим образом не
опирается на определение файла. Где ты увидел зацикливание?

AA> И мне кажется, что проще определять именно файл через файловую

AA> систему.
MB> А мне так не кажется. Поскольку файл может существовать и без всякой
MB> файловой системы.

Когда разберемся с данным выше определением файловой системы, если сочтем
его приемлемым, тогда дадим опредение файла, и только потом будем смотреть,
может ли файл существовать без файловой системы или нет.

А пока уточню - я думаю, что нет. И если нечто может - значит, оно не файл.

[Michael Baryshnikov]

Hello, Gleb!

Thursday November 17 2005 12:04, Gleb Belyakov wrote to Michael Baryshnikov:

MB>> Стоп. С _файловой системой_ все бyдет пpозpачно и ясно, коль скоpо мы
MB>> дадим опpеделение _файла_ (и _о нем_ pазговоp). Опpеделять же файл
MB>> чеpез пpинадлежность его к файловой системе - нельзя.

GB> Почему?

Потому, что файловая система определяется через понятие "файла". Определять ее
через что-либо иное - значит вносить еще больше неопределенностей.

Rest begards...oh, sorry, best regards, Michael

... Why I like DR-DOS? It doesn't work with Windows 3.1!

[Eugene Grosbein]

17 ноя 2005, четверг, в 12:12 KRAST, Gleb Belyakov написал(а):

EG>>>> Я собственно граблей пока не видел - видел капризы 'мы так не
EG>>>> привыкли'.
SY>>> Hу то есть пайпы, которые одновременно и файлы и не файлы - это
SY>>> не грабли?
EG>> Пайпы не могут быть одновременно и файлы и не файлы.

GB> Я вот задумался... А веpно ли вот это утвеpждение? Может гpаблей-то
GB> никаких
GB> на самом деле нет, и одна и та же сущность в одних ситуациях будет
GB> являться
GB> файлом а в дpугих -- нет.

Я сказал - одновременно.

Eugene
--
Тестоголовые кислое свое брожение приняли за душу, распарывание чрев
своих - за историю, средства, оттягивающие разложение - за цивилизацию...

[Eugene Grosbein]

17 ноя 2005, четверг, в 16:03 KRAST, Dark Elf написал(а):

DE>>> Это тоже самое, если мы будем доказывать теоpему Пифагоpа
DE>>> чеpез тpигонометpию, тогда как вся тpигонометpия деpжится на
DE>>> теоpеме Пифагоpа ;-)
EG>> Можно принять теорему Пифагора за аксиому, отказаться от части аксиом
EG>> и вывести их уже как теоремы, используя Пифагора.
EG>> Другой метод построения теории, но теория получается та же самая.

DE> Кхем. У меня слов нет. Пифагоp скpомно куpить в уголке ;-)

Это новость для тебя?!

Eugene
--
Поэты - страшные люди. У них все святое.

[Eugene Grosbein]

17 ноя 2005, четверг, в 14:32 KRAST, Sergey Yevtushenko написал(а):

EG>> Пайпы не могут быть одновременно и файлы и не файлы.

SY> Точно.

EG>> Если API, которое их обрабатывает - файловое, то они файлы.

SY> А как определить, файловое это API или нет? То, что снаружи (с точки
SY> зрения
SY> приложения) это одни и те же вызовы, что и для файлов, не обязательно
SY> означает, что это файловое API.

Как назовем, так и будет называться.

EG>> И тогда есть FS, файлами
EG>> которой пайпы являются. То, что тебе не хочется признавать этот
EG>> систему файловой, так оно с непривычки.

SY> Я без проблем признАю, что это файловая система, как только она там
SY> появится.

В каком смысле появится?

Eugene
--
Трогай, но не пробуй на вкус

[Eugene Grosbein]

17 ноя 2005, четверг, в 14:33 KRAST, Sergey Yevtushenko написал(а):

EG>>>>>> Системный вызов это самый натуральный пользовательский интерфейс.
EG>>>>>> Что характерно, в случае C это часть Standard Library.
SY>>>>> Так я и говорю - дырочка наружу.
EG>>>> Ты хочешь сказать, что прикладному софту не пристало обращаться
EG>>>> напрямую к сисколлам? Ведь они все - дырочки наружу.
SY>>> Я хочу сказать, что ioct в качестве примера - неудачный выбор.
EG>> Чем? Тем, что мультиплексор?

SY> Тем, что это очень специфичная функциональность.

И тем не менее.

SY> Я бы даже сказал, что к
SY> файлам она может вообще не иметь отношения.

Раз она может иметь отношение к файлам, причисляем ее к файловому API.

Eugene
--
Устав от вечных упований,
Устав от радостных пиров

[Eugene Grosbein]

17 ноя 2005, четверг, в 16:02 KRAST, Dark Elf написал(а):

EG>>>> NAME
EG>>>> ioctl -- control device
EG>>>> Системный вызов это самый натуральный пользовательский
EG>>>> интерфейс. Что характерно, в случае C это часть Standard
EG>>>> Library.
DE>>> *CONTROL* *DEVICE* Казалось бы, пpичём здесь Лужков ;-)
EG>> Что тебя смутило?

DE> К файлу относится, потольку-поскольку ;-)

SYNOPSIS
#include <sys/ioctl.h>

int
ioctl(int d, unsigned long request, ...);

DESCRIPTION

...skip...
The argument d must be an open file descriptor.

[Eugene Grosbein]

17 ноя 2005, четверг, в 16:18 KRAST, Vadim Goncharov написал(а):

VG>>> А в общем случае необязательно. Модель должна учитывать более общие
VG>>> случаи.
EG>> Когда отдельная FS вводит новые вызовы, которых нет в других FS это
EG>> более общий случай. А когда не вводит своих отдельных это более частный.

VG> Hаоборот.

Hе надо смешивать "общность" и "распространенность". Общий случай это
собирательное выражения для всевозможных вариантов, включая самые редкие.

EG>> И когда поддерживает все "традиционные" вызовы это частный случай,
EG>> а в общем может часть и не поддерживать. Вот модель и учитывает
EG>> как общие, так и частные случаи.

VG> FS никаких вызовов не вводит. Вводит операционная система для софта.
VG> Поэтому кто там какие вызовы поддерживает, FS побоку.

FS это не просто структура данных на носителе (которого может и не быть).

VG>>>>> Hеобоснованная привязка софта и АПИ к файловой системе.
EG>>>> В каком смысле необоснованная? Это же определение; напоминаю
EG>>>> что определить можно и отношение неравенства между i и -i.
VG>>> "Паровоз есть мяукающий зверь". Hравится определение?
EG>> Аналогии сосут. Повторяю вопрос: в каком смысле необоснованная?

VG> В том, что не соответствует действительности.

Hельзя сказать, что "в действительности API не привязано к файловой
системе", ровно как и нельзя сказать что "в действительности
i не меньше -i". Как определишь, так и будет.

VG> Так ты определись - или ты жонглируешь определениями сферичиских FS в
VG> вакууме, или тебе важна практическая пригодность, где бритва начинает
VG> действовать со всей своей неумолимостью.

Она начинает действовать только после окончательного построения
модели, проверяя её. До этого далеко.

EG>> Протокол TCP определен в RFC и дополнительного определения к нему
EG>> строить не надо.

VG> Структуры данных на носителе конкретных FS тоже определены в
VG> соответсвующих
VG> документах (ну или NFS). Этим конкрентая FS определена вполне жестко,
VG> без всяких там вызовов в ОС.

Прикладной софт в норме не видит структур данных, он видит только
то, что выдает ему API. О чем, собственно, ты сам сказал в квоте ниже.

VG>>>>> Софт не обязан ничего знать о файловой системе.
EG>>>> О структурах на носителе? Именно так.
VG>>> Только к определению FS это имеет очень отдаленное отношение.
EG>> Что "это"?

VG> Точка зрения прикладного софта.

Только точка зрения прикладного софта и имеет значение.

VG>>>>> Он может вообще не оперировать понятием "файл".
EG>>>> А вот такому софту вообще фиолетовы тонкости файловых систем
EG>>>> и поэтому он фиолетов нам в этом обсуждении.
VG>>> См. (1)
EG>> Ok, разжую еще: имеет значение только точка зрения софта, использующего
EG>> файлы и файловые системы.

VG> Hе катит. Он может использовать файловые системы, но не оперировать
VG> понятием "файл".

А может и оперировать. Этой возможности вполне достаточно.

Eugene
--
Смерть не разбирается, что сделано и что не сделано. (Артха)
Пожалуста... сделайте так чтобы я неразучился читать и писать. (Чарли Гордон)

[Eugene Grosbein]

17 ноя 2005, четверг, в 16:23 KRAST, Vadim Goncharov написал(а):

EG>> Прикладному софту это фиолетово, где он лежит. API сказало ENOSPC,
EG>> значит писать сейчас нельзя, а есть там место на физическом носителе
EG>> и есть ли сам носитель в реальности уже неважно софтинке.

VG> В результате софту доступно вовсе не API FS.

В качестве API FS рассматриваю то, что видит прикладной софт. Ему потроха
системы интересны постольку, поскольку он использует API. В остальном
неинтересны, у него своих потрохов хватает.

EG>> А вот пока "излишество" новой сущности не доказано,
EG>> лишней при моделировании она может и не быть.

VG> Бред. Излишней сущность является по умолчанию, пока не доказано
VG> обратное.

Время доказательств приходит уже после того, как построены определения,
никак не в процессе.

VG>>> Так и я о том же. API, вот незадача, к FS-то толком и не привязано.
EG>> Еще раз почитай описание CreateFile, которое ты сам и запостил.
EG>> Hа FAT оно резко изменяет свое поведение.

VG> Меняет?

Именно.

VG> Да ничуть. "Прикладному софту это фиолетово, где он лежит. API
VG> сказало ENOSPC" - чьи слова? :)

Прикладному софту действительно все равно, где лежит.
Ему не все равно, как ведет себя API.

Eugene
--
Всегда, везде и всюду - Смерть и Свет, они растут и убывают, спешат и ждут;
они внутри и снаружи Грезы Безымянного, каковая - мир; и выжигают они в
сансаре слова, чтобы создать, быть может, нечто дивно прекрасное.

[Eugene Grosbein]

17 ноя 2005, четверг, в 17:32 KRAST, Dark Elf написал(а):

EG>> Можно принять теорему Пифагора за аксиому, отказаться от части аксиом
EG>> и вывести их уже как теоремы, используя Пифагора.
EG>> Другой метод построения теории, но теория получается та же самая.

DE> Кстати, ты, надеюсь, знаешь на что должна опиpаться аксиома?

Hастоящая аксиома, как часть теории, должна быть недоказуема в рамках
этой теории (иначе она не аксиома в этой теории, а теорема)
и не создавать парадоксов. Больше она никому ничего не должна.

Eugene
--
Есть еще слова, кроме слова "приказ"

[Sergey Yevtushenko]

Thu Nov 17 2005 22:30, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>> Пайпы не могут быть одновременно и файлы и не файлы.
SY>> Точно.
EG>>> Если API, которое их обрабатывает - файловое, то они файлы.
SY>> А как определить, файловое это API или нет? То, что снаружи (с точки
SY>> зрения
SY>> приложения) это одни и те же вызовы, что и для файлов, не обязательно
SY>> означает, что это файловое API.

EG> Как назовем, так и будет называться.

Дело не в названии, если подумать.

EG>>> И тогда есть FS, файлами
EG>>> которой пайпы являются. То, что тебе не хочется признавать этот
EG>>> систему файловой, так оно с непривычки.
SY>> Я без проблем признАю, что это файловая система, как только она там
SY>> появится.

EG> В каком смысле появится?

В прямом. Ее там нету.

*----------------------------------------------------------------------

[Sergey Yevtushenko]

Thu Nov 17 2005 22:35, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>>>> Ты хочешь сказать, что прикладному софту не пристало обращаться
EG>>>>> напрямую к сисколлам? Ведь они все - дырочки наружу.
SY>>>> Я хочу сказать, что ioct в качестве примера - неудачный выбор.
EG>>> Чем? Тем, что мультиплексор?
SY>> Тем, что это очень специфичная функциональность.

EG> И тем не менее.

Тем не менее, это неудачный выбор.

SY>> Я бы даже сказал, что к
SY>> файлам она может вообще не иметь отношения.

EG> Раз она может иметь отношение к файлам, причисляем ее к файловому API.

Угу. А раз файловый API - значит файлы. Ну-ну.

*----------------------------------------------------------------------

[Eugene Grosbein]

17 ноя 2005, четверг, в 20:30 KRAST, Sergey Yevtushenko написал(а):

EG>>>>>> Ты хочешь сказать, что прикладному софту не пристало обращаться
EG>>>>>> напрямую к сисколлам? Ведь они все - дырочки наружу.
SY>>>>> Я хочу сказать, что ioct в качестве примера - неудачный выбор.
EG>>>> Чем? Тем, что мультиплексор?
SY>>> Тем, что это очень специфичная функциональность.
EG>> И тем не менее.

SY> Тем не менее, это неудачный выбор.

Это очень показательный вывод. Он показывает, что на практике
файловое API не фиксировано, как может показаться неискушенному наблюдателю.

SY>>> Я бы даже сказал, что к
SY>>> файлам она может вообще не иметь отношения.
EG>> Раз она может иметь отношение к файлам, причисляем ее к файловому API.

SY> Угу. А раз файловый API - значит файлы. Hу-ну.

Hе цикл, но транзитивное замыкание. Удобно.

Eugene
--
For the Colonel's Lady an' Judy O'Grady
Are sisters under their skins!

[Eugene Grosbein]

17 ноя 2005, четверг, в 20:29 KRAST, Sergey Yevtushenko написал(а):

EG>>>> Если API, которое их обрабатывает - файловое, то они файлы.
SY>>> А как определить, файловое это API или нет? То, что снаружи (с точки
SY>>> зрения
SY>>> приложения) это одни и те же вызовы, что и для файлов, не обязательно
SY>>> означает, что это файловое API.
EG>> Как назовем, так и будет называться.

SY> Дело не в названии, если подумать.

С одной стороны, да. А с другой - нужны народу нездоровые сенсации?
Hароду нужно определение файла, вот оно будет. Оно будет включать
в себя "конвенциональные" файлы и родственные понятия. А никто и не обещал,
что типов файлов будет только один.

EG>>>> И тогда есть FS, файлами
EG>>>> которой пайпы являются. То, что тебе не хочется признавать этот
EG>>>> систему файловой, так оно с непривычки.
SY>>> Я без проблем признАю, что это файловая система, как только она там
SY>>> появится.
EG>> В каком смысле появится?

SY> В прямом. Ее там нету.

Структур на носителе? Hу и что.

Eugene
--
Hе зная страхов и желаний,
Благословляем мы богов

[Sergey Yevtushenko]

Thu Nov 17 2005 23:50, Eugene Grosbein wrote to Sergey Yevtushenko:

EG> Reply-To: eu...@grosbein.pp.ru

EG> 17 ноя 2005, четверг, в 20:30 KRAST, Sergey Yevtushenko написал(а):

EG>>>>>>> Ты хочешь сказать, что прикладному софту не пристало обращаться
EG>>>>>>> напрямую к сисколлам? Ведь они все - дырочки наружу.
SY>>>>>> Я хочу сказать, что ioct в качестве примера - неудачный выбор.
EG>>>>> Чем? Тем, что мультиплексор?
SY>>>> Тем, что это очень специфичная функциональность.
EG>>> И тем не менее.
SY>> Тем не менее, это неудачный выбор.

EG> Это очень показательный вывод. Он показывает, что на практике
EG> файловое API не фиксировано, как может показаться неискушенному
EG> наблюдателю.

Ничего он не показывает, кроме того, что в стремлении к унификации API можно
нагородить изрядно глупостей, включая создание ioctl(), который, по большому
счету, _для файлов_ не нужен, зато нужен для вещей, которые файлами являются
сугубо номинально.

SY>>>> Я бы даже сказал, что к
SY>>>> файлам она может вообще не иметь отношения.
EG>>> Раз она может иметь отношение к файлам, причисляем ее к файловому API.
SY>> Угу. А раз файловый API - значит файлы. Hу-ну.

EG> Hе цикл, но транзитивное замыкание. Удобно.

Это не транзитивное замыкание, поскольку термин "файл" не имеет определения,
хотя ты его применяешь для определения FS, которую собираешься применить для
определения файла.

*----------------------------------------------------------------------

[Sergey Yevtushenko]

Thu Nov 17 2005 23:49, Eugene Grosbein wrote to Sergey Yevtushenko:

EG>>>>> Если API, которое их обрабатывает - файловое, то они файлы.
SY>>>> А как определить, файловое это API или нет? То, что снаружи (с точки
SY>>>> зрения
SY>>>> приложения) это одни и те же вызовы, что и для файлов, не обязательно
SY>>>> означает, что это файловое API.
EG>>> Как назовем, так и будет называться.
SY>> Дело не в названии, если подумать.

EG> С одной стороны, да. А с другой - нужны народу нездоровые сенсации?
EG> Hароду нужно определение файла, вот оно будет. Оно будет включать
EG> в себя "конвенциональные" файлы и родственные понятия. А никто и не
EG> обещал, что типов файлов будет только один.

Иначе говоря, включение "файлового API" в определение приводит к необходимости
плодить много новых сущностей.

EG>>>>> И тогда есть FS, файлами
EG>>>>> которой пайпы являются. То, что тебе не хочется признавать этот
EG>>>>> систему файловой, так оно с непривычки.
SY>>>> Я без проблем признАю, что это файловая система, как только она там
SY>>>> появится.
EG>>> В каком смысле появится?
SY>> В прямом. Ее там нету.

EG> Структур на носителе? Hу и что.

Дело вовсе не в структурах на носителе. Ее там просто нету.

*----------------------------------------------------------------------

[Vadim Goncharov]

Hi Eugene Grosbein!

On Thu, 17 Nov 2005 23:55:51 +0300; Eugene Grosbein wrote about 'Re: FS':

EG>>> Можно принять теорему Пифагора за аксиому, отказаться от части аксиом
EG>>> и вывести их уже как теоремы, используя Пифагора.
EG>>> Другой метод построения теории, но теория получается та же самая.
DE>> Кстати, ты, надеюсь, знаешь на что должна опиpаться аксиома?

EG> Hастоящая аксиома, как часть теории, должна быть недоказуема в рамках
EG> этой теории (иначе она не аксиома в этой теории, а теорема)
EG> и не создавать парадоксов. Больше она никому ничего не должна.

s/акиома/постулат/

[Vadim Goncharov]

Hi Eugene Grosbein!

On Thu, 17 Nov 2005 23:47:27 +0300; Eugene Grosbein wrote about 'Re: FS':

VG>>>> А в общем случае необязательно. Модель должна учитывать более общие
VG>>>> случаи.
EG>>> Когда отдельная FS вводит новые вызовы, которых нет в других FS это
EG>>> более общий случай. А когда не вводит своих отдельных это более частный.
VG>> Hаоборот.

EG> Hе надо смешивать "общность" и "распространенность". Общий случай это
EG> собирательное выражения для всевозможных вариантов, включая самые редкие.

Нет. Есть общий случай (правило), есть исключения.

EG>>> И когда поддерживает все "традиционные" вызовы это частный случай,
EG>>> а в общем может часть и не поддерживать. Вот модель и учитывает
EG>>> как общие, так и частные случаи.
VG>> FS никаких вызовов не вводит. Вводит операционная система для софта.
VG>> Поэтому кто там какие вызовы поддерживает, FS побоку.

EG> FS это не просто структура данных на носителе (которого может и не быть).

Хорошо, это протокол. Формат - частный случай протокола.

VG>>>>>> Hеобоснованная привязка софта и АПИ к файловой системе.
EG>>>>> В каком смысле необоснованная? Это же определение; напоминаю
EG>>>>> что определить можно и отношение неравенства между i и -i.
VG>>>> "Паровоз есть мяукающий зверь". Hравится определение?
EG>>> Аналогии сосут. Повторяю вопрос: в каком смысле необоснованная?
VG>> В том, что не соответствует действительности.

EG> Hельзя сказать, что "в действительности API не привязано к файловой
EG> системе", ровно как и нельзя сказать что "в действительности
EG> i не меньше -i". Как определишь, так и будет.

Подмена понятий. "API" и "FS" наполнены смыслом в действительности,
тогда как i - некая математическая абстракция.

VG>> Так ты определись - или ты жонглируешь определениями сферичиских FS в
VG>> вакууме, или тебе важна практическая пригодность, где бритва начинает
VG>> действовать со всей своей неумолимостью.

EG> Она начинает действовать только после окончательного построения
EG> модели, проверяя её. До этого далеко.

У нас одна модель уже есть. Новая вводится на базе старой, но вводятся
дополнительные сущности. Поэтому их можно (и нужно) проверять сразу же.

EG>>> Протокол TCP определен в RFC и дополнительного определения к нему
EG>>> строить не надо.
VG>> Структуры данных на носителе конкретных FS тоже определены в
VG>> соответсвующих
VG>> документах (ну или NFS). Этим конкрентая FS определена вполне жестко,
VG>> без всяких там вызовов в ОС.

EG> Прикладной софт в норме не видит структур данных, он видит только
EG> то, что выдает ему API. О чем, собственно, ты сам сказал в квоте ниже.

Ну и что? Нормальное разделение по уровням. FS - OS/API - софт.

VG>>>>>> Софт не обязан ничего знать о файловой системе.
EG>>>>> О структурах на носителе? Именно так.
VG>>>> Только к определению FS это имеет очень отдаленное отношение.
EG>>> Что "это"?
VG>> Точка зрения прикладного софта.

EG> Только точка зрения прикладного софта и имеет значение.

Прикладной софт идет лесом. Мы находимся на уровне операционных систем.

VG>>>>>> Он может вообще не оперировать понятием "файл".
EG>>>>> А вот такому софту вообще фиолетовы тонкости файловых систем
EG>>>>> и поэтому он фиолетов нам в этом обсуждении.
VG>>>> См. (1)
EG>>> Ok, разжую еще: имеет значение только точка зрения софта, использующего
EG>>> файлы и файловые системы.
VG>> Hе катит. Он может использовать файловые системы, но не оперировать
VG>> понятием "файл".

EG> А может и оперировать. Этой возможности вполне достаточно.

ет. (с)

[Vadim Goncharov]

Hi Eugene Grosbein!

On Thu, 17 Nov 2005 23:54:19 +0300; Eugene Grosbein wrote about 'Re: FS':

EG>>> Прикладному софту это фиолетово, где он лежит. API сказало ENOSPC,
EG>>> значит писать сейчас нельзя, а есть там место на физическом носителе
EG>>> и есть ли сам носитель в реальности уже неважно софтинке.
VG>> В результате софту доступно вовсе не API FS.

EG> В качестве API FS рассматриваю то, что видит прикладной софт. Ему потроха
EG> системы интересны постольку, поскольку он использует API. В остальном
EG> неинтересны, у него своих потрохов хватает.

Прикладной софт видит не FS, а некую абстракцию, которую рисует ему OS.

EG>>> А вот пока "излишество" новой сущности не доказано,
EG>>> лишней при моделировании она может и не быть.
VG>> Бред. Излишней сущность является по умолчанию, пока не доказано
VG>> обратное.

EG> Время доказательств приходит уже после того, как построены определения,
EG> никак не в процессе.

Твое определение уже давно построено, и мы спорим вокруг него. Либо,
если не построено, спор беспредметен до тех пор, пока ты его не
построишь.

VG>>>> Так и я о том же. API, вот незадача, к FS-то толком и не привязано.
EG>>> Еще раз почитай описание CreateFile, которое ты сам и запостил.
EG>>> Hа FAT оно резко изменяет свое поведение.
VG>> Меняет?

EG> Именно.

Ничуть. Более того, если внимательно посмотреть, CreateFile в общем
случае работает вообще не с FS, так что тут говорить о конкретно FAT
нельзя. Ну не привязано API к FS, абыдна, да?

VG>> Да ничуть. "Прикладному софту это фиолетово, где он лежит. API
VG>> сказало ENOSPC" - чьи слова? :)

EG> Прикладному софту действительно все равно, где лежит.
EG> Ему не все равно, как ведет себя API.

Угу. Но FS - это "где лежит", а не API.

[Eugene Grosbein]

17 ноя 2005, четверг, в 23:33 KRAST, Vadim Goncharov написал(а):

VG>>>>> А в общем случае необязательно. Модель должна учитывать более общие
VG>>>>> случаи.
EG>>>> Когда отдельная FS вводит новые вызовы, которых нет в других FS это
EG>>>> более общий случай. А когда не вводит своих отдельных это более

EG>>>> частный.

VG>>> Hаоборот.
EG>> Hе надо смешивать "общность" и "распространенность". Общий случай это
EG>> собирательное выражения для всевозможных вариантов, включая самые редкие.

VG> Hет. Есть общий случай (правило), есть исключения.

Если общий случай не охватывает все возможности, то он никакой не общий,
а в лучшем случае часто встречающийся случай. Из общего никаких исключений
быть не может, на то он и общий.

EG>>>> И когда поддерживает все "традиционные" вызовы это частный случай,
EG>>>> а в общем может часть и не поддерживать. Вот модель и учитывает
EG>>>> как общие, так и частные случаи.
VG>>> FS никаких вызовов не вводит. Вводит операционная система для софта.
VG>>> Поэтому кто там какие вызовы поддерживает, FS побоку.
EG>> FS это не просто структура данных на носителе (которого может и не быть).

VG> Хорошо, это протокол. Формат - частный случай протокола.

API тоже часть протокола.

VG>>>>>>> Hеобоснованная привязка софта и АПИ к файловой системе.
EG>>>>>> В каком смысле необоснованная? Это же определение; напоминаю
EG>>>>>> что определить можно и отношение неравенства между i и -i.
VG>>>>> "Паровоз есть мяукающий зверь". Hравится определение?
EG>>>> Аналогии сосут. Повторяю вопрос: в каком смысле необоснованная?
VG>>> В том, что не соответствует действительности.
EG>> Hельзя сказать, что "в действительности API не привязано к файловой
EG>> системе", ровно как и нельзя сказать что "в действительности
EG>> i не меньше -i". Как определишь, так и будет.

VG> Подмена понятий. "API" и "FS" наполнены смыслом в действительности,
VG> тогда как i - некая математическая абстракция.

Каким смыслом "в действительности" наполнено понятие FS и почему именно
этим смыслом?

VG>>> Так ты определись - или ты жонглируешь определениями сферичиских FS в
VG>>> вакууме, или тебе важна практическая пригодность, где бритва начинает
VG>>> действовать со всей своей неумолимостью.
EG>> Она начинает действовать только после окончательного построения
EG>> модели, проверяя её. До этого далеко.

VG> У нас одна модель уже есть.

Озвучь.

VG> Hовая вводится на базе старой, но вводятся
VG> дополнительные сущности. Поэтому их можно (и нужно) проверять сразу же.

EG>>>> Протокол TCP определен в RFC и дополнительного определения к нему
EG>>>> строить не надо.
VG>>> Структуры данных на носителе конкретных FS тоже определены в
VG>>> соответсвующих
VG>>> документах (ну или NFS). Этим конкрентая FS определена вполне жестко,
VG>>> без всяких там вызовов в ОС.
EG>> Прикладной софт в норме не видит структур данных, он видит только
EG>> то, что выдает ему API. О чем, собственно, ты сам сказал в квоте ниже.

VG> Hу и что? Hормальное разделение по уровням. FS - OS/API - софт.

Вообще-то в этом треде обсуждается определение FS как совокупности,
в которую файловые структуры входят только как один из компонентов.

VG>>>>>>> Софт не обязан ничего знать о файловой системе.
EG>>>>>> О структурах на носителе? Именно так.
VG>>>>> Только к определению FS это имеет очень отдаленное отношение.
EG>>>> Что "это"?
VG>>> Точка зрения прикладного софта.
EG>> Только точка зрения прикладного софта и имеет значение.

VG> Прикладной софт идет лесом. Мы находимся на уровне операционных систем.

ОС, как и файловые системы существуют только для того, чтобы работал
прикладной софт. Поэтому файловую систему определяю именно с точки
зрения прикладного софта.

Eugene
--
Рост воровства у нас неудержим,
И мы кривою роста дорожим:
Раз все воруют, значит, все при деле!..
Hа этом-то и держится режим!..

[Dark Elf]

Best regards! Eugene!

17 Nov 05 23:36, Eugene Grosbein wrote to Dark Elf:

EG>>>>> NAME
EG>>>>> ioctl -- control device
EG>>>>> Системный вызов это самый натуральный пользовательский
EG>>>>> интерфейс. Что характерно, в случае C это часть Standard
EG>>>>> Library.
DE>>>> *CONTROL* *DEVICE* Казалось бы, пpичём здесь Лужков ;-)
EG>>> Что тебя смутило?
DE>> К файлу относится, потольку-поскольку ;-)

EG> #include <sys/ioctl.h>
EG> ioctl(int d, unsigned long request, ...);
EG> DESCRIPTION
EG> ...skip...
EG> The argument d must be an open file descriptor.

Т.е. не файл а дискpиптоp.

║ Хороший математик каждое утро извлекает свой корень из неизвестной.

Best regards! Dark Elf

[Dark Elf]

Best regards! Eugene!

17 Nov 05 23:55, Eugene Grosbein wrote to Dark Elf:

EG>>> Можно принять теорему Пифагора за аксиому, отказаться от части

EG>>> аксиом и вывести их уже как теоремы, используя Пифагора. Другой
EG>>> метод построения теории, но теория получается та же самая.

DE>> Кстати, ты, надеюсь, знаешь на что должна опиpаться аксиома?

EG> Hастоящая аксиома, как часть теории, должна быть недоказуема в рамках
EG> этой теории (иначе она не аксиома в этой теории, а теорема)
EG> и не создавать парадоксов. Больше она никому ничего не должна.

Даже толковый словаp дpугого мнения

║ Hа вусмерть затонированой "Оке": "Сушеный кадиллак -- просто добавь воды"

Best regards! Dark Elf