Hi Franz, On Jul 29 15:25, Franz Sirl wrote: > Am 2016-07-28 um 21:58 schrieb Corinna Vinschen: > > Could it be permissions? Can you send the output of `icacls T:'? > > > > Other than that, an strace of `ls -ld /cygdrive/t/.' might give a clue. > > Hi Corinna, > > no, it's not permissions, it's the order in which files are returned for > directory enumeration. There is this code snippet around line ~2800 in > path.cc: > > RtlSplitUnicodePath (&upath, &dirname, &basename); > .... > status = NtQueryDirectoryFile (dir, NULL, NULL, NULL, &io, > &fdi_buf, sizeof fdi_buf, > FileIdBothDirectoryInformation, > TRUE, &basename, TRUE); > /* Take the opportunity to check file system while we're > having the handle to the parent dir. */ > fs.update (&upath, dir); > NtClose (dir); > > It tries to query the first entry returned and assumes (no idea if Windows > guarantees that, POSIX does not AFAIK) that it is "."
No, not at all. It was timply never intended that symlink_info::check's
NtQueryDirectoryFile branch is called for top-level dirs. The path split
works under the assumption that we're in some subdir.
> this drive it is just some file that happens to be first in the directory
> enumeration. And then everything goes wrong from there.
Your below strace indicates it's going pear-shaped a bit earlier:
> The related strace excerpt shows:
>
> 1788 764507 [main] ls 7456 lstat64: entering
> 45 764552 [main] ls 7456 normalize_posix_path: src /cygdrive/t/.
> 44 764596 [main] ls 7456 normalize_posix_path: /cygdrive/t/ =
> normalize_posix_path (/cygdrive/t/.)
> 42 764638 [main] ls 7456 mount_info::conv_to_win32_path:
> conv_to_win32_path (/cygdrive/t)
> 49 764687 [main] ls 7456 mount_info::cygdrive_win32_path: src
> '/cygdrive/t', dst 'T:\'
> 46 764733 [main] ls 7456 set_flags: flags: binary (0x2)
> 44 764777 [main] ls 7456 mount_info::conv_to_win32_path: src_path
> /cygdrive/t, dst T:\, flags 0x4022, rc 0
> 372 765149 [main] ls 7456 symlink_info::check: 0x0 = NtCreateFile
> (\??\T:\)
that's the debug_printf on line 2674. NtCreateFile succeeds.
> 316 765465 [main] ls 7456 symlink_info::check: 0xC7E90006 =
> NtQueryInformationFile (\??\T:\)
This is the debug_printf on line 2766. The status code returned at
this point is from conv_hdl.get_finfo() which in turn calls
file_get_fai(), defined in path.cc at line 1299ff.
I never saw this status code 0xC7E90006 before, but it comes very
likely from the device driver itself. What that means is that
NtQueryInformationFile (..., FileAllInformation) has gone awry for
some reason.
This is a bit of a bummer. FileAllInformation should work on all
supported filesystems.
> So upath was likely "\??\T:\" and I guess RtlSplitUnicodePath() returned
> "" or "*.*" for basename.
Don't guess, debug it! Either install the cygwin-debuginfo package,
or build your own Cygwin without optimization for easier debugging.
> Maybe a possible fix/workaround would be to force basename to "." in this
> case?
In the first place it would be prudent to find out why the
FileAllInformation info class fails on this drive. And in the second
place it would be important to find out how to fix this. Potential
checks:
- Buffer alignment of the FILE_ALL_INFORMATION member in class
path_conv_handle.
- Buffer size of the FILE_ALL_INFORMATION member. For instance,
does it work if the buffer is 1 byte bigger? Or perhaps if
the buffer is NAME_MAX bigger?
- If the above fails, adding a code path to file_get_fai for broken
filesystems which calls NtQueryInformationFile twice, once with
FileBasicInformation, once with FileStandardInformation info class.
The old version of the function, called file_get_fnoi, had some
code along these lines already. For reference see
git show eed35efb
> And, as an explanation, this happened because during the copying of this
> share
> the filesystem was changed from pure ext3 to ext3 with dir_index enabled.
> With
> dir_index enabled the directory entries are enumerated in an order dictated
> by the hashing I guess. I turned of the dir_index feature and Cygwin started
> working normally again on this drive. But note that it only works because
> now "a directory" is returned as first entry, but it seems it's usually not
> "." with NcFsd. Seems like it worked by accident before.
Yes, that may be the case. We might have to revert code along the
lines of the old file_get_fnoi function to make it work again.
The desired result is that we *don't* call the NtQueryDirectoryFile
code path. This is meant to be used only for files and dirs with no
permission to read their meta data.
HTH,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
