Question about inode comparaison

1 view
Skip to first unread message

megabast

unread,
May 27, 2009, 1:14:20 PM5/27/09
to google-tsumufs
Hi, I have a new question for you

I hope you will have some time to answer.

In syncthread file, line 176:

# elif nfs_stat.st_ino != item.getInum():
# self._debug('Inode number changed -- conflicted.')
# return True

I don't understand why you make this comparaison between cache file
inode and nfs file inode. There are lightly chances that both files
would have same inodes.
Indeed, when I write in a new file, I get this conflict "inode number
changed"

Thanks for your response
Best regards, Bastien

June Tate-Gans

unread,
Jun 4, 2009, 1:08:54 PM6/4/09
to google-...@googlegroups.com
Bastien,

If I understand what you're saying, you're confused why we would
compare the local disk inode to the NFS inode -- we're actually not
doing that here. In this case, we're actually comparing the inode
number on NFS with the inode number that we cached to disk. If it
changed, then we can assume the entire file is different. In fact, we
actually /have/ to.

In the new file case, the _propogateChange method shouldn't be called
at all -- instead, _propogateNew should be called.
--
June Tate-Gans | Don't try to outweird me, three-eyes. I get stranger things
Sysops, SEA | than you free with my breakfast cereal. --Zaphod Beeblebrox

Bastien Bouzerau

unread,
Jun 9, 2009, 7:20:06 AM6/9/09
to google-...@googlegroups.com
Hi June,
Thank you for your answer, I will check why it calls PropogateChange in next days and I'll give you more details.
I'm actually integrating your tsumufs-applet script into tsumfs as a python thread. I haved work on gtk objects and tray icon display. I hope you will agree with my design. I will send you my class when it will be finished with commentaries associated.

Bastien

2009/6/4 June Tate-Gans <jtg...@google.com>
Reply all
Reply to author
Forward
0 new messages