This is the mail archive of the
mailing list for the Cygwin project.
Re: Error accessing mapped drive >2TB?
- From: Andrey Repin <anrdaemon at yandex dot ru>
- To: Corinna Vinschen <cygwin at cygwin dot com>, cygwin at cygwin dot com
- Date: Wed, 21 Oct 2015 15:33:56 +0300
- Subject: Re: Error accessing mapped drive >2TB?
- Authentication-results: sourceware.org; auth=none
- References: <CA+2x6-L_pqdN6PHE0c15hcmrmB66Z75Hz95cH+dbcn4yXuVZNg at mail dot gmail dot com> <712A87EA-64C7-4033-BE7F-39C8C8D527EB at etr-usa dot com> <20151021100328 dot GL5319 at calimero dot vinschen dot de>
- Reply-to: cygwin at cygwin dot com
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
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
With best regards,
Wednesday, October 21, 2015 15:32:13
Sorry for my terrible english...