fstat(3) — Linux man page
This manual page is part of the POSIX Programmer’s Manual. The Linux implementation of this interface may differ (consult the corresponding Linux manual page for details of Linux behavior), or the interface may not be implemented on Linux.
Name
Synopsis
int fstat(int fildes, struct stat *buf);
Description
The fstat() function shall obtain information about an open file associated with the file descriptor fildes, and shall write it to the area pointed to by buf.
If fildes references a shared memory object, the implementation shall update in the stat structure pointed to by the buf argument only the st_uid, st_gid, st_size, and st_mode fields, and only the S_IRUSR, S_IWUSR, S_IRGRP, S_IWGRP, S_IROTH, and S_IWOTH file permission bits need be valid. The implementation may update other fields and flags.
If fildes references a typed memory object, the implementation shall update in the stat structure pointed to by the buf argument only the st_uid, st_gid, st_size, and st_mode fields, and only the S_IRUSR, S_IWUSR, S_IRGRP, S_IWGRP, S_IROTH, and S_IWOTH file permission bits need be valid. The implementation may update other fields and flags.
The buf argument is a pointer to a stat structure, as defined in , into which information is placed concerning the file.
The structure members st_mode, st_ino, st_dev, st_uid, st_gid, st_atime, st_ctime, and st_mtime shall have meaningful values for all other file types defined in this volume of IEEE Std 1003.1-2001. The value of the member st_nlink shall be set to the number of links to the file.
An implementation that provides additional or alternative file access control mechanisms may, under implementation-defined conditions, cause fstat() to fail.
The fstat() function shall update any time-related fields as described in the Base Definitions volume of IEEE Std 1003.1-2001, Section 4.7, File Times Update, before writing into the stat structure.
Return Value
Upon successful completion, 0 shall be returned. Otherwise, -1 shall be returned and errno set to indicate the error.
Errors
The fstat() function shall fail if: EBADF The fildes argument is not a valid file descriptor. EIO An I/O error occurred while reading from the file system. EOVERFLOW The file size in bytes or the number of blocks allocated to the file or the file serial number cannot be represented correctly in the structure pointed to by buf.
The fstat() function may fail if: EOVERFLOW One of the values is too large to store into the structure pointed to by the buf argument.
The following sections are informative.
Examples
Obtaining File Status Information
The following example shows how to obtain file status information for a file named /home/cnd/mod1. The structure variable buffer is defined for the stat structure. The /home/cnd/mod1 file is opened with read/write privileges and is passed to the open file descriptor fildes.
#include sys/types.h> #include sys/stat.h> #include fcntl.h> struct stat buffer; int status; . fildes = open("/home/cnd/mod1", O_RDWR); status = fstat(fildes, &buffer); Application Usage
Rationale
Future Directions
See Also
lstat(), stat(), the Base Definitions volume of IEEE Std 1003.1-2001, ,
check if file is open with lsof
I’m using linux mint 13 xfce and I have a file named wv.gold that I’m trying to check in bash if it’s open by any program (for instance, I opened it in sublime-text and gedit ) In many forums people say that if I run lsof | grep filename I should get 0 if it’s open or 256(1) if it’s closed, but in fact I get nothing (empty string) if I run using grep «wv.gold» , and get a little list if I do it using grep gold . The list is something like:
bash 2045 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir bash 2082 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir watch 4463 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir gedit 16679 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir lsof 20823 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir grep 20824 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir lsof 20825 user cwd DIR 8,1 4096 658031 /home/user/path/to/dir Thus, I get the path to the directory it is but NOT the path to the file (there are other files there) and either way only to gedit process, not to sublime-text process. Is there some easy way to see if a txt file is opened by any other program? EDIT: It turns out (cf. comments from @mata and @ctn) that some editors load files and close them immediately, and they just reopen the file when saving it. This way, we can only see it when they are still opening a big file (since you have the time to observe it while opening) and it disappears immediately after that.
How to determine, whether a file is open?
My code needs to go through files in a directory, picking only those, which are currently opened (for writing) by any other process on the system. The ideal solution would apply for all Unixes, but I’ll settle for a Linux-only. The program is written in Python, but I can add a custom C-function, if I have to — I just need to know, what API is available for this. One suggestion I found was to go through all file-descriptors under Linux /proc , resolving their links to see, if they point at the file of interest. But that seems rather heavy. I know, for example, that opening a file increases its reference count — filesystem will not deallocate blocks of an opened file even if it is deleted — until it is closed — the feature relied upon by tmpfile(3) . Perhaps, a user process can get access to these records in the kernel?
Yeah, lsof — and fuser — scan /proc . But that yields more information than I need — I don’t care, which processes have the file open. I just want to know, whether any such exist. Perhaps, this information can be obtained more cheaply, than /proc rescan?
The advantage of scanning /proc is that it is backed by direct kernel calls, not a physical file system. That gives /proc a huge performance advantage over opening and reading a directory, even just to find the names.
The advantage of scanning /proc is that it is the only way to get the information without modifying the kernel.