similar to: [LLVMdev] [PATCH] sys::fs::can_read() and sys::fs::can_write() for Unix

I'm not sure that this fix is really correct. An alternate way I can think to fix this would be for the core server to maintain a readonly flag for each layer (instead of just per- server). You could also argue that our readonly test in server/connections.c:compute_eflags is wrong and/or that the implementations of server/plugins.c:plugin_can_write and server/filters.c:filter_can_write have

Using ‘nbdkit --filter=xz file disk.xz’ and loop mounting eventually results in this error: nbdkit: file[1]: debug: xz: pwrite count=4096 offset=1048576 flags=0x0 nbdkit: file[1]: debug: pwrite count=4096 offset=1048576 fua=0 nbdkit: file[1]: error: pwrite: Bad file descriptor nbdkit: file[1]: debug: sending error reply: Bad file descriptor Since the filter did not intercept can_write, it was

Hello, We are having a problem with linker lookup on Windows. When the driver tries to locate a program by its name, e.g. a linker, it scans the paths provided by the toolchain using ScanDirForExecutable and then, if fails, uses llvm::sys::findProgramByName, which on Windows searches the CWD and system path. ScanDirForExecutable disregards file extensions, so search in the toolchain-provided

This is a subset of the last half of the larger 9-patch series. The uncontroversial first half of that series is pushed, but here, I tried to reduce the size of the patches by splitting out some of the more complex changes, so that the rest of the changes remaining in the series are more mechanical. In turn, it forced me to write timing tests, which let me spot another spot where we are wasting

> It looks like OS X always has TMPDIR set these days (to the value of > _CS_DARWIN_USER_TEMP_DIR), so I think we should just go with TMPDIR if it's > set and non-empty, and then fall back to confstr. However, we should not be > using TMPDIR if ErasedOnReboot is false (i.e. if we'd prefer > _CS_DARWIN_USER_CACHE_DIR). Unfortunately there's no canonical environment >

> Well, that changes behavior on Linux; previously it did honor TMPDIR when > looking for a cache directory. Is that okay? (The Windows version is also > honoring TEMP in this case.) I *think* that is a bug fix. I don't have those env variables set on my linux machine (fedora 20), but I don't remember seeing them pointing to anything but /tmp in the past and that is even in

I have a few concerns: 1. GetTempPathW is buggy, we should be manually using GetEnvironmentVariableW with TMP, TEMP and USERPROFILE arguments and use the first that exists. 2. We should make sure that the platform specific pieces live in their respective Path.inc files. On Thu, Jul 24, 2014 at 9:44 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On

On Jul 25, 2014, at 13:44 , Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 25 July 2014 16:31, David Majnemer <david.majnemer at gmail.com> wrote: >> I have a few concerns: >> 1. GetTempPathW is buggy, we should be manually using >> GetEnvironmentVariableW with TMP, TEMP and USERPROFILE arguments and use the >> first that exists. >> 2. We

On 25 July 2014 17:57, David Majnemer <david.majnemer at gmail.com> wrote: > To be clear, I don't think we need both; I'd like for us to drop one of > them. I just want to make sure that that the final state, post merge, works > well on all of our platforms. :) Cool. The attached patch removes TempDir. It passes all tests, but the OS X case looks a bit suspicious. I first

Hi, all. I noticed recently that llvm::sys::fs::createTemporaryFile does not use llvm::sys::path::system_temp_directory, instead relying on its platform-specific helper TempFile. Is there any reason for this disparity? The two implementations are not in sync, either: - TempDir honors TMPDIR, TMP, TEMP, TEMPDIR, and a configuration-settable P_tmpdir on Unix-y systems. system_temp_directory just

Hi Greg, The following two patches move /sys/o2cb into /sys/fs/o2cb as we previously discussed. A symlink is created to maintain compatibility with existing versions of ocfs2-tools. A patch to automatically search /sys/fs/o2cb has been committed to the ocfs2-tools repo and a release with that code shouldn't be too far out. Old versions of ocfs2-tools have been tested and work fine with the

Hi, sys::fs::create_directories() recurses infinitely for relative paths with only one directory or where the first directory in path doesn't exist. This was observed in r153176. Example: #include <llvm/Support/FileSystem.h> using namespace llvm; int main(int argc, char *argv[]) { bool existed; error_code ec = sys::fs::create_directories(Twine("log"), existed);

Hi, sys::fs::create_directories() recurses infinitely for relative paths with only one directory or where the first directory in path doesn't exist. This was observed in r153176. Example: #include <llvm/Support/FileSystem.h> using namespace llvm; int main(int argc, char *argv[]) { bool existed; error_code ec = sys::fs::create_directories(Twine("log"), existed);

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, as the subject says, I was just wondering where the implementation of sys::fs::canonicalize() might be. The function is declared in llvm/Support/FileSystem.h, but I couldn't find its implementation within lib/Support. Consequently, any application using this function doesn't link. Am I missing something here? Regards, Mario -----BEGIN

On 19 July 2012 09:10, Mario Schwalbe <mario at se.inf.tu-dresden.de> wrote: > as the subject says, I was just wondering where the implementation of > sys::fs::canonicalize() might be. Looks like it got implemented, then reverted due to buildbot breakage, and never re-committed: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111212/133222.html Jay.

I get this during booting? Anyone have any ideas? I'm running redhat 7.1 w/ kernel 2.4.9-6 and the wine version from the powertools cd. Latest version of wine does it also. I get this error when installing from redhat powertools too: "execution of %post scriplet from wine 20010131-3 failed, exit status1" but it installs and seems to work... just my windows service doesn't

On Tuesday 28 January 2014 16:21:09 Richard W.M. Jones wrote: > Commit 72afcf450a78b7e58f65b4a7aaf94d71cd25fca5 was partially > incorrect. If the guest userspace is expecting /selinux to exist, > then we should bind-mount /sys/fs/selinux from the appliance kernel > there. > --- > daemon/command.c | 16 +++++++++++++--- > 1 file changed, 13 insertions(+), 3 deletions(-) >

Hi I allready have set 256 on max_user_instances , and in the log i keep seeing Mar 28 10:08:44 mail dovecot: imap(some.username): Warning: Inotify instance limit for user 98 (UID vmail) exceeded, disabling. Increase /proc/sys/fs/inotify/max_user_instances All users use thunderbird 3.1.9 , and from time to time this show in log , with a random user. What can i do to resolve this issue ? my

llvm::sys::fs::make_absolute converts its first parameter (const Twine &current_directory) to StringRef p(path.data(), path.size()), and then passes that StringRef to several functions (path::has_root_directory, path::has_root_name, and path::append) that accept Twines as parameters. Since llvm::StringRef can implicitly convert to an llvm::Twine, p converts to a bunch of Twine temporaries. In

Commit 72afcf450a78b7e58f65b4a7aaf94d71cd25fca5 was partially incorrect. If the guest userspace is expecting /selinux to exist, then we should bind-mount /sys/fs/selinux from the appliance kernel there. --- daemon/command.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/daemon/command.c b/daemon/command.c index 1aa1a52..939bf87 100644 --- a/daemon/command.c