爲什麼fnctl在嘗試解鎖文件時從不返回錯誤？

我寫了一個簡單的程序來幫助我測試fcntl文件鎖定。參數'set'鎖定我的測試文件。參數'get'告訴我文件是否被鎖定。參數'un'嘗試解鎖文件。爲什麼fnctl在嘗試解鎖文件時從不返回錯誤？

在一個shell中，我運行程序來鎖定文件。我保持文件打開並等待輸入。

$ ./lock set 
file is locked 
hit enter to release lock with a call to fcntl

在另一個shell中，我運行程序來鎖定文件。它不起作用，因爲該文件已被鎖定。我運行程序檢查鎖。我被告知鎖不可用。所有這些按預期工作。

$ ./lock get 
locking is not possible 
$ ./lock set 
locking file failed

如果我嘗試在shell 2中解鎖我的文件，會發生什麼？看來fcntl在用l_type = F_UNLCK調用時從不會返回錯誤。

$ ./lock un 
unlocked 
file either was successfully unlocked or was already unlocked 
$ ./lock get 
locking is not possible 
$ ./lock set 
locking file failed

我知道我的解鎖代碼是好的。如果我回去殼一個，讓程序解鎖：

$ ./lock get 
locking is possible

我只使用於整個文件的獨佔寫鎖：

$ ./lock set 
file is locked 
hit enter to release lock with a call to fcntl 

unlocked 
hit enter to close the file

我可以確認結果在外殼2

fl.l_type = F_WRLCK; 
    fl.l_whence = SEEK_SET; 
    fl.l_start = 0; 
    fl.l_len = 0; 
    fl.l_pid = -1; // used by F_GETLK only 

    result = fcntl(fd, F_SETLK, &fl);

以下是我正在做的解鎖：

fl.l_type = F_UNLCK; 
    fl.l_whence = SEEK_SET; 
    fl.l_start = 0; 
    fl.l_len = 0; 
    fl.l_pid = -1; // used by F_GETLK only 

    result = fcntl(fd, F_SETLK, &fl); 
    if (!result) 
    { 
    printf("unlocked\n"); 
    }

我正在使用RHEL 5.5。

你能解釋一下這個fcntl行爲嗎？謝謝！

編輯：手冊頁似乎意味着解鎖操作僅供鎖擁有者使用：「除了被明確的F_UNLCK刪除之外，當過程終止時它還會自動釋放記錄鎖，或者如果它關閉任何涉及鎖定文件的文件描述符。「

來源

2011-04-15 Philippe A.

因爲......這是它的工作方式？

在Unix系統上，鎖是建議性的。你試圖獲得一個鎖使用它們，只有在你成功時才做你想做的事。

這包括解鎖該文件。由於整個系統是自願的，所以沒有什麼能夠阻止你從另一個進程中解鎖文件，因此你的程序總是成功的。

來源

2011-04-15 19:57:19

鎖是諮詢意義上的，他們不會阻止你弄亂文件內容。但是你不能偷別的進程的鎖。 shell 2無法解鎖是非常正常的。不正常的是fcntl迴歸成功。 – 2011-04-15 20:04:05

它*不應該*讓你這樣做，正確的，但我不知道是這樣。我個人從來沒有嘗試過你的問題描述（只需在隨機文件中調用解鎖）。如果您打電話解鎖然後嘗試鎖定文件，會發生什麼情況？我試圖做的一點是，你應該在沒有鎖的進程中做的唯一事情就是試圖獲取它。 – 2011-04-15 20:07:30

由於您的評論被接受的答案。 Fcntl解鎖行爲有點奇怪，但是誰在乎實際上呢？ – 2012-02-16 19:46:46

更重要的是，這正是POSIX指定他們所做的。這遠非他們對文件鎖定的唯一的或者甚至是最可疑的決定（後者將是在文件描述符的任何進程在文件close()上打開時，給定文件上的所有鎖定必須被刪除它）。

來源

2011-04-15 19:59:25 geekosaur

它是「在文件上打開文件描述符的任何進程」還是「任何帶有文件描述符的進程都指向相同的打開文件描述」？我很確定這是後者。 – 2011-04-15 20:05:16

@R。從技術上講是後者，但我已經看到了前者 - 可能是對POSIX定義的瘋狂性的評論（我認爲當時的規範足夠寬鬆以允許任何解釋;如果它仍然存在，不知道是否是臨時的）。 – geekosaur 2011-04-15 20:17:29

實際的要求是鎖與一個（file，pid）對（實際的文件，而不是打開的文件描述）相關聯，並且在'close'上，那個（文件，pid）對的所有鎖被刪除。其他打開或關閉文件的進程完全不相關。 – 2011-04-15 21:09:33

爲什麼fnctl在嘗試解鎖文件時從不返回錯誤？

回答

相關問題