Mail Archives: cygwin/2011/10/21/05:11:58
On Oct 20 19:29, Corinna Vinschen wrote:
> On Oct 20 15:57, Franz Sirl wrote:
> > Am 2011-10-20 15:09, schrieb Corinna Vinschen:
> > >As I wrote, it's not used, so even if it fails, it's worth a
> > >support case with Novell, but it doesn't mean we have to change
> > >Cygwin.
> >
> > It fails with errorcode 0xc0000022, Access denied.
>
> It might be worth a try to ask the Novell support why this occurs.
> This is a bug, IMHO. Since Vista, this call should even be supported
> in the Win32 API, using the call
>
> FILE_BASIC_INFO fbi;
> GetFileInformationByHandleEx (fhdl, FileBasicInfo, &fbi, sizeof fbi);
>
> > >>>- NWFS only supports filenames which follow DOS conventions. That is,
> > >>> it does not support filenames with leading spaces or trailing dots and
> > >>> spaces. This is only checked for when generating filenames.
> > >>
> > >>Leading and trailing spaces seem to work, trailing dots fail with
> > >>"Permission denied".
> > >
> > >So we still have to assume that only DOS filenames work.
> >
> > Hmm, I wonder if I should file at least a low priority enhancement
> > request for that.
> >
> > >>>- NWFS does not support re-opening a file by handle, so it always has to
> > >>> be re-opened by name. The only difference here is how the
> > >>> OBJECT_ATTRIBUTES is created, with a handle or with a name.
> > >>
> > >>I've worked with Novell to fix that one for NcFsd, will be in one of
> > >>the next releases (IR10 or IR11 I guess).
> > >
> > >Cool, but I think that NcFsd should still be subsumed under NWFS.
> > >The fact that re-opening doesn't quite work isn't such a big problem,
> > >and by using the OBJECT_ATTRIBUTES with a name we can support older
> > >versions of NcFsd as well.
> >
> > Older versions of NcFsd have even more problems with Cygwin, so
> > supporting them doesn't really make sense. It only works reasonable
> > since this years June release. I would prefer to keep this code path
> > exercised :-).
>
> Hmm, that should be possible. But keep in mind that this does not
> have a better performance on all filesystems.
>
> > >Are you ok if I send you an URL to a test DLL via PM for this issue?
> > >I would add the "handle NcFsd as NWFS" as well to this DLL, otherwise
> > >it would be identical to the latest snapshot, which should be available
> > >now, btw.
> >
> > Sure, PM me the URL. [...]
>
> Thanks, but not today anymore.
Rather than PM, I've just uploaded a snapshot which adds explicit NcFsd
support. Please give it a try. NcFsd is marked as having a buggy Query
FileBasicInformation support and as only supporting DOS filenames. It
is not marked as having a buggy re-open file support and the comment
notes that this is supported starting with IR10, which isn't yet
released, AFAICS.
But there's one more change: As you observed, NcFsd does not return a
STATUS_SHARING_VIOLATION when trying to open the top level directory for
DELETE, rather trying to set the delete disposition fails with
STATUS_CANNOT_DELETE. When this error occurs, unlink_nt now also checks
for NcFsd, and if so, it tries delete-on-close as another method to
delete the file/directory.
This is just an experiment, so could you please take this snapshot and
test your fine testcase under strace on W7/NcFsd and send the strace here?
However, IMHO this is a bug in NcFsd, just like the sharing violation
in NWFS. Since NcFsd is activaly maintained, it might make sense for
you or any other NcFsd user to open a support case for this problem, just
like for the FileBasicInformation thingy.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -