This problem has existed for quite a while, and I was sticking with 2.2 to work around it, but 3.0 has been more necessary, lately. (Yes, 2.2 works fine.) Using SMBD to share a locally mounted NTFS drive displays all directories as a zero byte file until it is opened, at which time SMBD realizes that it is a directory and allows navigation. Repro: Mount NTFS drive locally Share NTFS mount via SMBD Connect to share from MS File sharing (XP/2K/2K3) or via smbclient Example via smbclient: ... MSDOS.SYS 0 Sun Jun 15 22:32:58 2003 Music 0 Sun Jan 23 17:49:39 2005 NTDETECT.COM 47564 Mon Aug 9 22:15:20 2004 ntldr 250032 Mon Aug 9 22:15:20 2004 ... smb: \> cd Music cd \Music\: not a directory smb: \> get Music NT_STATUS_FILE_IS_A_DIRECTORY opening remote file \Music smb: \> cd Music cd \Music\: not a directory
I've had the same problem on OpenBSD 3.7 with Samba 3.0.14a. It seems like the problem lies in the NTFS code rather than Samba. Samba seems to rely on the "number of links" information in the filesystem which the NTFS driver fails to report. To get it to work I modified the NTFS code to always report a minimum of 1 number of links and recompiled the kernel. I did the following modification in the file ntfs_vnops.c on line 232. before: vap->va_nlink = ip->i_nlink; after: vap->va_nlink = (ip->i_nlink ? ip->i_nlink : 1); Use this as only a temoprary solution since I don't know how it affects the NTFS driver.
I would say that the problem is definitely with Samba, since 2.2 works fine, and 3.0 doesn't. The OS has no issues with NTFS at all.
You are going to need to get some help from the ntfs driver folks. I seriously doubt that it is posix compliant. Or at least give some more evidence to show that the ntfs driver is giving us the correct info and we a munged it.
Since this is a definite regression in functionality it should at least be investigated by the Samba team to determine why. If the result is the driver then at least that information can be taken to the driver team. Since it DID work and now it doesn't, Samba should investigate why. The only difference is which version of Samba is installed. 2.2 works, 3.0 doesn't. Marking this invalid without even investigating is a cop-out.
Would you rather me be honest about the amount of attention this bug will probably receive or just leave it open? If Samba works on posix filesystems such as xfs, etc2/3, reiser, jfs, ufs, etc....and it doesn't work on NTFS then you need to get your NTFS developers to run the posix compliance tests. The fact that no one else has reported this bug in over 24 months of 3.0.x releases is an indication of the pressure from the community to work. If you have a valid patch that is no full of #ifdef's then We'll be glad to work accept it. Or if you want to put on of your NTFS developers in touch with us, I'll be glad to try to work the bug from that angle. But asking us to fix a bug without even providing log files or trace logs? That's just not reasonable. Sorry. Wish I had better news for you. But I'm just being honest about the priority of this bug.
I can tell you the problem exactly because of the analysis done by Andreas Wanberg. Samba uses these macros to determine a valid return from a stat() call for a file and a directory : include/smb_macros.h:#define VALID_STAT(st) ((st).st_nlink != 0) include/smb_macros.h:#define VALID_STAT_OF_DIR(st) (VALID_STAT(st) && S_ISDIR((st).st_mode)) If your filesystem is returning zero for st_nlink then it's NOT GOING TO WORK. Your filesystem is broken. Fix it using the patch kindly supplied by Andreas and re-build your kernel. This is *NOT* a Samba bug. The reason it worked in 2.x was these macros weren't being used. They are essential for effieciency and we're not going to pull them out of Samba just because *you* have a broken POSIX filesystem. Jeremy.
Created attachment 1460 [details] Proposed patch Ok - having said all that and been nasty (sorry) :-) I really do want to help and don't like leaving a customer with a broken system. I think the attached patch will fix the problem for you by solving it in userspace. The filesystem is still broken though.... I'll leave this up to Jerry if he wants to add it in as a user-selectable compile-time fix. Jeremy.
Jeremy, do you really think it is a good idea to work around this bug rather than just gettign the FreeBSD NTFS driver folks to fix their file system? I'm assuming the BROKEN_STAT_LINK_COUNT is going to be a manual #define.
Oh yeah it would be a manual define for broken systems. I'm not so sure I want to add this code anyway, I just felt really guilty about being nasty to the poor bloke. I wanted to at least leave him with a working system :-). Jeremy.
I appreciate the code even if it's not going to be integrated. If nothing else, as I said, it gives me something to go to the driver developers with as fodder.
Does it work ? Does it fix your particular issue ? That's what I'd like to know. Thanks, Jeremy.
Today was my first chance at testing it, and it does indeed fix the issue in question. I'm definitely going to forward on the information in this bug to the BSD driver team.