Objective: To monitor file changes within the specified directory of the Linux file system and record or submit them to the appropriate interface.
The specified directory is used to store files submitted by the customer.
The submission may be FTP or mount
Mode one:
Use the inotify mechanism.
The relevant development tools can be inotify-tools or encapsulated on their basis.
Advantages: Easy to open, easy to maintain and stable to operate.
Weakness:
1. It was later learned that for unlink event, information about the deleted file was not available, such as: Want to know if the deleted file is Softlink
2. In the case of mass files or directories, maintaining inode_list requires a large amount of memory space, while at the same time, it is time-consuming to load inode information when the program starts loading.
Mode two:
Use the Fuse--file system user space.
can refer to http://www.ibm.com/developerworks/cn/linux/l-fuse/have a brief introduction
To implement your own file system
To register a custom file action method:
Inotefs_oper.readlink = Inotefs_readlink;
Inotefs_oper.readdir = Inotefs_readdir;
Inotefs_oper.mknod = Inotefs_mknod;
Inotefs_oper.mkdir = Inotefs_mkdir;
Inotefs_oper.symlink = Inotefs_symlink;
Implement the corresponding method, excerpted from one of my implementations:
static int Inotefs_rmdir (const char *path)
{
int res;
Char *apath = getabsolutepath (path);
Path = Getrelativepath (path);
res = rmdir (path);
Inotefs_log (Apath, "rmdir", Res, "rmdir%s", Apath);
return res = =-1? -errno:0;
}
can see that
1, just simple to perform system actions RM
res = rmdir (path);
2, before and after the RM action can be intercepted and processed, the example only after the deletion of the event and log
Inotefs_log (Apath, "rmdir", Res, "rmdir%s", Apath);
The advantages of this approach: flexible, efficient, development is not complex, high degree of freedom, especially to solve the inotify mode of memory footprint and start-up time of the malady.
The application scenarios are diverse, especially in a number of transactions that rely on file systems to make the underlying logic transparent, such as file mirroring/remote synchronization, through a custom file system.
mode three:
Use system tools such as Strace ltrace.
These tools can monitor the process's system call, and so on.
Therefore, if users use FTP upload, you can monitor the FTP server's PID, access to FTP system call
For example unlink ("Xxxxxxxxxxxxxxxxxxx" ...)
From this, you can obtain file change information.
This is not a way to handle the mount write file, but it can be used in some fast development situations, and the cost of stick a PID is fairly low.
mode four:
Cut into the kernel to intercept system call.
The advantage of course is the ultimate performance
However, the development of skills and to ensure the stability of the system is also very high requirements.
Specific development can refer to GitHub of some open source projects.
If you choose this approach, you can use a compromise development approach to avoid intrusion into the kernel code, resulting in an uncontrollable error--
Using the ld_preload parameters of Linux, through the chroot and other means, their own replacement of the underlying modules such as GLIBC read Unlink, and to intercept.