similar to: rsync's internal "virtual file system"

Can someone explain to me what is happening here: ~ $ touch foo ~ $ ln foo bar ~ $ ls foo bar bar foo ~ $ mv foo bar ~ $ ls foo bar bar foo I try to move a file over a hard linked copy of itself and the move fails, but there is no error. Is this the intended behavior? -- Ben Escoto

Hi, I am thinking about a non-standard usage of rsync (at least not mentioned in the man file) I want to synchronized my collegues home directories(trees) each night AND store rsync's internal updating commands (reversed) to be able to restore the state of a directory the day before. This would require - saving the internal updating commands in a separate directory - reversing these commands

A while back, I asked if there had been any consideration in making rsync support direct ssl (as opposed to just ssh). I've been looking around for a secure way (e.g. encrypted, so passwords are never in the clear, and even content is obscured from sniffers) to allow a set of limited-trust users (limited-trust being defined as mostly customers, whom you trust with their own data, but not with

If I want to make sure a file has really been deleted do I have to: 1. fsync the file 2. fsync the directory the file is in 3. both? Much thanks. -- Ben Escoto

Hi, can someone tell me whether applications can expect the write requests they make to be executed in order? For instance, suppose an application requests that a file be deleted, and then that another file be moved to an unrelated place. Will these events always happen in that order? Or to put it another way, if something unexpected happens in the meantime (say the computer crashes), is it

Hey, Greg suggested that I take a straw poll. Should cAos take steps to prevent getting stuck with a big ISP bill in the future? For example, should cAos: a) for new installs, have the yum.conf point to public mirrors, rather than to mirror.caosity.org? b) make sure that "yum update" does not substitute a new yum.conf file that points only to mirror.caosity.org? c) allow public

Hey folks, As you may be aware if you've been watching llvm-commits, I've been working recently on improving the ability to use LLVM across multiple threads. While the goal for now is to be able to hack on multiple Module's in parallel, this has necessitated a larger review of how LLVM interacts with threads. In a recent(-ish) patch, I added a new API:

With the recent OS changes (windows 2000) necessitated by various worms, etc, I have now been receiving this error message when I run update and I am not sure how I can correct. >update.packages() >trying URL `http://cran.r-project.org/bin/windows/contrib/PACKAGES' Error in download.file(url = paste(contriburl, "PACKAGES", sep = "/"), : cannot open: HTTP

Greetings folks. I had really wanted out-of-tree folks to be able to make only a single change to their code due to the new pass manager; essentially, by the time they had to touch the code at all I wanted them to be able to port completely to the new pass manager. However, Richard has raised the issue that this is nearly impossible to make work with C++ modules, and we've lost the modules

On Tue, Jan 20, 2015 at 3:55 PM, H. Peter Anvin <hpa at zytor.com> wrote: > On 01/20/2015 12:17 PM, Andreas Gruenbacher wrote: >> On 01/20/2015 09:13 PM, H. Peter Anvin wrote: >>> I can't remember, but I have a vague recollection that someone >>> specifically requested that EACCES be treated the same as ENOENT... >> >> If that is really necessary

Hi Jonas, > I am investigating the possibilities of incorporating fixed point support into > the LLVM I/R. I think you should write a rationale explaining why you want to introduce new types etc rather than using the existing integer types, with intrinsic functions for the operations, or some other such scheme. Introducing new types is hard work and creates a maintenance burden for

Building with MinGW-w64 GCC 5.3.0 via Makefile.lite, I get the following warnings: bitwriter.c: In function 'FLAC__bitwriter_write_utf8_uint64': bitwriter.c:324:19: warning: inlining failed in call to 'FLAC__bitwriter_write_raw_uint32.constprop': --param large-function-growth limit reached [-Winline] inline FLAC__bool FLAC__bitwriter_write_raw_uint32(FLAC__BitWriter *bw,

On Wednesday 20 September 8:56 pm, Alex Jones wrote: > I think the consequences outweigh the benefits. Having metadata at the > beginning of the file serves as metadata and gives you important > information such as expected stream length. Pushing this to the back for > the sake of making tag updates quicker seems a bit of a bad move to me - > how often do you re-tag your files?

[moving this thread to nut-upsdev] On Jan 12, 2008 5:54 PM, Alexander I. Gordeev <lasaine at lvk.cs.msu.su> wrote: > On Sun, 13 Jan 2008 01:30:37 +0300, Charles Lepple <clepple at gmail.com> > wrote: > > when you figure this out, can we make sure that we know which > > changesets would need to be back-ported to branches/Testing (since > > that is where we would

[moving this thread to nut-upsdev] On Jan 12, 2008 5:54 PM, Alexander I. Gordeev <lasaine at lvk.cs.msu.su> wrote: > On Sun, 13 Jan 2008 01:30:37 +0300, Charles Lepple <clepple at gmail.com> > wrote: > > when you figure this out, can we make sure that we know which > > changesets would need to be back-ported to branches/Testing (since > > that is where we would

On 5 February 2013 11:03, David Tweed <david.tweed at arm.com> wrote: > since the more instructions there > are the more an out-of-order CPU can put them into otherwise unused slots. > I > can't think of a way of figuring out such a mapping other than empirically. > Given the amount of uncertainty on these OOO guesses, I don't think we can get anything worth trying,

I've looking into the possibility of using rsync for mirroring where we are currently using iOra. It looks like iOra has two main advantages over rsync: 1) can calculate deltas across multiple files (i.e., blocks common to two files will only appear once in the delta) 2) can de-couple delta calculation and application (creates deltas offline) I'm pretty sure I can emulate (1) by

I have a VPS account with 256MB guaranteed RAM. I am running it as Apache1.3 -> Pen -> mongrel_cluster (with 2 mongrel servers). "top" shows 2 "ruby" instances (I guess for both of the mongrel servers), each weighing in at about 25MB. Does that sound about right? If you are using 2 mongrel servers per client app, does that mean that each RoR app needs 50MB+

On Wed, Jul 12, 2023 at 10:52?AM Jani Nikula <jani.nikula at intel.com> wrote: > > On Wed, 12 Jul 2023, Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > > Hello, > > > > while I debugged an issue in the imx-lcdc driver I was constantly > > irritated about struct drm_device pointer variables being named "dev" > > because with

On Wed, Jul 12, 2023 at 10:52?AM Jani Nikula <jani.nikula at intel.com> wrote: > > On Wed, 12 Jul 2023, Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > > Hello, > > > > while I debugged an issue in the imx-lcdc driver I was constantly > > irritated about struct drm_device pointer variables being named "dev" > > because with