Dennis Ritchie and Ken Thompson's paper UNIX Time-Sharing System mentions the following points
About i-number: A directory entry contains only a name for the associated file and a pointer to the file itself. This pointer is an integer called the i-number (for index number) of the file
About open and create system-calls: The returned value (of open and create) is called a file descriptor. It is a small integer used to identify the file in subsequent calls
Purpose of open/create: The purpose of an open or create system call is to turn the path name given by the user into an i-number by searching the explicitly or implicitly named directories
Does this mean that the file descriptor is just the i-number of a file? Or am I missing something?
A file descriptor in UNIX is basically just an index into the array of open files for the current process.
An inode number is an index into the inode table for the file system.
So they're basically just integers, indexes into an array, but they are indexes into completely different, unrelated arrays. So there is no connection between them.
To add to Chris Dodd's answer, not only are inode numbers and file descriptor numbers not directly related, it wouldn't be practical for them to be.
Inode numbers are unique to each file system. Imagine if you opened fileA on a file system (say, /mnt) with inode number 100, and in the same process also opened fileB on another filesystem (say, /mnt2) which also happened to have inode number 100. What should the file descriptors be in that case?
Related
In describing how find (& find and replace) work, the Atom Flight Manual refers to the buffer as one scope of search, with the entire project being another scope. What is the buffer? It seems like it would be the current file, but I expect it is more than that.
From the Atom Flight Manual:
A buffer is the text content of a file in Atom. It's basically the same as a file for most descriptions, but it's the version Atom has in memory. For instance, you can change the text of a buffer and it isn't written to its associated file until you save it.
Also came across this from The Craft of Text Editing by Craig Finseth, Chapter 6:
A buffer is the basic unit of text being edited. It can be any size, from zero characters to the largest item that can be manipulated on the computer system. This limit on size is usually set by such factors as address space, amount of real and/or virtual memory, and mass storage capacity. A buffer can exist by itself, or it can be associated with at most one file. When associated with a file, the buffer is a copy of the contents of the file at a specific time. A file, on the other hand, can be associated with any number of buffers, each one being a copy of that file's contents at the same or at different times.
In typical UNIX file systems, data and directory information are
both stored in structures called inodes. Figure 1 shows how a file
in directory/folder A named TheMatrix.jpg is stored starting at
inode 34119, where a set of file information and a list of locations
of its actual data are given. The first block containing actual data
is at inode 213456.
A second file called Link2Matrix.jpg in directory/folder B is linked to
the same file data. Indicate what would be the value of inode X
(shown inside the directory B block at the bottom left) when this
file is; (i) Hard linked to TheMatrix.jpg(ii) Symbolically (or soft linked) to TheMatrix.jpg
Block diagram of inode based file system
I understand that hard linking a file results in inode X taking on the same value as the linked i.e. 34119
However my understanding is that a soft-link will result in a new inode value being generated. However, I do not know how this value is assigned and it appears to be quite arbitrary. Is there a clue in the diagram somewhere that indicates what inode X would be if a soft link was created?
TIA!
Most file systems use locking to handle concurrent read/write. But what if after a read call, a write call is executed which deletes the data preceding the previous read call.
Is the pointer for a file open for reading updated to reflect the new start of the now smaller file?
The question isn't really valid, because you can't delete data using the write system call. You can overwrite data using the write(2) system call, but you can't delete data. Now, you can truncate the file using the truncate(2) system call. This changes the size of the file (reported via the st_size field by the stat(2) system call), and any bytes after the end of the file as reported by changed st_size will be zero. You can increase the size of the file using the truncate system call by requesting a new size which is larger than the current size. It is undefined (per the POSIX specification) whether this is allowed, or what the system will do when it recieves a truncate larger than the current size of the file. On many file systems it will simply set the size of the file to requested size.
OK, a few more concepts. Associated with each open file structure is a file offset pointer. Attempts to read or write a file using the read(2) or write(2) system call will advance the offset pointer by the number of bytes read or written. If you open a file twice using the open(2) system call, you will get two file descriptors, which each refer to a different open file structure, and in that case, a read(2) or write(2) using one file descriptor will not change the file offset for the other file descriptor. (If you clone a file descriptor using the dup(2) system call, then then you will get a second file descriptor which points to the same file structure, and then changes made to the file structure via one file descriptor, using the read(2), write(2), or lseek(2) system calls will be reflected via the cloned file descriptor. But that's a side issue, so that's all I will say on this topic for now.)
Now, if you truncate the file, this doesn't change the file offset in the file descriptor. However, any bytes after the truncated size will be zero if read. So the answer is that file offset pointer won't be updated after the truncate, but an attempt to read beyond the truncated size of the file will return all zeros.
Various manual pages commonly exemplify FIFOs being opened in the /tmp directory, but they do not share a common naming convention. When I list the contents of my /tmp dir' I get nothing but directories named like /tmp/ssh-5oRuBPhI9lv9. Is there a convention, especially/specifically for IPC?
There is no official naming convention.
Sure, when using FIFOs, you will need some convention, since FIFOs are typically used for process communication between unrelated processes. So the name must be known to the different processes, which implies you have to follow some sort of convention, but it's your call.
The reason you see directories and files with mysterious names in /tmp is usually the result of the corresponding processes calling mkstemp(3) or mkdtemp(3). These functions atomically generate a unique name and create the corresponding file / directory.
If for some reason you want your FIFO to have a similar name, you can generate a unique name with tmpnam(3) and then pass that name to mkfifo(3). But note that there is a window of time between the call to tmpnam(3) and the call to mkfifo(3) where another process could create a file with the same name (and then mkfifo(3) would fail). If that's a problem, you could instead atomically create a temporary directory with mkdtemp(3) and then create the FIFO inside that directory with a name of your choice.
The reason there is no sure way to atomically generate and create a temporary, uniquely named FIFO is that FIFOs are used as rendezvous points for unrelated processes, so in general the name must be known a priori. Having a FIFO with a unique temporary name would make it harder for other processes to find it, which kind of defeats the purpose.
I am writing an application which uses the DCM MKDIR, We save our images in little bigger name, but when I am trying to use the DCMMKDIR application, which is asking me to input file name max 8 characters.
Presently, I am planning to rename my Images starting from 1 to N. But remapping these images to known names(on the disk) will be bit difficult(I feel).
are there are any other methods/process to achieve the same.
The restriction of the filename to eight characters is derived from the DICOM Standard to ensure compatibility with applications that support e.g. only ISO 9660 as a file system for CDs.
About the naming you can have a look at the specifications the german CD Testat (http://www.dicom-cd.de/docs/DRG-RequirementsSpecification-2006.pdf). As a vendor you can be certified to conform to certain standards for interoperability of patient CDs which is currently the most common usage of DICOMDIRs.
The DICOMDIR file generated by DCMMKDIR is mainly a kind of index to tell an application, what DICOM files in a certain directory exist and this kind of file structure is usually more common for transfer media.
It is very common to use subdirectories to circumvent the restriction on max 8 length filenames. For example, a file could be 20110331/183421/000001 which would identify it properly with date, time and index without exceeding the somewhat arcane filename limit.