Michael Havens wrote:
> why does deleting a file move it to .Trash but not make the space available
> for reuse?
Because, as already said, as far as the filesystem is concerned it's still a
file taking up space.
Longer answer: I guess you are using a "desktop" interface, click the file, and
;t control.
Personally, I always use computers that I control and I use OwnCloud
to keep such files in sync.
On 09/23/2015 02:29 PM, Michael Havens wrote:
> I don't have the technical knowledge to bring this idea into the
> real world but: What do you think about adding a tar/zip option?
I don't have the technical knowledge to bring this idea into the real world
but:
What do you think about adding a tar/zip option? I like to rsync my
/Documents directory and as i was doing so this morning my pen drive ran
out of room. I only ever make minor changes to /Documents and someti
On 11.02.2015 14:03, QUBE RUBBIK wrote:
> Hello
>
> I was just thinking about a killer feature for rsync, the ability to detect
> files name changes or move within the source and destination.
> At this time rsync has to re-transfer a file if it has been renamed or moved
> inside a subfolder, wit
I haven't used it yet, but take a look at --fuzzy specified once or
twice. I think it does what you want or at least something very similar.
Joe
On 02/11/2015 09:03 AM, QUBE RUBBIK wrote:
> Hello
>
> I was just thinking about a killer feature for rsync, the ability to
> detect files name changes
Hello
I was just thinking about a killer feature for rsync, the ability to detect
files name changes or move within the source and destination.
At this time rsync has to re-transfer a file if it has been renamed or moved
inside a subfolder, with a heavy waste of ressources and bandwidth.
It cou
I probably won't be implementing this, but since I've thought of it,
I thought I'd share.
Give rsync an option like --resumption-file=[file]
Let's say you've done:
rsync -a --resumption-file=foo a/ b/ c/
rsync starts by putting "a/" and "b/" in foo. It then gets the
listing for a/, and repl
https://bugzilla.samba.org/show_bug.cgi?id=4383
devz...@web.de changed:
What|Removed |Added
CC||devz...@web.de
--- Comment #2 from
https://bugzilla.samba.org/show_bug.cgi?id=2296
devz...@web.de changed:
What|Removed |Added
CC||devz...@web.de
--- Comment #2 from
I have been thinking this would be a nice feature: exclude files by
type rather than just regular expressions. Mostly because binaries
don't have any extension on Linux, so they aren't recognizable just by
name. At work I rsync a source directory for doing builds in a chroot
environment for the t
)
rsync error: error in rsync protocol data stream (code 12) at
io.c(189)
Any idea to avoid it?
Thanks,
Jignesh
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http
https://bugzilla.samba.org/show_bug.cgi?id=4383
[EMAIL PROTECTED] changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from
https://bugzilla.samba.org/show_bug.cgi?id=4383
Summary: Idea: Store files in compressed format and visa versa
Product: rsync
Version: 3.0.0
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Have you considered using a traditional network filesystem instead of
putting together your own system on top of rsync? I think AFS (the
Andrew File System) supports the kind of replication you want.
Matt
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before
Recently, I have investigated FUSE as an option for implementing something
like I proposed to this list in April, 2005 (instead of inotify).
Just yesterday, I submitted some patches to the mysqlfs-general mailing
list that improve mysqlfs a bit. With a little more work (which I may or
may not do)
Recently, I have investigated FUSE as an option for implementing something
like I proposed to this list in April, 2005 (instead of inotify).
Just yesterday, I submitted some patches to the mysqlfs-general mailing
list that improve mysqlfs a bit. With a little more work (which I may or
may not do)
On Fri, Jun 10, 2005 at 04:15:42PM -0400, Moshe Jacobson wrote:
> Instead, I think would be nice to add a flag e.g. --detect-moved-dirs,
> which would compare the file listing for each side, and look for whole
> directory trees that seem to be moved since last rsync.
This is the enhancement sugges
Hi (Wayne? Not sure who did --fuzzy),
Like many people, I use rsync with hard linking to keep multiple
backups of my data in a relatively small space on the server.
I like the idea behind --fuzzy, but it seems that in most cases, this
option doesn't help me much.
Instead, I think wou
On 4/12/05, Lester Hightower wrote:
> The actual replication happens in user-land with rsync as the transport.
> I think rsync will have to be tweaked a little to make this work, but
> given all the features already in rsync I don't think this will be a big
> deal. I envision an rsync running on
ll not be replicated to other systems.
> The Constant Replicator design appeals to me because it more closely
> mirrors my needs, and has fewer "scarey black boxes" in the design.
> However, the more I have thought about what is really going on here, the
> more I am convinced
mkdir( ... ), rmdir( ... )
I implemented such a beast in terms of a LD_PRELOAD library that
intercepts these calls (as well as a whole lot others that may update
time information). Unfortunately, this was proprietary and I don't have
access to the sources. However, I've done that, the idea
Interesting ideas.
> I envision the "VFS Change Logger" as a (hopefully very thin) middle-ware
> that sits between the kernel's VFS interfaces and a real filesystem, like
> ext3, reiser, etc. The "VFS Change Logger" will pass VFS calls to the
> underlying filesystem driver, but it will make note
s come somewhat close to the Inter-Mezzo filesystem
for Linux, which was at one time in the mainline kernel, but some time
ago dropped because it wasn't being maintained. Their approach, I think,
is too focused on standards and openness, rather than making something
that works. Maybe your id
t
resulted from the ensuing discussion and code improvements were so
consequential that I dared not post again until I felt I had another topic
worthy of the time and consideration of this superb group.
This idea might be a little far fetched, but if so I guess that means that
I am just ignorant
|P5
Version|2.6.3 |2.6.4
--- Additional Comments From [EMAIL PROTECTED] 2005-02-12 14:44 ---
I'm not that enamored with this idea, but I'll leave this open as a place-holder
for future consideration.
--
Configure bugm
https://bugzilla.samba.org/show_bug.cgi?id=2296
Summary: Idea: transparently uncompress .gz and .bz2 files before
synchronizing.
Product: rsync
Version: 2.6.3
Platform: All
OS/Version: Linux
Status: NEW
On Sun, Sep 19, 2004 at 07:54:47AM -0600, Sean Reifschneider wrote:
> My thought is that it could be implemented fairly inexpensively by
> mostly relying on the temporary files that are already written. If the
> temp files were given a common extension (even if it were just common
> among a concur
ularly during low usage periods where I might be able to get much
more than that from a fast site. Yeah, I know I could change the mirror
I'm using, but there aren't many push-primaries. That's what gave me
the idea.
Sean
--
I hear a cow jack-knifed on the Harley Memorial Bridge.
unlinks the old one
first, leaving the original hard-linked file untouched. At least that's
how it works on Solaris. I also just tested a rename(2) on Linux and it
does the same thing.
Regarding your idea of --also-using, try to work up a patch and see how
it works. I suppose you'd want
On Tue, 10 Apr 2001 [EMAIL PROTECTED] wrote:
> From: Anthony Rumble <[EMAIL PROTECTED]>
> >
> > On Tue, 10 Apr 2001 [EMAIL PROTECTED] wrote:
> >
> > > You don't have to .. just create a hard link .. rsync will break the link
> > > if the transfer completes.
> >
> > Umm.. Hang on.. no.. it woul
From: Anthony Rumble <[EMAIL PROTECTED]>
>
> On Tue, 10 Apr 2001 [EMAIL PROTECTED] wrote:
>
> > You don't have to .. just create a hard link .. rsync will break the link
> > if the transfer completes.
>
> Umm.. Hang on.. no.. it would modify the same file.. and thus.. truncate
> it.. if it abor
On Tue, 10 Apr 2001 [EMAIL PROTECTED] wrote:
> From: Anthony Rumble <[EMAIL PROTECTED]>
> >
> > I am oten doing something like this
> >
> > cp something-beta-1.iso something-beta-2.iso
> >
> > Then rsync --progress --partial --stats --block-size=8192
> > somewhere::blah/something-beta-2.iso
From: Anthony Rumble <[EMAIL PROTECTED]>
>
> I am oten doing something like this
>
> cp something-beta-1.iso something-beta-2.iso
>
> Then rsync --progress --partial --stats --block-size=8192
> somewhere::blah/something-beta-2.iso .
>
> When I want to go from beta-1 to beta-2.. and usuall
I am oten doing something like this
cp something-beta-1.iso something-beta-2.iso
Then rsync --progress --partial --stats --block-size=8192
somewhere::blah/something-beta-2.iso .
When I want to go from beta-1 to beta-2.. and usually.. if all goes well..
this works..
HOWEVER..
A).. I hate
tes for top n directories/files
3) --nosetperms-pattern=patt: Ditto by by pattern using --exclude symantics
4) (implicit) if target ends in / then don't touch anything before the
slash (not current behaviour)
or even:
1a) --umask-top=umask: bitwise-AND umask with source flags for top target
dire
35 matches
Mail list logo
