This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Sep 14 14:34, Warren Young wrote: > On Sep 12, 2015, at 11:14 AM, Nem W Schlecht <nemws1@gmail.com> wrote: > > > > The only thing I can think of is that the 2nd drive is >2TB. > > The same thing happens here with a 3.1 TB Fusion drive and a 500 GB external drive, so no, I donât think the volume size is the real issue. > > I assume you are seeing the same thing that I am, that Explorer shows the root contents of both drives just fine? > > When I straceâd an ls of one of these root shares here, I got 764 lines ofâemissions, of which this section seems the most interesting to me: > > 1051 263166 [main] ls 4720 stat64: entering > 625 263791 [main] ls 4720 normalize_posix_path: src /p > 609 264400 [main] ls 4720 normalize_posix_path: /p = normalize_posix_path (/p) > 630 265030 [main] ls 4720 mount_info::conv_to_win32_path: conv_to_win32_path (/p) > 653 265683 [main] ls 4720 mount_info::cygdrive_win32_path: src '/p', dst 'P:\' > 668 266351 [main] ls 4720 set_flags: flags: binary (0x2) > 674 267025 [main] ls 4720 mount_info::conv_to_win32_path: src_path /p, dst P:\, flags 0x4022, rc 0 > 1168 268193 [main] ls 4720 symlink_info::check: 0x0 = NtCreateFile (\??\P:\) > 10641 278834 [main] ls 4720 symlink_info::check_reparse_point: NtFsControlFile(FSCTL_GET_REPARSE_POINT) failed, 0xC0000275 > 839 279673 [main] ls 4720 symlink_info::check: not a symlink > 1049 280722 [main] ls 4720 symlink_info::check: 0 = symlink.check(P:\, 0x24B620) (0x4022) > 655 281377 [main] ls 4720 path_conv::check: this->path(P:\), has_acls(0) > 640 282017 [main] ls 4720 stat_worker: got 5 error from path_conv > 757 282774 [main] ls 4720 __set_errno: int stat_worker(path_conv&, stat*):1933 setting errno 5 > 714 283488 [main] ls 4720 stat_worker: -1 = (\??\P:\,0x600042080) > > Why errno 5 from path_conv? Probably because of the above symlink_info::check_reparse_point: NtFsControlFile(FSCTL_GET_REPARSE_POINT) failed, 0xC0000275 This is in fact a weird error code in this scenario. Consider that symlink_info::check_reparse_point is *only* called, if the file to check (here "P:\") has the FILE_ATTRIBUTE_REPARSE_POINT flag set. So from the Windows perspective it is certainly a reparse point. Cygwin checks the flag to allow evaluating of reparse points as symlinks. If the flag is set, it calls symlink_info::check_reparse_point which in turn calls status = NtFsControlFile (..., FSCTL_GET_REPARSE_POINT, ...); to fetch the target information the reparse point points to, in POSIX terms the symlink target. But *this* call returns a status of 0xC0000275, which means STATUS_NOT_A_REPARSE_POINT. And since it's totally unexpected that NtFsControlFile fails on a reparse point, the code sets errno to EIO. Hang on. The FILE_ATTRIBUTE_REPARSE_POINT flag is set but when calling a function to fetch the reparse data it's no reparse point anymore? How dumb is that? I can't reproduce this bug with my Samba drives, but it's not actually a bug in Cygwin from my perspective. Yeah, that observation doesn't really help, so I applied a potential workaround to Cygwin. If you're set up to build your own Cygwin, please give it a try. Otherwise I'll upload a new snapshot in the next couple of days. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Attachment:
pgpbbY0wqxfMz.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |