[00:45:23] --- Russ has left: Disconnected [02:13:36] --- dev-zero@jabber.org has become available [02:13:40] --- dev-zero@jabber.org has left: offline [02:46:38] --- brantgurga has left [03:41:17] --- dev-zero@jabber.org has become available [05:31:18] --- Jeffrey Altman has left: Replaced by new connection [05:37:02] --- brantgurga has become available [05:44:38] --- brantgurga has left [06:11:09] --- Simon Wilkinson has become available [06:37:59] --- Simon Wilkinson has left [06:39:14] --- Jeffrey Altman has become available [07:30:13] --- brantgurga has become available [07:56:56] --- dev-zero@jabber.org has left [08:45:45] --- cclausen has become available [09:05:16] --- dev-zero@jabber.org has become available [09:45:54] --- brantgurga has left [10:24:10] --- Russ has become available [10:49:21] --- brantgurga has become available [11:49:24] --- dev-zero@jabber.org has left [12:22:34] --- dev-zero@jabber.org has become available [12:31:53] --- deason has become available [14:59:58] --- dev-zero@jabber.org has left [19:48:57] perhaps I misunderstand how hardlinks are supposed to work but why do two names that both refer to the same file have different File IDs associated with them? more importantly, how is the client supposed to be able to properly manage dirty buffers and lock allocations if two FIDs refer to the same data stream? [19:51:33] To match normal UNIX semantics, shouldn't they have the same FID, just two directory entries? That's what happens on a traditional UNIX file system. [19:51:54] that is what I would expect but its not what I'm seeing from the Windows client [19:53:38] hmm. I wonder if my home volume in athena.mit.edu was restored from backup at one point and the "hard link" was restored as a separate file [19:53:48] that would explain what I'm seeing [19:53:51] on a random unix client, I see two hard links with the same FID [19:55:00] that is what must have happened. if I recreate the hardlink the FIDs are the same. [19:56:19] --- stevenjenkins has left [19:57:02] > why do two names that both refer to the same file have different File > IDs associated with them? They don't. [19:57:28] Jeff, please read to the end [19:57:58] Of course, you realize that response is useless, because I won't have read it until I get to the end. [19:59:45] --- stevenjenkins has become available [20:00:02] --- cclausen has left [20:01:53] --- cclausen has become available [20:36:14] existing Windows clients have broken behavior regarding hard links. When a hard link is created the status info of the link target is not updated and the linkCount field ends up being incorrect. When a hard link is removed, the linkCount is also ignored and the file will be treated as if the linkCount was zero even though it isn't. This has now been fixed in the respository. [20:46:29] If anyone has CellServDB updates, now is the time to send them. I expect to publish a new one within the next half hour. [20:53:06] would you take linked cells? [20:53:14] or would that cause problems for people? [20:54:17] let me check arla's parser [20:55:43] Not at this time. My current tools have no way to represent or generate them. [20:57:23] --- summatusmentis has become available [21:08:56] just as a technical note. arla will ignore the linkage but will otherwise properly create an entry for the cell. [21:52:25] --- dev-zero@jabber.org has become available [22:19:33] --- deason has left [22:42:55] --- dwbotsch has left [22:43:13] --- dwbotsch has become available [22:47:58] --- dev-zero@jabber.org has left: Replaced by new connection [22:47:59] --- dev-zero@jabber.org has become available [23:25:27] --- dev-zero@jabber.org has left [23:51:48] --- reuteras has become available