Re: xdvipdfmx:fatal: This font using the "seac" command for accented, characters...

[Mark]

Dear Ken:

Thanks for the notice!

Btw., recently I experienced xpdf failing to start due to rebasement 
errors similar to what a few people reported here months ago, and the 
xpdf version from your repository worked for me. So I'd be happy to see 
your xpdf compilation in the standard cygwin distribution.


Best,

Mark

On 18.06.2016 22:04, cygwin-digest-h...@cygwin.com wrote:

cygwin_203614.ezm

Subject:
Re: xdvipdfmx:fatal: This font using the "seac" command for accented
characters...
From:
Ken Brown 
Date:
18.06.2016 13:41

To:
cygwin@cygwin.com


On 6/17/2016 5:54 PM, Mark McGregor wrote:

Ken wrote:
No, I don't think XeTeX is dying. A look at its git repository shows
lots of commits from Jonathan Kew and Arthur Reutenauer in the last
few months.


The last commit was over 1 month ago: a 1-line change from JK. I'm not
overly optimistic that anything will happen to this bug report at all.
But, anyway, thank you for having reported!


I had some private correspondence with Akira Kakuto about my bug report,
and he said it isn't a bug.  The problem is simply that xetex has very
limited support for type1 fonts, and the solution is to remove them from
the fonts that fontconfig knows about, as you've done.  So I'll probably
make this change the next time I update texlive.

Ken



--
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

Re: FUSE for Cygwin - was: Re: Fork and Windows Heap

[Bill Zissimopoulos]

Hello, Jeffrey:

On 6/18/16, 1:19 PM, "Jeffrey Altman"  wrote:


>On 6/18/2016 4:03 PM, Bill Zissimopoulos wrote:
>> * A directory cannot be renamed if it or any of its subdirectories
>> contains a file that has open handles (except in the batch-oplock case
>> described earlier).
>> 
>> 
>> In particular the third bullet point mandates that the FSD keeps
>> information not only about files that are open, but also of their
>> hierarchical relationships. The easiest way to do this on Windows is to
>> maintain a mapping of file names to open files.
>
>This is not how my file system redirector enforces the rule.  The file
>control block (representing the handle) for an open file maintains a
>reference to the directory object through which it was opened.  As long
>as the directory object has outstanding references the redirector fails
>the rename request.

Thank you for your very useful pointer. I have a question. In your file
system redirector if the file "\comp1\comp2\name.ext” gets opened, do you
also open (internally) the directories "\comp1" and "\comp1\comp2”? It
sounds like you do.

I understand that this is what UNIX VFS does, but it is my understanding
that Windows does not require this. WinFsp avoids it so that it will not
send extraneous requests to the user mode file system. WinFsp only knows
about files that have been explicitly opened using IRP_MJ_CREATE.

But perhaps I misunderstand what you are suggesting. Apologies for being
thick, but can you please elaborate?

>File path maps to specific files in fact do not work because the file
>can be hard linked into more than one directory.  Only the directory
>that was used to create a file handle is restricted from renaming.

I agree. But my FSD does not currently support hard links. If/when it does
I will have to revisit this design.

Many thanks for your insight. BTW, if your redirector is public/opensource
I would love to take a look.

Bill

Re: FUSE for Cygwin - was: Re: Fork and Windows Heap

[Jeffrey Altman]

On 6/18/2016 4:03 PM, Bill Zissimopoulos wrote:
> * A directory cannot be renamed if it or any of its subdirectories
> contains a file that has open handles (except in the batch-oplock case
> described earlier).
> 
> 
> In particular the third bullet point mandates that the FSD keeps
> information not only about files that are open, but also of their
> hierarchical relationships. The easiest way to do this on Windows is to
> maintain a mapping of file names to open files.

This is not how my file system redirector enforces the rule.  The file
control block (representing the handle) for an open file maintains a
reference to the directory object through which it was opened.  As long
as the directory object has outstanding references the redirector fails
the rename request.

File path maps to specific files in fact do not work because the file
can be hard linked into more than one directory.  Only the directory
that was used to create a file handle is restricted from renaming.

Jeffrey Altman




smime.p7s
Description: S/MIME Cryptographic Signature

Re: FUSE for Cygwin - was: Re: Fork and Windows Heap

[Bill Zissimopoulos]

On 6/18/16, 1:02 AM, "Corinna Vinschen"  wrote:


>>but I eventually had to change it for a number of issues (notably Rename
>> support).
>
>For rename support you can use the index number as well, usually,
>since you can open a file by index number.  At least on NTFS.

Unfortunately it is not as simple as that. A proper Rename implementation
needs to conform to rules that effectively require the FSD to maintain
filename/path information about open files.

From "FILE_RENAME_INFORMATION structure” [1]:
<<
Special rules for renaming open files:

* A file cannot be renamed if it has any open handles, unless it is only
open because of a batch opportunistic lock (oplock) and the batch oplock
can be broken immediately.

* A file cannot be renamed if a file with the same name exists and has
open handles (except in the batch-oplock case described earlier).

* A directory cannot be renamed if it or any of its subdirectories
contains a file that has open handles (except in the batch-oplock case
described earlier).

>>

In particular the third bullet point mandates that the FSD keeps
information not only about files that are open, but also of their
hierarchical relationships. The easiest way to do this on Windows is to
maintain a mapping of file names to open files.

>>I am not saying that it would not be possible to change this
>> part of WinFsp, I just believe that it is a non-trivial change at this
>> moment.
>
>Ok.

I have thought more about this.

As mentioned, originally the FSD maintained a mapping of IndexNumber to
“FileNode” somewhat similar to UNIX. This is because it is important for
an FSD to be able to identify when the same file is being reopened; for
example, to properly implement file deletion (a file gets deleted only
when its last handle is closed) or sharing or caching.

When I had to implement Rename, bullet point (3) above complicated
matters. So I ended up maintaining two tables for a while, one for
IndexNumbers and one for file names. Then I ended up scrapping the
IndexNumber table when I decided that I would not implement hard links
(for a variety of reasons).

Perhaps what I should have done instead is to maintain IndexNumber
relationships (parent/child) and do my rename tests based on that. That’s
what a VFS system would do, although I am not sure that it is the cleanest
solution within a Windows FSD.

Compounding this the user mode file system may not even send me back real
IndexNumber’s, so then I would have to fake them (e.g. file name hash).

In any case I am going to shelve this for a while and come back to it at a
later time as there are lots of higher priority (for me) things to do on
WinFsp.

--

In other news I made a new release yesterday and I am happy to say that
this release supports Cygwin. I am able to compile SSHFS with a minimal
patch and it runs correctly under Cygwin.

The SSHFS-Win repo is here [2].

I may actually go the extra mile and create a libfuse.dll so that things
like FUSEPY can work out of the box.

Bill

[1] 
https://msdn.microsoft.com/en-us/library/windows/hardware/ff540344(v=vs.85)
.aspx
[2] https://bitbucket.org/billziss/sshfs-win

[ANNOUNCEMENT] Updated: gcc-5.4.0-1 (x86/x86_64)

[JonY]

gcc-5.4.0-1 has been uploaded for 32bit and 64bit Cygwin and marked as
stable.

This version has been built with
--with-default-libstdcxx-abi=gcc4-compatible so it should remain
compatible to GCC 4 C++ ABI.

Note that C11 with gnu extensions is now default for C. See
https://gcc.gnu.org/gcc-5/porting_to.html for more help on porting code
to GCC 5.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.




signature.asc
Description: OpenPGP digital signature

Updated: gcc-5.4.0-1 (x86/x86_64)

[JonY]

gcc-5.4.0-1 has been uploaded for 32bit and 64bit Cygwin and marked as
stable.

This version has been built with
--with-default-libstdcxx-abi=gcc4-compatible so it should remain
compatible to GCC 4 C++ ABI.

Note that C11 with gnu extensions is now default for C. See
https://gcc.gnu.org/gcc-5/porting_to.html for more help on porting code
to GCC 5.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.




signature.asc
Description: OpenPGP digital signature

Re: xdvipdfmx:fatal: This font using the "seac" command for accented characters...

[Ken Brown]

On 6/17/2016 5:54 PM, Mark McGregor wrote:

Ken wrote:
No, I don't think XeTeX is dying. A look at its git repository shows lots of 
commits from Jonathan Kew and Arthur Reutenauer in the last few months.


The last commit was over 1 month ago: a 1-line change from JK. I'm not overly 
optimistic that anything will happen to this bug report at all. But, anyway, 
thank you for having reported!


I had some private correspondence with Akira Kakuto about my bug report, 
and he said it isn't a bug.  The problem is simply that xetex has very 
limited support for type1 fonts, and the solution is to remove them from 
the fonts that fontconfig knows about, as you've done.  So I'll probably 
make this change the next time I update texlive.


Ken

--
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

Re: FUSE for Cygwin - was: Re: Fork and Windows Heap

[Corinna Vinschen]

Hi Bill,

On Jun 17 19:48, Bill Zissimopoulos wrote:
> Hi, Corinna:
> 
> On Jun 17 07:25, Bill Zissimopoulos wrote:
> > > Windows hard links are rather un-POSIX like and rarely used on Windows.
> > > After considering the required changes on the FSD for a feature that is
> > > so rarely used I opted against supporting them.
> > 
> > I disagree here.  Windows hardlinks work fine and pretty much as on
> > POSIX with the exception of DOS mode bits.  Those are not per file but
> > per file entry as far as my experiecen goes.  One of the reasons we try
> > to ignore them as much as possible.
> 
> I no longer remember all the details now, because it was a few months ago
> that I looked into this and determined that hard links are "un-POSIX like".
> As far as I recall there was the FileAttributes issue (which I now think
> may have been my incorrect understanding of the documentation), but there
> was also the issue of FindFirstFileName/FindNextFileName, which is not
> something that POSIX supports out of the box (AFAIK).
> 
> Regarding the FileAttributes issue. The Windows documentation seems to
> suggest that they are stored with the file and not the directory entry.

Yes, you're right.  Apparently I didn't really think when writing.  The
*real* issue with DOS attributes is that they are per file :) That has
implications if you have multiple hardlinks to symlinks of the "Windows
shortcut" type, but that shouldn't affect your WinFSD.

> The bigger issue is that the FSD now maintains an internal table of open
> files that is indexed by file name. It actually started as a table of open
> files indexed by IndexNumber (inode number Windows equivalent),

Yeah, Cygwin is presenting them as i-node numbers.

> but I
> eventually had to change it for a number of issues (notably Rename
> support).

For rename support you can use the index number as well, usually,
since you can open a file by index number.  At least on NTFS.

> I am not saying that it would not be possible to change this
> part of WinFsp, I just believe that it is a non-trivial change at this
> moment.

Ok.

> [...]
> Let's examine the lifetime of a call to creat(). Suppose a Cygwin process
> does creat("/cygdrive/z/foo*bar"). In the following OP is the "originating
> process", CW is the "Cygwin runtime", NT is NTOS, WD is the "WinFsp FSD",
> WL is the "WinFsp DLL", FL is the "FUSE layer", and FS is the "user mode
> FUSE file system".
> 
> OP: creat("/cygdrive/z/foo*bar")
> CW: NtCreateFile(L"\\foo\xf02abar") <--- Cygwin translation
> NT: IRP_MJ_CREATE L"\\foo\xf02abar"
> WD: FspFsctlTransactCreateKind L"\\foo\xf02abar"
> WL: FSP_FILE_SYSTEM_INTERFACE::Create L"\\foo\xf02abar"
> FL: fuse_operations::create "/foo*bar"  <--- WinFsp/FUSE
> translation
> FS: somehow satisfies fuse_operations::create
> [snip return path]
> 
> The opposite happens when the file system communicates a file name back
> to the originating process, as in readdir().
> 
> OP: readdir("/cygdrive/z/")
> [snip call path]
> FS: fuse_operations::readdir response: "foo*bar"
> FL: FSP_FILE_SYSTEM_INTERFACE::ReadDirectory response: L"foo\xf02abar"
> WL: FspFsctlTransactQueryDirectoryKind response: L"foo\xf02abar"
> WD: IRP_MN_QUERY_DIRECTORY response: L"foo\xf02abar"
> NT: NtQueryDirectoryFile response: L"foo\xf02abar"
> CW: readdir response: "foo*bar"
> OP: receives "foo*bar"

If I'm not missing anything crucial, that's pretty much exactly what we
need.  The Cygwin process reads and writes the file as if the '*' is
a valid character and the entire process of mapping is completely
transparent to both sides.  Looks perfect to me.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature