Názor k článku NFS: vzdálený přístup k souborům v linuxovém operačním systému od R.Y. Pák - Ad: "Kdyz chci soubor smazat, tak chci aby...

Ad: "Kdyz chci soubor smazat, tak chci aby to OS udelal i kdyz nejaky jiny program ho pouziva."

V Linuxu to funguje takhle (https://man7.org/linux/man-pages/man2/unlink.2.html): "If the name was the last link to a file but any processes still have the file open, the file will remain in existence until the last file descriptor referring to it is closed."

Linuxový unlink vyhovuje POSIX.1-2008, takže tohle chování lze očekávat na víceméně všech Unixech.

Ad: "soubor zůstal, ale přejmenoval se na .nfs000XXX dokud onen "jiný program" žil."

Základní idea při návrhu NFS byla, že se se soubory na NFS bude pracovat jako se soubory lokálními. Výše popsané chování se očekává (viz popis ulink). Lze diskutovat, zda to jméno má být jiné atd., ale rozhodně to není chybné chování.

RFC 5661 (NFSv4.1) uvádí:

Open files can be preserved if removed and the hard link count ("hard link" is defined in an Open Group [6] standard) goes to zero, thus obviating the need for clients to rename deleted files to partially hidden names -- colloquially called "silly rename"(see the new OPEN4_RESULT_PRE­SERVE_UNLINKED reply flag in Section 18.16).

OPEN4_RESULT_PRE­SERVE_UNLINKED indicates that the server will preserve the open file if the client (or any other client) removes the file as long as it is open. Furthermore, the server promises to preserve the file through the grace period after server restart, thereby giving the client the opportunity to reclaim its open.

The use of the OPEN4_RESULT_PRE­SERVE_UNLINKED result flag allows a client to avoid the common implementation practice of renaming an open file to ".nfs<unique value>" after it removes the file. After the server returns OPEN4_RESULT_PRE­SERVE_UNLINKED, if a client sends a REMOVE operation that would reduce the file's link count to zero, the server SHOULD report a value of zero for the numlinks attribute on the file.