_wstat does not work with Windows Vista symbolic links. In these cases,
_wstat will always report a file size of 0. _stat does work correctly with
symbolic links.
Ugh, how weird and unexpected. (My expectation would have been that
neither supports symbolic links.) For which C runtime is
Ugh, how weird and unexpected. (My expectation would have been that
neither supports symbolic links.) For which C runtime is this, btw,
the system msvcrt.dll, or some of the MSVC-version-specific ones?
The MSDN documentation doesn't specify. I suspect its all of them TBH.
Instead, we should
Ugh, how weird and unexpected. (My expectation would have been that
neither supports symbolic links.) For which C runtime is this, btw,
the system msvcrt.dll, or some of the MSVC-version-specific ones?
The MSDN documentation doesn't specify. I suspect its all of them TBH.
Actually, looking
On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist t...@iki.fi wrote:
Sure but if all I want to know how big a file is, do I *really* want to link
in all of that extra crud? GIO is huge. There are times when the low level
functions are just plain appropriate.
I would say, bah. Any actively
hi;
On 29 September 2011 09:57, Andrew W. Nosenko
andrew.w.nose...@gmail.com wrote:
On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist t...@iki.fi wrote:
I would say, bah. Any actively maintained (or recently written)
GLib-using code that doesn't use GIO by now is just being maintained
or written
On Thu, Sep 29, 2011 at 10:05:57AM +0100, Emmanuele Bassi wrote:
On 29 September 2011 09:57, Andrew W. Nosenko
andrew.w.nose...@gmail.com wrote:
On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist t...@iki.fi wrote:
I would say, bah. Any actively maintained (or recently written)
GLib-using code
On Thu, Sep 29, 2011 at 12:05, Emmanuele Bassi eba...@gmail.com wrote:
hi;
On 29 September 2011 09:57, Andrew W. Nosenko
andrew.w.nose...@gmail.com wrote:
On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist t...@iki.fi wrote:
I would say, bah. Any actively maintained (or recently written)
if GIO is measurably slower at doing I/O than a stat(), please: file
bugs along with profiling data.
This is WAY off topic but still ... how can you possibly believe it is NOT
slower? One system call versus:
1. Allocate arrays
2. Allocate hash tables
3. Do strdups
4. Calculate hashes
5.
On 29 September 2011 10:53, Kean Johnston kean.johns...@gmail.com wrote:
I really don't need accurate GPS measuring to know that a Bugati Veyron is
faster than a Fiat Uno, any more than I need to provide you with profiling
data to prove that GIO is slower than g_stat().
I can also tell you
Of course GIO is slower when you look at the LoC count, the question
is for the typical case is performance acceptable. If your
application is opening a million files then maybe it's not typical.
Maybe my application runs on a router and not on an 64-core Core i5000 with
16 petabytes of RAM.
On 29 September 2011 11:13, Kean Johnston kean.johns...@gmail.com wrote:
No way you can convince me
otherwise I'm afraid, and that's not because I'm being stubborn, it's
because I (and I think you) know I'm right. GIO is appropriate for some
applications, of that I have no doubt, but trying to
If you are happy limiting yourself to a single platform and don't need
some the magic that comes with GIO, feel free to use stat(). It's not
UNIXWARE, SCO OpenServer, AIX, Solaris, MacOS X, Windows, Linux,
FreeBSD, OpenBSD, NetBSD, Minix, HP-UX ... did I miss any platforms? I'll
consider
Am 29.09.2011 12:24, schrieb Kean Johnston:
If you are happy limiting yourself to a single platform and don't need
some the magic that comes with GIO, feel free to use stat(). It's not
UNIXWARE, SCO OpenServer, AIX, Solaris, MacOS X, Windows, Linux,
FreeBSD, OpenBSD, NetBSD, Minix, HP-UX ...
On 9/29/2011 6:24 AM, Kean Johnston wrote:
If you are happy limiting yourself to a single platform and don't need
some the magic that comes with GIO, feel free to use stat(). It's not
UNIXWARE, SCO OpenServer, AIX, Solaris, MacOS X, Windows, Linux,
FreeBSD, OpenBSD, NetBSD, Minix, HP-UX ...
I disagree that we don't have an ABI to maintain on Windows. I think
people on Windows are somewhat likely to download precompiled binary
versions of our DLLs for use with developing their software (since the
build process is so complicated). We can easily introduce extremely
difficult-to-debug
On Mon, 2011-09-26 at 08:59 +0200, Kean Johnston wrote:
There is also a broader issue with stat. The size of struct stat can vary
according to what macros are defined when you include sys/stat.h. If you
have _FILE_OFFSET_BITS=64 defined your size fields are 64-bit, otherwise
they *can* be
On Wed, 2011-09-28 at 10:00 +0200, Kean Johnston wrote:
This means that there is an awful lot of valid existing code (including
within GLib itself) that looks like this:
{
struct stat buf;
g_stat (filename,buf);
}
which (if I understand your proposal correctly) would be
time_t is typically a signed long, which is 64bit on all 64bit linux
versions.
Even more good reason to standardize then.
I don't see what advantages this gives you. It will break all existing
code that uses g_stat and struct stat, you can't share GStatBuf with
other struct stat using code,
Le mercredi 28 septembre 2011 à 11:03 +0200, Kean Johnston a écrit :
Only if you define UNIX as Linux. OSX has other fields Linux doesn't.
Some UNIX variants have 16-bit uid_t's others have 32. Some have as low as
16-bit ino_t's others have 64. There are all KINDS of ways in which it
Do you have a use case where hash-table lookups would be a bottleneck?
Small mobile devices. Devices with only 64MB of RAM to play with. Embedded
devices. Just because GLib is used mainly in GNOME don't make the
assumption its the ONLY place. Not every deployment of GLib applications is
on a
On Wed, Sep 28, 2011 at 10:27 AM, Kean Johnston kean.johns...@gmail.com wrote:
Do you have a use case where hash-table lookups would be a bottleneck?
Small mobile devices. Devices with only 64MB of RAM to play with. Embedded
devices. Just because GLib is used mainly in GNOME don't make the
The problem is that stat is API from the 1970's. None of us really
So is malloc. So is chmod. They are wrapped.
want to prolong the life of code with such readable names as S_IFMT,
S_IFREG, st_blksize and EBADF. One of GIO's design goals was to come
up with a fully portable, modern abstraction
On Wed, 28 Sep 2011 at 11:03:00 +0200, Kean Johnston wrote:
Offering a portable, no-ifdefs-required,
suitably-large-sized-to-accomodate-everyone structure ... yes
*STRUCTURE* that all code can use completely portably without having
to worry about anything ...
... until GLib is ported to
On Wed, 2011-09-28 at 11:03 +0200, Kean Johnston wrote:
So easily solved. Call the damned thing g_statfile() and have the structure
be GFileStat.
So then we would have 'struct stat' and 'GStatBuf' which would work with
g_stat(), g_lstat() and fstat(). Additionally we would add a
'GFileStat'
On 09/26/2011 08:59 AM, Kean Johnston wrote:
Here's how I would define
the GStatBuf data type:
Won't you break ABI if you're changing the layout of the struct on
linux/unixes? As I understand this is not an issue on Windows since
everyone ships the libraries with the binary, but it is on
On 9/27/2011 9:08 AM, Steve Frécinaux wrote:
On 09/26/2011 08:59 AM, Kean Johnston wrote:
Here's how I would define
the GStatBuf data type:
Won't you break ABI if you're changing the layout of the struct on
linux/unixes? As I understand this is not an issue on Windows since
everyone ships the
On Tue, 2011-09-27 at 11:36 +0200, Kean Johnston wrote:
On 9/27/2011 9:08 AM, Steve Frécinaux wrote:
Won't you break ABI if you're changing the layout of the struct on
linux/unixes? As I understand this is not an issue on Windows since
everyone ships the libraries with the binary, but it is
In at least gstdio.c, possibly other places (I am still looking) there is a
lot of code to use the wide versions of various functions like stat,
because it is assumed that the input argument is UTF-8 and the CRT doesn't
support UTF-8 directly but rather Microsoft's own multibyte character set
On Mon, 26 Sep 2011 08:59:29 +0200, Kean Johnston wrote:
So, for stat, we have to do a double conversion: first from the input UTF-8
to UTF-16, and then from UTF-16 to MBCS so that we can call stat instead of
wstat so that users don't get any nasty surprises when using g_stat() on a
Won't that fail on filenames that have characters outside of the active
codepage instead?
Sure but that will actually fail rather than silently succeeding with an
incorrect value.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
2011/9/26 Jernej Simončič jernej|s-gm...@eternallybored.org:
Won't that fail on filenames that have characters outside of the active
codepage instead?
You can use g_win32_locale_filename_from_utf8() to obtain a short
filename (8.3) that will refer to the filename with unrepresentable
2011/9/26 Kean Johnston kean.johns...@gmail.com:
Despire the
coolness of Windows supporting time fields 64-bits wide for the least amount
of pain it would probably be best if the time fields were left at 32-bits
(although it would be really cool and forward thinking if we used 64-bits),
FWIW
On Mon, 26 Sep 2011 14:59:43 +0200, Kean Johnston wrote:
Won't that fail on filenames that have characters outside of the active
codepage instead?
Sure but that will actually fail rather than silently succeeding with an
incorrect value.
But which is more likely to happen - user having a
2011/9/26 Jernej Simončič jernej|s-gm...@eternallybored.org:
But which is more likely to happen - user having a filename with foreign
characters, or user having a symlink (which on Windows can only be created
by administrators)...
Based on the bugs reported against Inkscape that were caused by
But which is more likely to happen - user having a filename with foreign
characters, or user having a symlink (which on Windows can only be created
by administrators)...
You asked the question slightly incorrectly: which is more likely to
happen: a user have a file on their filesystem that
On Mon, 26 Sep 2011 15:25:06 +0200, Kean Johnston wrote:
You asked the question slightly incorrectly: which is more likely to
happen: a user have a file on their filesystem that their system codepage
cannot support or having a symlink. I'd say the latter is more frequent
because every
MBCS isn't able to represent all the characters (though depending on the
codepage, it does cover a fair amount), but that's not really relevant -
how do you represent тест in CP-1250?
Give that to me as a sequence of wchar_t's and I'll figure it out :)
On Mon, 26 Sep 2011 15:45:20 +0200, Kean Johnston wrote:
Give that to me as a sequence of wchar_t's and I'll figure it out :)
It's \u0442\u0435\u0441\u0442.
--
Jernej Simončič http://eternallybored.org/
___
gtk-devel-list mailing list
But which is more likely to happen - user having a filename with foreign
characters, or user having a symlink (which on Windows can only be created
by administrators)...
Are you sure about that (I havent had the time to create a quick
application that tests this) but
2011/9/26 Kean Johnston kean.johns...@gmail.com:
Plus I am
fairly sure (but not 100%) that MBCS can represent all of the characters
UTF-16 can (which is what the _wstat function uses).
MBCS is misleadingly named in Microsoft documentation. It is not
always a multibyte encoding. It is a
On Mon, 26 Sep 2011 15:55:20 +0200, Kean Johnston wrote:
Are you sure about that (I havent had the time to create a quick
application that tests this) but
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363866%28v=vs.85%29.aspx
makes no mention of elevated priveliges. Are you
user. The ordinary user is unlikely to create any symlinks, and I'm
not even sure that _wstat would be called when selecting the linked
file for opening in the file chooser.
Forget about a file chooser. I want to write a utility. I want to be able
to stat files and get their sizes to display how
I'm sure. Open an unelevated command prompt and use the mklink command.
That could be weirdness with the mklink command. I'll write a test using
the actual API's.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
On Mon, 26 Sep 2011 16:11:11 +0200, Kean Johnston wrote:
Forget about a file chooser. I want to write a utility. I want to be able
to stat files and get their sizes to display how many bytes the files in a
directory uses. How do I do that with a broken _wstat? Or, I want to
*write* a file
On Mon, 2011-09-26 at 13:55 +0200, Jernej Simončič wrote:
On Mon, 26 Sep 2011 08:59:29 +0200, Kean Johnston wrote:
So, for stat, we have to do a double conversion: first from the input UTF-8
to UTF-16, and then from UTF-16 to MBCS so that we can call stat instead of
wstat so that users
Couldn't GLib directly use GetFileAttributesExW instead, or does this
Sadly the file attributes constants dont have anything like
FILE_ATTRIBUTE_SYMLINK etc, so we wouldn't be able to determine if the file
is a symbolic link or not. Which I guess would be OK because this is
g_stat() not
On Mon, 26 Sep 2011 16:12:25 +0200, Kean Johnston wrote:
That could be weirdness with the mklink command. I'll write a test using
the actual API's.
It's not - symlinks are intentionally restricted to administrators to
prevent the security issues they would introduce in applications predating
It's not - symlinks are intentionally restricted to administrators to
prevent the security issues they would introduce in applications predating
symlink support.
Ah ok cool, useful information, thank you!
___
gtk-devel-list mailing list
On Mon, 2011-09-26 at 19:11 +0200, Kean Johnston wrote:
Couldn't GLib directly use GetFileAttributesExW instead, or does this
Sadly the file attributes constants dont have anything like
FILE_ATTRIBUTE_SYMLINK etc, so we wouldn't be able to determine if the file
is a symbolic link or not.
FWIW I'm in favor of 64 bit time fields, as the event horizon for
32-bit fields is only 27 years away. Even if you think that it's very
unlikely that any present day programs will still be used in 27 years,
you can think of this as enabling Unix timestamp calculations with
dates much further into
50 matches
Mail list logo
