Also unifies hidden file handling.
Fixes bug [53826](https://bugs.winehq.org/show_bug.cgi?id=53826).
--
v11: ntdll: Try to avoid requesting the file name for a handle.
ntdll: Ensure that attributes are kept the same when renaming or hard-linking a file.
ntdll: Set xattr in NtCreateFile if inferred and requested attributes don't match.
ntdll: Only infer hidden attribute from file name if xattr is not present.
ntdll: Handle hidden file names in fd_get_file_info.
ntdll: Pass file path into fd_get_file_info if available.
ntdll: Do not compute file attributes for info classes that don't need them.
ntdll: Handle hidden file names inside get_file_info instead of after it.
ntdll: Do not open-code hidden file handling in get_dir_data_entry.
ntdll/tests: Add test for file attributes of files with names beginning with a dot.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1148
On Tue Nov 15 21:40:55 2022 +0000, Rémi Bernon wrote:
> Because this is a blocking call, which can call application callbacks,
> or otherwise also blocking until there's a sample ready.
> We want to be able to deliver samples from the callback thread, on other
> streams, without being blocked and without blocking the reader. There's
> no point in making all this asynchronous otherwise.
GetNextSample() already calls callbacks with the lock held. I.e. this is basically doing the same thing as described above. I also don't see how delivering samples can block this, or the reverse, since we drop the CS in order to deliver samples. What deadlock results from not dropping the CS here?
I would guess that AllocateForOutput() is blocking in IMemAllocator::GetBuffer(), but if that's the case, according to my reading of 2/4, we should either be inside of IWMReaderCallback::OnSample() or still holding the CS and about to call it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15909
On Tue Nov 15 21:40:55 2022 +0000, Rémi Bernon wrote:
> The most common case where this happens is on EOS, I don't think we want
> to print error. When streams are deselected this would happen as well if
> it interrupts the wait on buffer.
Sure, but then we probably should avoid printing a WARN either, since that's expected behaviour.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1311#note_15908