FANOTIFY API To Become More Useful With The Linux 5.1 Kernel

[phoronix]

Phoronix: FANOTIFY API To Become More Useful With The Linux 5.1 Kernel

The fanotify API that is used for monitoring/intercepting file-system events is set to tack on a few more features with the upcoming Linux 5.1 kernel cycle...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-Fanotify-Improvements

[cybertraveler]

I was curious about the behaviour of "moving" files on Linux, so I looked up the syscall for doing it. It's "rename()".

Details here:

man 2 rename

The documentation makes sense to me except for this one part of the man page. It says:

If newpath exists but the operation fails for some reason rename() guarantees to leave an instance of newpath in place.

What does that mean?

Does it leave the original file at the location newpath untouched? Does it ensure there is something left at newpath (IE either the file being renamed XOR the original file that was already present at newpath)?

I think the sensible thing for the rename() call to do in the event of a failure, is to:

• ensure that the file referenced by oldpath remains linked at oldpath.
• return an error code
• ideally the error code should be specific to the actual thing that went wrong (IE it's not just a generic IT_BROKE error).

---

I was also surprised to see that the man page did not explain whether the rename operation works across different file systems. Presumably on a single file system, it will do an unlink() and link() operation. When rename()ing a file across 2 different file systems, presumably it will copy the file across link()ing it in the new location and then unlink() it in the old location.

[jpg44]

fanotify/inotify have always been useless with many use cases simply because you have to register each file and directory you want to watch, you cannot register to also watch all subdirectories as well. If you need to monitor tens of thousands of files, this gets ridiculous quickly. A very limited API.

[cl333r]

fanotify/inotify have always been useless with many use cases simply because you have to register each file and directory you want to watch, you cannot register to also watch all subdirectories as well. If you need to monitor tens of thousands of files, this gets ridiculous quickly. A very limited API.

Each directory yes, but not each file, when you listen to a directory you get the events for all its files automatically.

[cl333r]

I was also surprised to see that the man page did not explain whether the rename operation works across different file systems. Presumably on a single file system, it will do an unlink() and link() operation. When rename()ing a file across 2 different file systems, presumably it will copy the file across link()ing it in the new location and then unlink() it in the old location.

It's also interesting that sendfile(2) works across filesystems, but copy_file_range(2) fails.

[Weasel]

fanotify/inotify have always been useless with many use cases simply because you have to register each file and directory you want to watch, you cannot register to also watch all subdirectories as well. If you need to monitor tens of thousands of files, this gets ridiculous quickly. A very limited API.

Amen.

[pal666]

What does that mean?

it means that rename is atomic. it will either do nothing or rename completely

I was also surprised to see that the man page did not explain whether the rename operation works across different file systems.

obviously it doesn't. not even across different mounts of same filesystem

Presumably on a single file system, it will do an unlink() and link() operation.

wrong. that wouldn't be atomic

When rename()ing a file across 2 different file systems, presumably it will copy the file across link()ing it in the new location and then unlink() it in the old location.

rename would just fail. /bin/mv would then do open,open,read,write,unlink,close. but that's not one syscall and i've ignored (extended) attributes

[pal666]

It's also interesting that sendfile(2) works across filesystems, but copy_file_range(2) fails.

maybe this has something to do with senfile being able to work with not filesystems at all. like literally requiring second descriptor to be a socket before 2.6.33? sendfile does copy, copy_file_range does reflink, which requires one filesystem

[nh2_]

I was also surprised to see that the man page did not explain whether the rename operation works across different file systems.

The man page says in the ERRORS section:

       EXDEV  oldpath and newpath are not on the same mounted filesystem.  (Linux permits a filesys‐
              tem to be mounted at multiple points, but rename()  does  not  work  across  different
              mount points, even if the same filesystem is mounted on both.)

You are asking good questions though; reading man pages critically and questioning behaviour is good practice. For example, that way the PostgreSQL fsync() bug could have been avoided.

[cybertraveler]

The man page says in the ERRORS section:

EXDEV oldpath and newpath are not on the same mounted filesystem. (Linux permits a filesys‐
tem to be mounted at multiple points, but rename() does not work across different
mount points, even if the same filesystem is mounted on both.)

You are asking good questions though; reading man pages critically and questioning behaviour is good practice. For example, that way the PostgreSQL fsync() bug could have been avoided.

Ah, nice spot. Thanks.