Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #123196 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2017-11-21 11:50 -0800 |
| Last post | 2017-11-22 16:36 +0000 |
| Articles | 20 on this page of 82 — 15 participants |
Back to article view | Back to comp.lang.c
[sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 11:50 -0800
Re: [sot] file times / file metadata "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-21 21:05 +0100
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-22 09:15 +1300
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 12:23 -0800
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 12:42 -0800
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 13:01 -0800
Re: [sot] file times / file metadata "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-21 22:04 +0100
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 13:17 -0800
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 13:22 -0800
Re: [sot] file times / file metadata "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-21 23:23 +0100
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-22 11:34 +1300
Re: [sot] file times / file metadata Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-11-21 17:34 -0500
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 16:16 -0800
Re: [sot] file times / file metadata "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-22 01:44 +0100
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-22 14:10 +1300
Re: [sot] file times / file metadata gordonb.eiy78@burditt.org (Gordon Burditt) - 2017-11-28 01:55 -0600
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-22 11:07 +0100
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-22 09:13 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-22 15:50 +0100
Re: [sot] file times / file metadata jameskuyper@verizon.net - 2017-11-22 07:08 -0800
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-22 16:22 +0100
Re: [sot] file times / file metadata bartc <bc@freeuk.com> - 2017-11-22 15:37 +0000
Re: [sot] file times / file metadata bartc <bc@freeuk.com> - 2017-11-22 15:43 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-22 15:01 -0500
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-23 17:52 +1300
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-23 14:12 -0500
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-24 08:28 +1300
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-24 08:52 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-23 09:39 +0100
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-23 14:17 -0500
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-28 16:44 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-28 14:23 -0500
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-28 19:35 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-30 15:54 -0500
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-30 21:43 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 11:42 -0500
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-12-04 19:35 +0000
Re: [sot] file times / file metadata Keith Thompson <kst-u@mib.org> - 2017-12-04 11:53 -0800
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-12-04 20:11 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 15:03 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-11-28 19:42 +0000
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-28 20:13 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-30 15:57 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-11-30 21:17 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 11:56 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-12-04 18:36 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 15:07 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-12-04 22:27 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 17:57 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-12-05 08:50 +0100
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-05 08:49 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-12-05 15:17 +0100
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-05 16:32 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-12-05 15:29 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-05 16:37 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-12-06 01:26 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-06 12:38 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-12-06 01:27 +0000
Re: [sot] file times / file metadata jameskuyper@verizon.net - 2017-11-28 09:35 -0800
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-29 08:24 +1300
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-29 08:27 +1300
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-28 14:29 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-29 09:51 +0100
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-30 15:59 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-29 10:00 +0100
Re: [sot] file times / file metadata "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-29 09:11 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-29 15:28 +0100
Re: [sot] file times / file metadata "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-29 11:32 -0500
Re: [sot] file times / file metadata James Kuyper <jameskuyper@verizon.net> - 2017-11-23 15:05 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-24 10:20 +0100
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-24 09:05 -0500
Re: [sot] file times / file metadata Robert Wessel <robertwessel2@yahoo.com> - 2017-11-24 22:50 -0600
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-28 16:59 +0000
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-29 08:26 +1300
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-29 10:10 +0100
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-29 21:01 +0000
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-29 23:13 +0100
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-30 17:26 +0000
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-22 08:00 -0800
Re: [sot] file times / file metadata "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-22 17:11 +0100
Re: [sot] file times / file metadata "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-22 16:51 +0100
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-11-22 16:36 +0000
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-11-22 16:22 +0100 |
| Message-ID | <ov44np$s9$1@dont-email.me> |
| In reply to | #123300 |
On 22/11/17 16:08, jameskuyper@verizon.net wrote: > On Wednesday, November 22, 2017 at 9:50:23 AM UTC-5, David Brown > wrote: >> On 22/11/17 15:13, Jerry Stuckle wrote: >>> On 11/22/2017 5:07 AM, David Brown wrote: >>>> On 21/11/17 22:04, Pascal J. Bourguignon wrote: >>>>> fir <profesor.fir@gmail.com> writes: >>>>> >>>>>> note yet i made some test that was copyying file in total >>>>>> comender and the result is a bit discussable >>>>>> >>>>>> >>>>>> - when i copied file the old one file changed acces time to >>>>>> current (though i was not opening it only copying) >>>>> >>>>> Think about it! >>>>> >>>>> How would YOU copy the file if not by opening it and reading >>>>> it? >>>>> >>>>> (There is an answer, and once you find it, you'll >>>>> understand why it's not provided, and why you have to open >>>>> the file and read it to copy it). >>>>> >>>> >>>> I can think of ways to copy a file without reading it. In >>>> fact, I regularly make copies of my entire filesystems without >>>> reading them. >>>> >>>> >>> >>> I would love to see how you copy a file or filesystem without >>> reading it. >>> >> >> Google "btrfs snapshots", "zfs snapshots" or "lvm snapshots". All >> of these make logical copies of files without actually reading or >> writing any data. > > <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup> > describes them as "COW" snapshots. I assume that "COW" stands for > "copy on write" - which means the snapshot is only some kind of alias > for the original file. Actual file copying only takes place when > either the original or one of the aliases gets written to - and that > copying does in fact involve reading the original file before writing > the copy. Correct. It is a logical copy, and to anything accessing the file it makes no difference. You can get the same effect with just "cp file1 file2" on btrfs - except that obviously makes real changes to the directory and metadata, and snapshots work almost instantaneously for entire filesystems or subvolumes. Whether the original data ever gets read or not will depend on what you later do with the copy or the original. If you make a copy, then re-write or delete the original, then the logical copy was made without ever reading the original file. Is it /really/ copying a file? I suppose that depends on your definition of "copy a file". It's a bit like wondering if a ten pound note is really money - after all, it only says "I promise to pay the bearer on demand the sum of ten pounds". A btrfs copy is perhaps just a /promise/ to make a copy on demand, rather than a real copy. But it looks like a copy and acts like a copy - it is only the time taken for the copy that is delayed. If Pascal was thinking of something different when he wrote "I can think of ways to copy a file without reading it", I would be curious to know what it was. > >> You can also go the other way - make physical copies of the data >> without making logical copies, and perhaps also without even having >> the data pass through the main cpu. This happens in raid systems. >> > > The data might not pass through the main cpu, but something still > reads the original file before writing the copy - otherwise, how > would it know what to write to the copy? > Yes, physical copying of the data means the data must be read off the first disk and written to the second disk. But there is no logical copying - no user-visible copy, no changes to metadata, creation times, directories, etc.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-11-22 15:37 +0000 |
| Message-ID | <zQgRB.14715$by1.4639@fx24.am4> |
| In reply to | #123301 |
On 22/11/2017 15:22, David Brown wrote: > On 22/11/17 16:08, jameskuyper@verizon.net wrote: >> The data might not pass through the main cpu, but something still >> reads the original file before writing the copy - otherwise, how >> would it know what to write to the copy? >> > > Yes, physical copying of the data means the data must be read off the > first disk and written to the second disk. But there is no logical > copying - no user-visible copy, no changes to metadata, creation times, > directories, etc. >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-11-22 15:43 +0000 |
| Message-ID | <aWgRB.46141$U41.870@fx07.am4> |
| In reply to | #123301 |
On 22/11/2017 15:22, David Brown wrote: [Note to myself: pressing 'Send' is not the same as the 'Back' button on a browser.] > Is it /really/ copying a file? I suppose that depends on your > definition of "copy a file". It's a bit like wondering if a ten pound > note is really money - after all, it only says "I promise to pay the > bearer on demand the sum of ten pounds". A btrfs copy is perhaps just a > /promise/ to make a copy on demand, rather than a real copy. But it > looks like a copy and acts like a copy - it is only the time taken for > the copy that is delayed. > > If Pascal was thinking of something different when he wrote "I can think > of ways to copy a file without reading it", I would be curious to know > what it was. Perhaps he meant copying without going through the usual channels. Such as copying the raw data off a drive a track at a time. Or taking a file system on a DVD and copying the whole thing optically in one go (I doubt individual movie DVDs are produced by serially writing data to each DVD. Not official ones anyway.) Copying a specific file however, and nothing else, you may need to go through the file system, or understand it enough to bypass the usual APIs. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-11-22 15:01 -0500 |
| Message-ID | <ov4l1f$v6e$1@jstuckle.eternal-september.org> |
| In reply to | #123300 |
On 11/22/2017 10:08 AM, jameskuyper@verizon.net wrote: > On Wednesday, November 22, 2017 at 9:50:23 AM UTC-5, David Brown wrote: >> On 22/11/17 15:13, Jerry Stuckle wrote: >>> On 11/22/2017 5:07 AM, David Brown wrote: >>>> On 21/11/17 22:04, Pascal J. Bourguignon wrote: >>>>> fir <profesor.fir@gmail.com> writes: >>>>> >>>>>> note yet i made some test that was >>>>>> copyying file in total comender and the result is a bit discussable >>>>>> >>>>>> >>>>>> - when i copied file the old one file changed acces time to current >>>>>> (though i was not opening it only copying) >>>>> >>>>> Think about it! >>>>> >>>>> How would YOU copy the file if not by opening it and reading it? >>>>> >>>>> (There is an answer, and once you find it, you'll understand why it's >>>>> not provided, and why you have to open the file and read it to copy it). >>>>> >>>> >>>> I can think of ways to copy a file without reading it. In fact, I >>>> regularly make copies of my entire filesystems without reading them. >>>> >>>> >>> >>> I would love to see how you copy a file or filesystem without reading it. >>> >> >> Google "btrfs snapshots", "zfs snapshots" or "lvm snapshots". All of >> these make logical copies of files without actually reading or writing >> any data. > > <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup> describes them as "COW" snapshots. I assume that "COW" stands for "copy on write" - which means the snapshot is only some kind of alias for the original file. Actual file copying only takes place when either the original or one of the aliases gets written to - and that copying does in fact involve reading the original file before writing the copy. > You've got it. If you make a copy of something, the copy should still exist when the original is destroyed - i.e. the disk is reformatted or whatever. David's "copy" does not do that. >> You can also go the other way - make physical copies of the data without >> making logical copies, and perhaps also without even having the data >> pass through the main cpu. This happens in raid systems. > > The data might not pass through the main cpu, but something still reads the original file before writing the copy - otherwise, how would it know what to write to the copy? > Exactly. But David doesn't understand the difference, obviously. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-11-23 17:52 +1300 |
| Message-ID | <f7n2gbF1omrU5@mid.individual.net> |
| In reply to | #123322 |
On 11/23/2017 09:01 AM, Jerry Stuckle wrote: > > You've got it. If you make a copy of something, the copy should still > exist when the original is destroyed - i.e. the disk is reformatted or > whatever. David's "copy" does not do that. If you take a snapshot (with ZFS) and delete the original file, the "copy" in the snapshot is still there. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-11-23 14:12 -0500 |
| Message-ID | <ov76it$jv2$2@jstuckle.eternal-september.org> |
| In reply to | #123351 |
On 11/22/2017 11:52 PM, Ian Collins wrote: > On 11/23/2017 09:01 AM, Jerry Stuckle wrote: > >> >> You've got it. If you make a copy of something, the copy should still >> exist when the original is destroyed - i.e. the disk is reformatted or >> whatever. David's "copy" does not do that. > > If you take a snapshot (with ZFS) and delete the original file, the > "copy" in the snapshot is still there. > And how do you "take a snapshot" without reading the file? What happens if you reformat the disk the original file is on? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-11-24 08:28 +1300 |
| Message-ID | <f7olqiF1omrU9@mid.individual.net> |
| In reply to | #123389 |
On 11/24/2017 08:12 AM, Jerry Stuckle wrote: > On 11/22/2017 11:52 PM, Ian Collins wrote: >> On 11/23/2017 09:01 AM, Jerry Stuckle wrote: >> >>> >>> You've got it. If you make a copy of something, the copy should still >>> exist when the original is destroyed - i.e. the disk is reformatted or >>> whatever. David's "copy" does not do that. >> >> If you take a snapshot (with ZFS) and delete the original file, the >> "copy" in the snapshot is still there. >> > > And how do you "take a snapshot" without reading the file? zfs snapshot filesystem@name > What happens if you reformat the disk the original file is on? The same thing that happens if you made a local copy? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-11-24 08:52 -0500 |
| Message-ID | <ov9870$q1k$1@jstuckle.eternal-september.org> |
| In reply to | #123392 |
On 11/23/2017 2:28 PM, Ian Collins wrote: > On 11/24/2017 08:12 AM, Jerry Stuckle wrote: >> On 11/22/2017 11:52 PM, Ian Collins wrote: >>> On 11/23/2017 09:01 AM, Jerry Stuckle wrote: >>> >>>> >>>> You've got it. If you make a copy of something, the copy should still >>>> exist when the original is destroyed - i.e. the disk is reformatted or >>>> whatever. David's "copy" does not do that. >>> >>> If you take a snapshot (with ZFS) and delete the original file, the >>> "copy" in the snapshot is still there. >>> >> >> And how do you "take a snapshot" without reading the file? > > zfs snapshot filesystem@name > >> What happens if you reformat the disk the original file is on? > > The same thing that happens if you made a local copy? > Who said anything about a local copy? And I can make a "local copy" to a different partition on the same disk and nuke the original partition. Does your zfs snapshot do that? Or it can make a "local copy" to a second disk on the same machine then remove the original disk? Nope in either case, because it is not a copy. You're as stoopid as David! -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-11-23 09:39 +0100 |
| Message-ID | <ov61fa$dgk$1@dont-email.me> |
| In reply to | #123322 |
On 22/11/17 21:01, Jerry Stuckle wrote: > On 11/22/2017 10:08 AM, jameskuyper@verizon.net wrote: >> On Wednesday, November 22, 2017 at 9:50:23 AM UTC-5, David Brown wrote: >>> On 22/11/17 15:13, Jerry Stuckle wrote: >>>> On 11/22/2017 5:07 AM, David Brown wrote: >>>>> On 21/11/17 22:04, Pascal J. Bourguignon wrote: >>>>>> fir <profesor.fir@gmail.com> writes: >>>>>> >>>>>>> note yet i made some test that was >>>>>>> copyying file in total comender and the result is a bit discussable >>>>>>> >>>>>>> >>>>>>> - when i copied file the old one file changed acces time to current >>>>>>> (though i was not opening it only copying) >>>>>> >>>>>> Think about it! >>>>>> >>>>>> How would YOU copy the file if not by opening it and reading it? >>>>>> >>>>>> (There is an answer, and once you find it, you'll understand >>>>>> why it's >>>>>> not provided, and why you have to open the file and read it to >>>>>> copy it). >>>>>> >>>>> >>>>> I can think of ways to copy a file without reading it. In fact, I >>>>> regularly make copies of my entire filesystems without reading them. >>>>> >>>>> >>>> >>>> I would love to see how you copy a file or filesystem without >>>> reading it. >>>> >>> >>> Google "btrfs snapshots", "zfs snapshots" or "lvm snapshots". All of >>> these make logical copies of files without actually reading or writing >>> any data. >> >> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup> describes >> them as "COW" snapshots. I assume that "COW" stands for "copy on >> write" - which means the snapshot is only some kind of alias for the >> original file. Actual file copying only takes place when either the >> original or one of the aliases gets written to - and that copying does >> in fact involve reading the original file before writing the copy. >> > > You've got it. If you make a copy of something, the copy should still > exist when the original is destroyed - i.e. the disk is reformatted or > whatever. David's "copy" does not do that. Nor does the "cp" command in *nix, or "copy" command in Windows. Format the disk containing the original and the copy of the file, and both are gone. If you "copy" the file to another disk, then your office burns down, both the original and copy are gone. See? Others can play stupid games too. With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices with such features, you can /delete/ the original and the copy is still there. That is, at heart, what most people think of as "making a copy". > >>> You can also go the other way - make physical copies of the data without >>> making logical copies, and perhaps also without even having the data >>> pass through the main cpu. This happens in raid systems. >> >> The data might not pass through the main cpu, but something still >> reads the original file before writing the copy - otherwise, how would >> it know what to write to the copy? >> > > Exactly. But David doesn't understand the difference, obviously. > Of course I understand it. I just don't have the same obsession with trying to tell people they are wrong as you do.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-11-23 14:17 -0500 |
| Message-ID | <ov76re$mi5$1@jstuckle.eternal-september.org> |
| In reply to | #123358 |
On 11/23/2017 3:39 AM, David Brown wrote: > On 22/11/17 21:01, Jerry Stuckle wrote: >> On 11/22/2017 10:08 AM, jameskuyper@verizon.net wrote: >>> On Wednesday, November 22, 2017 at 9:50:23 AM UTC-5, David Brown wrote: >>>> On 22/11/17 15:13, Jerry Stuckle wrote: >>>>> On 11/22/2017 5:07 AM, David Brown wrote: >>>>>> On 21/11/17 22:04, Pascal J. Bourguignon wrote: >>>>>>> fir <profesor.fir@gmail.com> writes: >>>>>>> >>>>>>>> note yet i made some test that was >>>>>>>> copyying file in total comender and the result is a bit discussable >>>>>>>> >>>>>>>> >>>>>>>> - when i copied file the old one file changed acces time to current >>>>>>>> (though i was not opening it only copying) >>>>>>> >>>>>>> Think about it! >>>>>>> >>>>>>> How would YOU copy the file if not by opening it and reading it? >>>>>>> >>>>>>> (There is an answer, and once you find it, you'll understand >>>>>>> why it's >>>>>>> not provided, and why you have to open the file and read it to >>>>>>> copy it). >>>>>>> >>>>>> >>>>>> I can think of ways to copy a file without reading it. In fact, I >>>>>> regularly make copies of my entire filesystems without reading them. >>>>>> >>>>>> >>>>> >>>>> I would love to see how you copy a file or filesystem without >>>>> reading it. >>>>> >>>> >>>> Google "btrfs snapshots", "zfs snapshots" or "lvm snapshots". All of >>>> these make logical copies of files without actually reading or writing >>>> any data. >>> >>> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup> describes >>> them as "COW" snapshots. I assume that "COW" stands for "copy on >>> write" - which means the snapshot is only some kind of alias for the >>> original file. Actual file copying only takes place when either the >>> original or one of the aliases gets written to - and that copying does >>> in fact involve reading the original file before writing the copy. >>> >> >> You've got it. If you make a copy of something, the copy should still >> exist when the original is destroyed - i.e. the disk is reformatted or >> whatever. David's "copy" does not do that. > > Nor does the "cp" command in *nix, or "copy" command in Windows. Format > the disk containing the original and the copy of the file, and both are > gone. > Yes, both the *nix cp and Windows copy commands make duplicates of the file. You can delete the original and the copy will remain. > If you "copy" the file to another disk, then your office burns down, > both the original and copy are gone. > > See? Others can play stupid games too. > Then you have destroyed both the original and the copy. Completely different - but you're too stoopid to understand that. And you refuse to admit you are wrong (again). > With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices > with such features, you can /delete/ the original and the copy is still > there. That is, at heart, what most people think of as "making a copy". > What is not making a copy of a file. That is making a duplicate on write. Or creating a symbolic link, in which case destroying the original destroys the link. >> >>>> You can also go the other way - make physical copies of the data without >>>> making logical copies, and perhaps also without even having the data >>>> pass through the main cpu. This happens in raid systems. >>> >>> The data might not pass through the main cpu, but something still >>> reads the original file before writing the copy - otherwise, how would >>> it know what to write to the copy? >>> >> >> Exactly. But David doesn't understand the difference, obviously. >> > > Of course I understand it. I just don't have the same obsession with > trying to tell people they are wrong as you do. > > > You've shown you have no idea what you're talking about (again). And yes, you do have an obsession trying to tell people they are wrong - as you are doing in this thread. Stoopid idiots are like that. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2017-11-28 16:44 +0000 |
| Message-ID | <ovk3qa$9cc$1@reader2.panix.com> |
| In reply to | #123390 |
In article <ov76re$mi5$1@jstuckle.eternal-september.org>, Jerry Stuckle <jstucklex@attglobal.net> wrote: >> With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices >> with such features, you can /delete/ the original and the copy is still >> there. That is, at heart, what most people think of as "making a copy". > >What is not making a copy of a file. That is making a duplicate on >write. Or creating a symbolic link, in which case destroying the >original destroys the link. No, that's not how it works. Creating a COW snapshot of a filesystem is nothing at all like creating a symbolic link. Explaining it to Stuckle is a waste of time, but this needs to be said in case someone reads this and thinks his otherwise-unrebutted point is correct. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-11-28 14:23 -0500 |
| Message-ID | <ovkd3j$b6v$1@jstuckle.eternal-september.org> |
| In reply to | #123570 |
On 11/28/2017 11:44 AM, Dan Cross wrote: > In article <ov76re$mi5$1@jstuckle.eternal-september.org>, > Jerry Stuckle <jstucklex@attglobal.net> wrote: >>> With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices >>> with such features, you can /delete/ the original and the copy is still >>> there. That is, at heart, what most people think of as "making a copy". >> >> What is not making a copy of a file. That is making a duplicate on >> write. Or creating a symbolic link, in which case destroying the >> original destroys the link. > > No, that's not how it works. Creating a COW snapshot of a > filesystem is nothing at all like creating a symbolic link. > > Explaining it to Stuckle is a waste of time, but this needs to > be said in case someone reads this and thinks his > otherwise-unrebutted point is correct. > > - Dan C. > Until the file is modified, it is exactly like a symbolic link. There is only one copy of the file on the disk, and if something happens to that copy the file is lost. When the file changes, the original is read and a copy made. But not until then. But trying to explain the facts to Cross is a waste of time. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2017-11-28 19:35 +0000 |
| Message-ID | <ovkdpr$olo$1@reader2.panix.com> |
| In reply to | #123579 |
In article <ovkd3j$b6v$1@jstuckle.eternal-september.org>, Jerry Stuckle <jstucklex@attglobal.net> wrote: >On 11/28/2017 11:44 AM, Dan Cross wrote: >> In article <ov76re$mi5$1@jstuckle.eternal-september.org>, >> Jerry Stuckle <jstucklex@attglobal.net> wrote: >>> What is not making a copy of a file. That is making a duplicate on >>> write. Or creating a symbolic link, in which case destroying the >>> original destroys the link. >> >> No, that's not how it works. Creating a COW snapshot of a >> filesystem is nothing at all like creating a symbolic link. >> >> Explaining it to Stuckle is a waste of time, but this needs to >> be said in case someone reads this and thinks his >> otherwise-unrebutted point is correct. > >Until the file is modified, it is exactly like a symbolic link. There >is only one copy of the file on the disk, and if something happens to >that copy the file is lost. > >When the file changes, the original is read and a copy made. But not >until then. Nope. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-11-30 15:54 -0500 |
| Message-ID | <ovpr67$p0i$1@jstuckle.eternal-september.org> |
| In reply to | #123584 |
On 11/28/2017 2:35 PM, Dan Cross wrote: > In article <ovkd3j$b6v$1@jstuckle.eternal-september.org>, > Jerry Stuckle <jstucklex@attglobal.net> wrote: >> On 11/28/2017 11:44 AM, Dan Cross wrote: >>> In article <ov76re$mi5$1@jstuckle.eternal-september.org>, >>> Jerry Stuckle <jstucklex@attglobal.net> wrote: >>>> What is not making a copy of a file. That is making a duplicate on >>>> write. Or creating a symbolic link, in which case destroying the >>>> original destroys the link. >>> >>> No, that's not how it works. Creating a COW snapshot of a >>> filesystem is nothing at all like creating a symbolic link. >>> >>> Explaining it to Stuckle is a waste of time, but this needs to >>> be said in case someone reads this and thinks his >>> otherwise-unrebutted point is correct. >> >> Until the file is modified, it is exactly like a symbolic link. There >> is only one copy of the file on the disk, and if something happens to >> that copy the file is lost. >> >> When the file changes, the original is read and a copy made. But not >> until then. > > Nope. > > - Dan C. > That's what copy on write is, Dan. But we already know your head is so far up your arse tat you can see your tonsils. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2017-11-30 21:43 +0000 |
| Message-ID | <ovpu2b$joa$1@reader2.panix.com> |
| In reply to | #123650 |
In article <ovpr67$p0i$1@jstuckle.eternal-september.org>, Jerry Stuckle <jstucklex@attglobal.net> wrote: >>> Until the file is modified, it is exactly like a symbolic link. There >>> is only one copy of the file on the disk, and if something happens to >>> that copy the file is lost. >>> >>> When the file changes, the original is read and a copy made. But not >>> until then. >> >> Nope. > >That's what copy on write is, Dan. But we already know your head is so >far up your arse tat you can see your tonsils. Nope. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-12-04 11:42 -0500 |
| Message-ID | <p03ttv$cnq$1@jstuckle.eternal-september.org> |
| In reply to | #123655 |
On 11/30/2017 4:43 PM, Dan Cross wrote: > In article <ovpr67$p0i$1@jstuckle.eternal-september.org>, > Jerry Stuckle <jstucklex@attglobal.net> wrote: >>>> Until the file is modified, it is exactly like a symbolic link. There >>>> is only one copy of the file on the disk, and if something happens to >>>> that copy the file is lost. >>>> >>>> When the file changes, the original is read and a copy made. But not >>>> until then. >>> >>> Nope. >> >> That's what copy on write is, Dan. But we already know your head is so >> far up your arse tat you can see your tonsils. > > Nope. > > - Dan C. > ROFLMAO! What an intelligent response - NOT! Why do you think it is called COPY ON WRITE? A copy is not made until something is written to the file. Until that time, you basically have a symlink to the file. However, I also know that concept is beyond your limited ability to comprehend. I also know both you and David are good at making up your own meanings for words, despite what the rest of the world agrees on. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2017-12-04 19:35 +0000 |
| Message-ID | <p0481o$1gb$1@reader2.panix.com> |
| In reply to | #123807 |
In article <p03ttv$cnq$1@jstuckle.eternal-september.org>, Jerry Stuckle <jstucklex@attglobal.net> wrote: >On 11/30/2017 4:43 PM, Dan Cross wrote: >> In article <ovpr67$p0i$1@jstuckle.eternal-september.org>, >> Jerry Stuckle <jstucklex@attglobal.net> wrote: >>>>> Until the file is modified, it is exactly like a symbolic link. There >>>>> is only one copy of the file on the disk, and if something happens to >>>>> that copy the file is lost. >>>>> >>>>> When the file changes, the original is read and a copy made. But not >>>>> until then. >>>> >>>> Nope. >>> >>> That's what copy on write is, Dan. But we already know your head is so >>> far up your arse tat you can see your tonsils. >> >> Nope. > >ROFLMAO! What an intelligent response - NOT! > >Why do you think it is called COPY ON WRITE? A copy is not made until >something is written to the file. Until that time, you basically have a >symlink to the file. Nope. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-04 11:53 -0800 |
| Message-ID | <lnd13uuv5e.fsf@kst-u.example.com> |
| In reply to | #123820 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <p03ttv$cnq$1@jstuckle.eternal-september.org>,
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
[SNIP]
>
> Nope.
>
> - Dan C.
Dan, those of us who have killfiled Jerry Stuckle would prefer not to
see his writings quoted in other articles.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2017-12-04 20:11 +0000 |
| Message-ID | <p04a5v$ogc$1@reader2.panix.com> |
| In reply to | #123822 |
In article <lnd13uuv5e.fsf@kst-u.example.com>, Keith Thompson <kst-u@mib.org> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >> In article <p03ttv$cnq$1@jstuckle.eternal-september.org>, >> Jerry Stuckle <jstucklex@attglobal.net> wrote: >[SNIP] >> >> Nope. >> > >Dan, those of us who have killfiled Jerry Stuckle would prefer not to >see his writings quoted in other articles. Fair enough, Keith. Sorry for the noise. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-12-04 15:03 -0500 |
| Message-ID | <p049lu$amr$2@jstuckle.eternal-september.org> |
| In reply to | #123820 |
On 12/4/2017 2:35 PM, Dan Cross wrote: > In article <p03ttv$cnq$1@jstuckle.eternal-september.org>, > Jerry Stuckle <jstucklex@attglobal.net> wrote: >> On 11/30/2017 4:43 PM, Dan Cross wrote: >>> In article <ovpr67$p0i$1@jstuckle.eternal-september.org>, >>> Jerry Stuckle <jstucklex@attglobal.net> wrote: >>>>>> Until the file is modified, it is exactly like a symbolic link. There >>>>>> is only one copy of the file on the disk, and if something happens to >>>>>> that copy the file is lost. >>>>>> >>>>>> When the file changes, the original is read and a copy made. But not >>>>>> until then. >>>>> >>>>> Nope. >>>> >>>> That's what copy on write is, Dan. But we already know your head is so >>>> far up your arse tat you can see your tonsils. >>> >>> Nope. >> >> ROFLMAO! What an intelligent response - NOT! >> >> Why do you think it is called COPY ON WRITE? A copy is not made until >> something is written to the file. Until that time, you basically have a >> symlink to the file. > > Nope. > > - Dan C. > ROFLMAO! And other "intelligent" response that shows you have no idea what you're talking about. But that's Dan for you. All mouth and no brain. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web