Greetings, Corinna Vinschen! >> > 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? That's… interesting. Windows does not allow for reparse points to networked locations. Symlinks all right, directory junctions no. > 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. -- With best regards, Andrey Repin Wednesday, October 21, 2015 15:32:13 Sorry for my terrible english...