search for: ofd

...<getopt.h> #include <pthread.h> +#include <linux/falloc.h> #include <lzma.h> #define DEBUG 0 @@ -145,10 +146,11 @@ usage (int exitcode) static void xzfile_uncompress (const char *filename, const char *outputfile, unsigned nr_threads) { int fd, ofd; + off_t hole_start, data_start; uint64_t size; lzma_index *idx; /* Open the file. */ fd = open (filename, O_RDONLY); @@ -176,10 +178,29 @@ xzfile_uncompress (const char *filename, const char *outputfile, posix_fadvise (fd, 0, 0, POSIX_FADV_RANDOM|POSIX_FADV_DONTNEED); /* Itera...

If the source and destination file are identical, the receiving scp truncates the file. On the sending end, read() returns 0, and garbage is sent instead of actual data, and the receiving end puts it into the file, which at least confuses the users. -- Florian Weimer Florian.Weimer at RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/

On Sat, Aug 06, 2016 at 03:43:48AM +0000, Eric Wong wrote: > Eric Wong <e at 80x24.org> wrote: > > I'm trying to test a trivial patch to set FD_CLOEXEC on the > > flintlock lockfd when using F_OFD_SETLK > > Fwiw, this is the patch I was originally going to test. > (but now I see maybe my F_SETFD might only need to be > called on F_OFD_SETLK success) Description at bottom. > > --- a/backends/flint_lock.cc > +++ b/backends/flint_lock.cc > @@ -108,6 +108,10 @@ Flint...

...+#define _GNU_SOURCE #include <config.h> #include <stdio.h> #include <stdlib.h> #include <string.h> @@ -166,12 +167,12 @@ xzfile_uncompress (const char *filename, const char *outputfile, debug ("uncompressed size = %" PRIu64 " bytes", size); ofd = open (outputfile, O_WRONLY|O_CREAT|O_TRUNC|O_NOCTTY, 0644); if (ofd == -1) error (EXIT_FAILURE, errno, "open: %s", outputfile); - if (ftruncate (ofd, size) == -1) - error (EXIT_FAILURE, errno, "ftruncate: %s", outputfile); + if (fallocate (ofd, 0, 0, size) == -1)...

...t;config.h> > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > @@ -166,12 +167,12 @@ xzfile_uncompress (const char *filename, const > char *outputfile, > debug ("uncompressed size = %" PRIu64 " bytes", size); > ofd = open (outputfile, O_WRONLY|O_CREAT|O_TRUNC|O_NOCTTY, 0644); > if (ofd == -1) > error (EXIT_FAILURE, errno, "open: %s", outputfile); > - if (ftruncate (ofd, size) == -1) > - error (EXIT_FAILURE, errno, "ftruncate: %s", outputfile); > + if (fallocate...

...rr("%s: %s", name, strerror(haderr)); - (void) response(); + if (response() == 0 && eraseflag && !haderr) { + if (unlink(name) < 0) + run_err("%s: %s", name, strerror(errno)); + } } } @@ -656,7 +679,7 @@ int amt, count, exists, first, mask, mode, ofd, omode; off_t size; int setimes, targisdir, wrerrno = 0; - char ch, *cp, *np, *targ, *why, *vect[1], buf[2048]; + char ch, *cp, *np, *targ, *dest, *why, *vect[1], buf[2048]; struct timeval tv[2]; #define atime tv[0] @@ -770,6 +793,7 @@ np = namebuf; } else np = targ; + dest = *t...

...np = targ; curfile = cp; - exists = stat(np, &stb) == 0; + exists = (buf[0] == 'L' ? lstat : stat)(np, &stb) == 0; if (buf[0] == 'D') { int mod_flag = pflag; @@ -845,9 +869,14 @@ sink(argc, argv) continue; } - omode = mode; - mode |= S_IWRITE; - if ((ofd = open(np, O_WRONLY | O_CREAT | O_TRUNC, mode)) < 0) { -bad: run_err("%s: %s", np, strerror(errno)); - continue; + if (buf[0] == 'L') + ofd = omode = -1; + else { + omode = mode; + mode |= S_IWRITE; + if ((ofd = open(np, O_WRONLY | O_CREAT | O_TRUNC, + mode))...

More posix_fadvise stuff, and document what Linux really does with these calls. Also fixes a nasty bug in virt-builder. Rich.

I'm trying to test a trivial patch to set FD_CLOEXEC on the flintlock lockfd when using F_OFD_SETLK and am running into a build failure even in an unpatched state. This is on a Debian jessie amd64 system building the jessie-backports version. The stable version (1.2.19-1+deb8u1) works and builds fine using the same commands, however I also encountered a similar build problem in a sid chro...

The way we used posix_fadvise was wrong, and yet right! Rich.

On Thu, 25 Feb 2016 23:37:52 +0000, Olly Betts <olly at survex.com> wrote: > On Thu, Feb 25, 2016 at 05:21:17PM +0100, Eric J wrote: > > On Thu, 25 Feb 2016 02:24:51 +0000, Olly Betts <olly at survex.com> wrote: > > > It's clearly not as simple as execl() always releasing the lock, but I > > > don't think we've ruled out the OS entirely yet - the

...+ rsync-2.6.1/util.c 2004-04-27 19:15:29.000000000 +0300 @@ -29,6 +29,7 @@ extern int verbose; extern struct exclude_list_struct server_exclude_list; +extern int do_fsync; int sanitize_paths = 0; @@ -281,8 +282,22 @@ int copy_file(char *source, char *dest, } } - close(ifd); - close(ofd); + if (close(ifd) != 0) { + rprintf(FINFO, "close failed on %s: %s\n", + source, strerror(errno)); + } + + if (do_fsync && (fsync(ofd) != 0)) { + rprintf(FERROR, "fsync failed on %s: %s\n", + dest, strerror(errno)); + return -1; + } + + if (close(ofd) != 0) { +...

Hello - I am making a first attempt at writing a simple C++ routine to print out R objects (this is a simple proof-of-concept as part of a larger package development). The relevant C++ routine is as follows: void Rwrite(SEXP fd, SEXP msg) { int *ofd = INTEGER(fd); const char * omsg = CHAR(asChar(msg)); printf("[%i] %s",*ofd,omsg); } And the corresponding interface in R is as follows: ptest <- function() { cfd <- as.integer(2); cmsg <- as.character("Hi"); storage.mode(cfd) <- "integer&quo...

...; i += bp->cnt) { amt = bp->cnt; if (i + amt > stb.st_size) amt = stb.st_size - i; @@ -572,6 +652,26 @@ if (result != amt) haderr = result >= 0 ? EIO : errno; } + + if (rate_limit) { + if (bcounter >= rate_limit / 2) { + (void) gettimeofday(&now, (struct timezone *) 0); + timersub(&now, &lastupdate, &wait); + + sleep_time = ((double)(bcounter / (rate_limit + * (double)(wait.tv_usec / 1000000.0)) - 0) + * (double)wait.tv_usec); + if (sleep_time < 0) + sleep_time = 0; + +...

...tmp.db: already locked [1]+ Stopped examples/simpleindex tmp.db so it is presumably not anything to do with the FS or the OS. I am hoping that the right Tcl person (whoever that is) may pick something up in an strace. > More recent Xapian versions will try to use the new OFD locks and avoid > the need to fork() and execl(), so will presumably avoid whatever is > going on here. But the OFD locks were added in Linux 3.15, so your > kernel isn't quite new enough. Yes, I saw that, and it is good, but my chances of moving up soon are not good. And I would lik...

On Sun, 21 Feb 2016 22:33:22 +0000, Olly Betts <olly at survex.com> wrote: > On Sun, Feb 21, 2016 at 02:15:25PM +0100, Eric J wrote: > > I discovered, while trying to set up Tcl bindings for Notmuch > > (https://notmuchmail.org/), which uses Xapian, that flintlock was not > > being locked (I had lost updates). > > It seems to work for me, testing with this: >

...n; + /* move tmp file over real file */ if (robust_rename(fnametmp,fname) != 0) { if (errno == EXDEV) { diff -ur rsync/util.c rsync-backuponly/util.c --- rsync/util.c 2003-07-02 06:45:31.000000000 +0900 +++ rsync-backuponly/util.c 2003-09-02 16:06:44.000000000 +0900 @@ -268,18 +268,23 @@ ofd = do_open(dest, O_WRONLY | O_CREAT | O_TRUNC | O_EXCL, mode); if (ofd == -1) { - rprintf(FERROR,"open %s: %s\n", - dest,strerror(errno)); - close(ifd); + int saveerrno = errno; + if (verbose > 2) + rprintf(FERROR,"open %s: %s\n", + dest,strerror(errno)); + clos...

...munix2 I suspect that this problem is also present on other OS's, but at the moment, I have confirmed it only on HP systems. Running tusc on an "scp -t" process shows that ftruncate is being called no matter what. In sink() in file scp.c, we can see: if (ftruncate(ofd, size)) { run_err("%s: truncate: %s", np, strerror(errno)); wrerr = DISPLAYED; } This code fragment should be enclosed in this if condition: if(wrerr == NO){ if (ftruncate(ofd, size)) {...

...e you running this on? Is use of Tcl actually a factor here, or can you reproduce it with just C++ code? E.g. using the "simpleindex" example from the xapian-core sources: examples/simpleindex tmp.db & examples/simpleindex tmp.db More recent Xapian versions will try to use the new OFD locks and avoid the need to fork() and execl(), so will presumably avoid whatever is going on here. But the OFD locks were added in Linux 3.15, so your kernel isn't quite new enough. Cheers, Olly

...-O2 `xapian-config --cxxflags --libs` doubleopen.cc And then run: ./a.out If locking is working, this should fail (and does for me) like so: terminate called after throwing an instance of 'Xapian::DatabaseLockError' Aborted > > More recent Xapian versions will try to use the new OFD locks and avoid > > the need to fork() and execl(), so will presumably avoid whatever is > > going on here. But the OFD locks were added in Linux 3.15, so your > > kernel isn't quite new enough. > > Yes, I saw that, and it is good, but my chances of moving up soon are...