Inode numbering not consistent across reboots

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a file on an NTFS formatted partition
2. Check the inode number with `stat -x file` or `ls -i file`
3. Reboot
4. Check again

What is the expected output? What do you see instead?
Inode number should be the same, but it's different each reboot

What version of the product are you using? On what operating system?
- OS X 10.5.4
- MacFuse 1.7
- NTFS-3g 1.2812-ublio

Please provide any additional information below.
Some apps rely on the inode number to see if a certain file has changed.
The expected bahaviour is that this number remains the same across reboots,
unless the file changes or moves partition/device. 

At first I thought it was an NTFS-3g issue, but the lead dev tells me NTFS
does have consistent inode numbers across reboots. This seems to be true,
since Linux + NTFS-3g does not have this issue.

Original issue reported on code.google.com by lukthelu...@gmail.com on 25 Aug 2008 at 10:37

[GoogleCodeExporter]

It still is an issue with the ntfs-3g *build* that you have. Consistent 
(user-file-system-provided) inode numbers 
are disabled in the version of ntfs-3g you are using. From the source:

/* ntfs-3g-1.2812_patched/src/ntfs-3g.c */
#if defined(__APPLE__) || defined(__DARWIN__)
        // Disable use_ino for MacFUSE, since it makes Finder unhappy
        if (fuse_opt_add_arg(&args, "-okernel_cache,attr_timeout=0") == -1)
#else
if (fuse_opt_add_arg(&args, "-ouse_ino,kernel_cache,attr_timeout=0") == -1)
#endif /* defined(__APPLE__) || defined(__DARWIN__) */
...

Now see this for some background:

http://groups.google.com/group/macfuse-
devel/browse_thread/thread/4961005a674791aa/d2320462b1c4866b?lnk=gst&q=use_ino#d
2320462b1c4866b

As I said more than once in the above thread, I suggested disabling use_ino 
only to experiment at that time. You 
should tell the ntfs-3g guys (who do Mac OS X builds) not to disable use_ino.

Original comment by si...@gmail.com on 25 Aug 2008 at 11:04

[GoogleCodeExporter]

Original comment by si...@gmail.com on 26 Aug 2008 at 1:17

• Changed state: Invalid