similar to: File access from within a DLL

While using the file functions have found a few more issues (on both Unix and Windows) ie R documentation: In the "close" description (base package) we see that the possible values for the mode 'open' the "r+" and "r+b" values are repeated, and are incorrect the second time. The second set actually corresponds to the "w+" / "w+b", see

Have searched through the archives but have been unable to find any related issues - hopefully I'm not bringing up an old topic. Am using RW1041 on a Windows NT on a machine with 1Gb of memory. Have a function doit() that reads in a chunk of data using readBin, performs a regression, saves out coeffs and then returns. When using Rgui with the default memory limit of 256Mb I'm able to

Hi, Seems that on RWin 1.7.0 and 1.6.2 isSeekable returns F on binary files, while seek() works as expected on the same connection - see example below: > con = file(nm, "rb") > isSeekable(con) [1] FALSE > readBin(con, double(), 10) [1] 7.263824e-317 5.968155e-317 2.340685e-317 2.734062e-312 4.088386e-312 4.670335e-317 [7] 6.097545e-317 3.396341e-312 6.615484e-317

I've been running rsync-2.4.2 with an old patch of mine for some time for backup purposes. Due to the recent remote bug, I thought it was time to upgrade, even if the host was behind a firewall. So I dug up the old patch (2.5.2 version attached), that I think I sent ages ago to this list as well. It does the following: (1) Firstly, the only sensible way to run something as

Hi, I've been running out of memory while using the lm.fit function - have solved the problem and thought there might be interest in incorporating some of the changes. Looked at the source and changed the following lines storage.mode(x) <- "double" storage.mode(y) <- "double" z <- .Fortran("dqrls", qr = x, n = n, p = p, y = y, ny = ny,

On Thu, Jun 27, 2013 at 11:29:28PM +0200, Daniel Gillen wrote: > Hi > > As my cross platform registry editor (FRED available from > https://www.pinguin.lu (sorry for advertising but I couldn't resist > ;-))) is evolving, I recently added write support to it. > > While under Linux everything worked nice, the Windblows build didn't. > > It seems that Windows

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. Anyone have an example of an MD4 collision so I can test that case? :) Patch Summary: -1 +1 Makefile.in -0 +304 hashlink.c (new)

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. (rev 3) * Don't link empty files. * Roll over to new file when filesystem maximum link count is reached. * If link fails for another reason, leave

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. (rev 2) * This revision is actually against CVS HEAD (I didn't realize I was working from a stale rsync'd CVS). * Apply permissions after

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. (rev 4) * Updated for committed robust_rename() patch, other changes in CVS. (rev 3) * Don't link empty files. * Roll over to new file when

This patch adds the --link-by-hash=DIR option, which hard links received files in a link farm arranged by MD4 file hash. The result is that the system will only store one copy of the unique contents of each file, regardless of the file's name. (rev 5) * Fixed silly logic error. (rev 4) * Updated for committed robust_rename() patch, other changes in CVS. (rev 3) * Don't link empty

Hi, Here is the problem (syscall.c, function do_open) on NT, Win2K, WinXP, with stripped "/" for UNC path convention, detected in release 2.5.5, 2.5.6: int do_open(char *pathname, int flags, mode_t mode) { if (flags != O_RDONLY) { if (dry_run) return -1; CHECK_RO } #ifdef O_BINARY /* for Windows */ flags |= O_BINARY; #endif /* some systems can't handle a double / */

Hiya. While merging the 2.6.0 changes into our modified version of rsync, I noticed the following bit of code in 2.6.0's options.c: extern int sanitize_paths; if (sanitize_paths) sanitize_path(strdup(files_from), NULL); filesfrom_fd = open(files_from, O_RDONLY|O_BINARY); Since sanitize_path modifies its first argument in place, the path that open()

Hello, This is my first time posting to this list. I think I might have found a bug, but I am not sure, so I appreciate any thought you may have. I am running rsync 3.2.0dev from Git master revision 916faecb with the copy-devices patch from rsync-patches master revision f22e220b on Debian 10 and I used the Debian build system to build rsync. I am running the following command: alpha# rsync

Hello, R version 2.4.1 (2006-12-18) i386-pc-mingw32 Calling serialize() with a NULL connection serializes it to a raw vector. However, when the object to be serialized is large, it takes a very long time: > system.time( serialize(matrix(0, 1000, 1000), NULL) ) [1] 38.25 40.73 81.54 NA NA > system.time( serialize(matrix(0, 2000, 2000), NULL) ) [1] 609.72 664.75 1318.57 NA

Hi, since the previous port of OpenSSH to Cygwin, there's happened a lot with Cygwin. We have worked hard to allow a more smooth porting of UNIX applications which results in two major advantages: - There's no need to use so called `text mode' in open calls anymore. - With only less interventions in the applications code the concept of real and effective uid's is supported

No point of using it on a unixish OS. Signed-off-by: maximilian attems <max at stro.at> --- usr/utils/cpio.c | 10 ++-------- 1 files changed, 2 insertions(+), 8 deletions(-) diff --git a/usr/utils/cpio.c b/usr/utils/cpio.c index 6891883..15134b9 100644 --- a/usr/utils/cpio.c +++ b/usr/utils/cpio.c @@ -31,10 +31,6 @@ #include <fnmatch.h> #endif -#ifndef O_BINARY -# define

I would like to use readBin to read a binary data file. Most of the data is 4-byte floating point but, for some reason, only double precision appears to be offered. I tried fVariable=readBin(iFile,what=single()); and got 35.87879 which looks believable except that the correct value is 3.030303. I then tried fVariable=readBin(iFile,what=single(),4); and got [1] 3.831111e+10 6.657199e+10

The underscores are wrong. The comment is also correct. Also remove the configure.ac option. Otherwise it tries to compile the windows unicode stuff which POSIX(cygwin) does not understand. --- configure.ac | 2 +- include/share/compat.h | 2 +- src/libFLAC/stream_decoder.c | 3 --- src/libFLAC/stream_encoder.c | 3 --- src/share/grabbag/file.c | 8 +------- 5 files

Ville Herva [mailto:vherva@niksula.hut.fi] wrote: > Of course, whether O_TEXT is defined or not does not > necessarily imply the availability of "t", but I > can't think of better alternative. Stratus VOS implements O_TEXT and O_BINARY but does not recognize "t". We have the options defined in ANS C and in POSIX. I'm at home and don't have my reference