[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20141222100744.F8W9I.38107.imail@eastrmwml208>
Date: Mon, 22 Dec 2014 10:07:44 -0500
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: Re: Cygwin
---- Solar Designer <solar@...nwall.com> wrote:
> Jim,
>
> Thanks! In the fallback code, do you somehow ensure that JtR will
> refuse to work with files > 2 GB, rather than seek to wrong offsets?
> e.g. on Linux this is achieved by building without large file flags, in
> which case open(2) is called (by its libc wrapper) without O_LARGEFILE.
> How does Cygwin handle this?
The code works just like it did prior to me adding the code for handling large files. I.e. it falls back to how cygwin stdio f*() functions work. They open a file, and fseek wraps when it hits 2gb, thus it is broken. If the user feeds it a file larger than 2gb, it will open the file, but will pretty much hang in a loop. I believe at one time I had code that would abort if the fseek(fp, 0, SEEK_END);ftell(fp) returned a - number. If that check is still there then at least it will complain that files larger than 2gb will not work. I can not find that block of code (I thought it was in wordlist.c). It is possible that check was removed.
>
> Of course. I only made that build to make sure there are no other build
> failures, and that the formats' self-tests pass (they do).
Like I said, if you really wanted it to work, we just need to make sure that the thin passthru fseeko64/ftello64 simply call the fseek/ftell, and they will with the changes to configure. I will see about making sure john properly refuses to load huge files in that case. The worst part of allowing john to run, is that it likely will get hung in a loop, processing the first candidates in the input file (first 2GB) over and over again. If there is no file 'seeking', just reading, then the 32 bit cygwin will work just fine. It will read out of a 100gb file just fine if read sequentially. But that means resumes will fail, etc. As will other things such as ETA computation, which seeks to end of file to get the file size.
cygwin32 was the only 32 bit supported system we knew of that we had no 'native' way to seek/tell in 64 bit mode. I thought I had worked around this by building my own 64 bit seek functions, but you spoiled my dream listing that the Win32 native functions I used are not in older cygwin :( I actually think those functions are in the mingw libs, at least that is what they appear to be. Cygwin uses sort of a hybrid usage of it's own libs and some of the mingw stuff. I know that even trying to use default AC_CHECK_FUNCS or AC_SEARCH_LIBS or AC_CHECK_LIB all failed to find that function, and I had to revert to simply writing a AC_LINK_IFELSE with a tiny source file that actually 'used' the function, to be able to find out it's existence or not.
I am not sure how many people are running a cygwin environment that is 3-4 years old however. And if they are and NEED it, then there is no harm at all of installing multiple cygwin environments. Many will play nicely with each other. They simply have to be installed in separate base directories.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
