Re: tar --one-file-system accesses remote file systems
Matt Seitz (matseitz) wrote: When I run tar -czlvf backup . in my home directory (/home/matseitz) , tar accesses a subdirectory (/home/matseitz/sjc-filer03a) that mounts a remote CIFS share. This problem and a proposed solution was mentioned in an earlier e'mail (http://www.cygwin.com/ml/cygwin/1998-09/msg00839.html). Is there a known solution to this issue? You can check recent (and not so recent) email archives on the subject. As I recall, it depends on your server and it's version. Older versions or FAT file-systems have their inodes faked. This may be the cause of the problem you're seeing. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tar --one-file-system accesses remote file systems
Larry Hall (Cygwin) [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Matt Seitz (matseitz) wrote: This problem and a proposed solution was mentioned in an earlier e'mail (http://www.cygwin.com/ml/cygwin/1998-09/msg00839.html). Is there a known solution to this issue? You can check recent (and not so recent) email archives on the subject. I tried. The only discussion I found was the link above. If you can give me a pointer to another thread, I'd appreciate it. I'll also try additional searches based on the information you gave below. As I recall, it depends on your server and it's version. Older versions or FAT file-systems have their inodes faked. This may be the cause of the problem you're seeing. Ah, yes, the mounted CIFS share is reported as a FAT file system*. So that may be the problem. I'll try it with a Windows server sharing an NTFS volume and see if I get a different result. *It's actually a Network Appliance ONtap WAFL QTree, configured to use UNIX security model. But ONtap reports UNIX QTrees as FAT file systems to CIFS clients.
Re: tar --one-file-system accesses remote file systems
Matt Seitz (matseitz) wrote: Larry Hall (Cygwin) reply-to-list-only-lh wrote in message ^^^ news:47B31A8F.7060008... ^^ http://cygwin.com/acronyms/#PCYMTNQREAIYR. Thanks. We don't want to be feeding the spammers around here. Matt Seitz (matseitz) wrote: This problem and a proposed solution was mentioned in an earlier e'mail (http://www.cygwin.com/ml/cygwin/1998-09/msg00839.html). Is there a known solution to this issue? You can check recent (and not so recent) email archives on the subject. I tried. The only discussion I found was the link above. If you can give me a pointer to another thread, I'd appreciate it. I'll also try additional searches based on the information you gave below. As I recall, it depends on your server and it's version. Older versions or FAT file-systems have their inodes faked. This may be the cause of the problem you're seeing. Ah, yes, the mounted CIFS share is reported as a FAT file system*. So that may be the problem. I'll try it with a Windows server sharing an NTFS volume and see if I get a different result. *It's actually a Network Appliance ONtap WAFL QTree, configured to use UNIX security model. But ONtap reports UNIX QTrees as FAT file systems to CIFS clients. That's it I expect. Going straight to the code, in fhandler_disk_file.cc, here's some code from fhandler_base::fstat_helper(): /* Enforce namehash as inode number on untrusted file systems. */ if (pc.isgood_inode (nFileIndex)) buf-st_ino = (__ino64_t) nFileIndex; else buf-st_ino = get_namehash (); One of the things that isgood_inode() checks for is that it's not a FAT drive. In case it is, you end up with a faked hash inode. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: tar --one-file-system accesses remote file systems
From: Larry Hall (Cygwin) Matt Seitz (matseitz) wrote: Matt Seitz (matseitz) wrote: This problem and a proposed solution was mentioned in an earlier e'mail (http://www.cygwin.com/ml/cygwin/1998-09/msg00839.html). Ah, yes, the mounted CIFS share is reported as a FAT file system*. That's it I expect. Going straight to the code, in fhandler_disk_file.cc, here's some code from fhandler_base::fstat_helper(): /* Enforce namehash as inode number on untrusted file systems. */ if (pc.isgood_inode (nFileIndex)) buf-st_ino = (__ino64_t) nFileIndex; else buf-st_ino = get_namehash (); One of the things that isgood_inode() checks for is that it's not a FAT drive. In case it is, you end up with a faked hash inode. Thanks for the diagnosis. I'm curious about something. The message I reference above also mentioned an issue with st_dev. It seems to imply that correcting the st_dev to use the volume serial number could resolve this issue. What is your opinion on that theory? -- Matt Seitz Manager, File System Virtualization Cisco Systems, Inc. .:|:.:|:.
Re: tar --one-file-system accesses remote file systems
Matt Seitz (matseitz) wrote: From: Larry Hall (Cygwin) Matt Seitz (matseitz) wrote: Matt Seitz (matseitz) wrote: This problem and a proposed solution was mentioned in an earlier e'mail (http://www.cygwin.com/ml/cygwin/1998-09/msg00839.html). Ah, yes, the mounted CIFS share is reported as a FAT file system*. That's it I expect. Going straight to the code, in fhandler_disk_file.cc, here's some code from fhandler_base::fstat_helper(): /* Enforce namehash as inode number on untrusted file systems. */ if (pc.isgood_inode (nFileIndex)) buf-st_ino = (__ino64_t) nFileIndex; else buf-st_ino = get_namehash (); One of the things that isgood_inode() checks for is that it's not a FAT drive. In case it is, you end up with a faked hash inode. Thanks for the diagnosis. I'm curious about something. The message I reference above also mentioned an issue with st_dev. It seems to imply that correcting the st_dev to use the volume serial number could resolve this issue. What is your opinion on that theory? Given that the message you found refers to code that's a good 10 years old, I think it's safe to assume that things here have changed. ;-) And they have. I found no 42 anywhere in the code that is related to st_dev. So that oddness is now gone. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
tar --one-file-system accesses remote file systems
When I run tar -czlvf backup . in my home directory (/home/matseitz) , tar accesses a subdirectory (/home/matseitz/sjc-filer03a) that mounts a remote CIFS share. This problem and a proposed solution was mentioned in an earlier e'mail (http://www.cygwin.com/ml/cygwin/1998-09/msg00839.html). Is there a known solution to this issue? -- Matt Seitz Manager, File System Virtualization Cisco Systems, Inc. .:|:.:|:. cygcheck.out Description: cygcheck.out -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
