Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.mac.system > #106786 > unrolled thread
| Started by | Nelson <nelson@nowhere.com> |
|---|---|
| First post | 2017-05-13 14:27 -0400 |
| Last post | 2017-05-19 09:46 +1200 |
| Articles | 20 on this page of 207 — 15 participants |
Back to article view | Back to comp.sys.mac.system
Could Mac Files be Ransomwared via Windows XP Running in a VM? Nelson <nelson@nowhere.com> - 2017-05-13 14:27 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-13 21:08 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-05-13 17:40 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-13 22:21 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Your Name <YourName@YourISP.com> - 2017-05-14 11:07 +1200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? gtr <xxx@yyy.zzz> - 2017-05-13 18:52 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Davoud <star@sky.net> - 2017-05-13 22:20 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? gtr <xxx@yyy.zzz> - 2017-05-13 19:38 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-13 22:56 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Nelson <nelson@nowhere.com> - 2017-05-14 09:11 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Your Name <YourName@YourISP.com> - 2017-05-14 15:42 +1200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 05:23 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? gtr <xxx@yyy.zzz> - 2017-05-14 11:00 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 19:17 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-14 12:40 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 19:51 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-14 13:00 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-14 16:52 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? gtr <xxx@yyy.zzz> - 2017-05-14 16:12 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-15 01:43 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 22:03 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-14 16:04 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 23:11 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-14 16:30 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 23:55 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? super70s <super70s@super70s.invalid> - 2017-05-15 08:25 -0500
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Tim Streater <timstreater@greenbee.net> - 2017-05-15 14:26 +0100
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-15 09:38 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-15 16:14 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Your Name <YourName@YourISP.com> - 2017-05-16 09:06 +1200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-15 17:11 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-15 14:21 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-15 21:25 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-15 14:32 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 00:01 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Your Name <YourName@YourISP.com> - 2017-05-16 09:35 +1200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-15 17:40 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-15 14:52 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-15 17:55 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 00:08 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-16 09:45 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-16 13:56 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? android <here@there.was> - 2017-05-16 20:36 +0200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-16 14:38 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? android <here@there.was> - 2017-05-16 21:05 +0200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 20:28 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? android <here@there.was> - 2017-05-17 05:48 +0200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-16 23:53 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? android <here@there.was> - 2017-05-17 06:10 +0200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-17 00:12 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? android <here@there.was> - 2017-05-17 06:48 +0200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 00:09 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-17 10:24 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-17 15:00 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 08:57 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-17 12:41 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 09:47 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-17 12:50 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 09:53 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 00:09 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-16 17:44 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-16 21:05 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-16 18:09 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Your Name <YourName@YourISP.com> - 2017-05-17 13:26 +1200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-16 21:35 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-17 02:04 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 18:59 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? android <here@there.was> - 2017-05-16 21:07 +0200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 20:28 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 18:20 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-16 17:41 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-17 02:04 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-16 19:14 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-16 22:46 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-16 19:51 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-16 23:41 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 09:00 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-17 12:41 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 09:45 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-17 12:50 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 09:53 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-17 13:06 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 10:31 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-17 16:43 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 15:41 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-17 18:49 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 15:56 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-18 00:43 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 21:51 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-18 01:05 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 22:14 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-18 01:46 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-17 22:55 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-18 21:50 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-18 16:23 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-19 00:16 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-19 14:55 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-19 18:33 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-19 15:39 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-19 19:08 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-19 16:28 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-19 19:32 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-19 16:45 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-19 20:05 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-19 17:10 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-20 15:04 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-20 09:33 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-20 16:43 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-20 16:45 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-20 09:47 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-20 17:08 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-22 15:21 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-22 06:31 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-22 15:23 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-23 09:32 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-23 10:50 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-23 21:15 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-23 16:06 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-18 21:47 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-18 16:19 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-19 00:13 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-19 01:20 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 00:05 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-16 09:45 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-16 13:56 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Nelson <nelson@nowhere.com> - 2017-05-16 14:32 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-16 17:40 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 18:06 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-16 15:30 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 23:50 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-16 17:38 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-17 02:00 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-16 19:16 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-05-15 18:50 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 00:09 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-05-15 20:12 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 00:16 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-15 20:20 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 23:17 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-14 16:32 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-14 19:42 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-15 00:04 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-15 01:36 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 23:32 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 23:33 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? gtr <xxx@yyy.zzz> - 2017-05-14 16:14 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 23:57 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? gtr <xxx@yyy.zzz> - 2017-05-14 17:00 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-15 00:16 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-15 01:39 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-15 03:14 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Nelson <nelson@nowhere.com> - 2017-05-15 11:39 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-15 17:01 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Tim Streater <timstreater@greenbee.net> - 2017-05-14 21:16 +0100
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-14 13:25 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-15 01:53 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 22:10 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-14 16:05 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 23:49 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 23:50 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? gtr <xxx@yyy.zzz> - 2017-05-14 16:16 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-15 00:01 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? gtr <xxx@yyy.zzz> - 2017-05-14 17:37 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-15 01:00 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-15 01:50 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-15 03:20 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-15 05:23 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-15 15:11 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-14 16:52 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-14 14:05 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-14 17:27 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 22:18 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-14 16:08 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 23:53 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-14 16:02 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-14 19:26 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 22:14 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-14 16:08 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-14 23:51 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Nelson <nelson@nowhere.com> - 2017-05-15 11:25 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-15 16:48 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Nelson <nelson@nowhere.com> - 2017-05-15 19:26 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 00:15 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Nelson <nelson@nowhere.com> - 2017-05-16 04:52 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 14:30 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-15 20:20 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-16 04:28 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Nelson <nelson@nowhere.com> - 2017-05-16 05:02 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-16 14:32 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Baker <alangbaker@telus.net> - 2017-05-16 17:39 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-17 22:14 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? nospam <nospam@nospam.invalid> - 2017-05-16 11:55 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2017-05-17 22:13 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Your Name <YourName@YourISP.com> - 2017-05-16 09:09 +1200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? "Andre G. Isaak" <agisaak@gm.invalid> - 2017-05-14 13:35 -0600
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Tim Streater <timstreater@greenbee.net> - 2017-05-14 21:18 +0100
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Your Name <YourName@YourISP.com> - 2017-05-15 10:07 +1200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2017-05-14 17:04 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? gtr <xxx@yyy.zzz> - 2017-05-14 16:20 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Jolly Roger <jollyroger@pobox.com> - 2017-05-15 00:46 +0000
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? gtr <xxx@yyy.zzz> - 2017-05-14 23:47 -0700
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? dempson@actrix.gen.nz (David Empson) - 2017-05-14 11:40 +1200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? dempson@actrix.gen.nz (David Empson) - 2017-05-14 14:41 +1200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Browne <alan.browne@freelunchvideotron.ca> - 2017-05-15 13:13 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Your Name <YourName@YourISP.com> - 2017-05-18 14:21 +1200
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Alan Browne <alan.browne@freelunchvideotron.ca> - 2017-05-18 09:18 -0400
Re: Could Mac Files be Ransomwared via Windows XP Running in a VM? Your Name <YourName@YourISP.com> - 2017-05-19 09:46 +1200
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2017-05-19 16:28 -0700 |
| Message-ID | <ofnv2d$417$3@news.datemas.de> |
| In reply to | #107056 |
On 2017-05-19 4:08 PM, nospam wrote: > In article <ofns7k$uhe$1@news.datemas.de>, Alan Baker > <alangbaker@telus.net> wrote: > >>>>>>>>>> >>>>>>> >>>>>>>> And you imagine that the OS can't sort out which install followed which >>>>>>>> because of the order of files ON DISK? >>>>>>> >>>>>>> Are you seriously claiming that the order of installation should >>>>>>> magically apply to the permissions? >>>>> >>>>>> No. Where do you get that? >>>>> >>>>> " >>>>> someone> except there is no way to know *which* bom file will come up >>>>> last, so >>>>> >>>>> you>Sure there is: >>>>> >>>>> you> The date created." >>>> >>>> Sorry. I didn't say that well. >>>> >>>> The BOM files themselves contain information on the modification date of >>>> each file installed, so it is easy to determine which supersedes which. >>> >>> no it isn't easy at all. >>> >>> you're *assuming* that a bom with a later date should supersede one >>> with an earlier date. that's not a good assumption at all. >> >> No. "Not a BOM with a later date". > > then what metric are you going to use to resolve conflicts? > > previously, you said a later version fixes the mistakes of an earlier > version. to me, that says 'date'. Yes. But a BOM files CONTAINS the dates of the files that were installed. Every single one of them. > >>> what you're also saying is that instead of simply iterating a list of >>> bom files and resetting permissions to whatever they say, the repair >>> permissions process would need to be significantly more complex, >>> collecting all bom files, go through all of the data to eliminate any >>> and all conflicts, somehow deciding which ones have priority over the >>> others, and after that's done, then apply the results to the system's >>> files. >> >> That is what it DOES do (or at least DID do until Apple removed it). >> That's why you stopped getting the results as the process progressed and >> instead got them all in one go at the end. > > definitely not. Sorry, but you're wrong. > >>> and that ignores the fact that permission repair doesn't actually fix >>> anything, which is why apple removed permissions repair entirely. >> >> Circular argument. > > nope to that too. > >>> it was somewhat useful a decade ago, but today, there is no reason for >>> it to exist anymore so it's *gone*. end of story. >>> >>> if you disagree with apple, you're more than welcome to write your own >>> permissions repair tool be sure to refer to the hfs+ documentation for >>> further details, as well as how to disable/enable sip. >> >> What part of the HFS+ documentation are you referring to. > > the part about enumerating a directory. do try to keep up. > >> Quote and link, please. > > start here: > <https://developer.apple.com/library/content/documentation/FileManagemen > t/Conceptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/Acc > essingFilesandDirectories.html> > No quote... ...again.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2017-05-19 19:32 -0400 |
| Message-ID | <190520171932052221%nospam@nospam.invalid> |
| In reply to | #107065 |
In article <ofnv2d$417$3@news.datemas.de>, Alan Baker <alangbaker@telus.net> wrote: > >>>>> " > >>>>> someone> except there is no way to know *which* bom file will come up > >>>>> last, so > >>>>> > >>>>> you>Sure there is: > >>>>> > >>>>> you> The date created." > >>>> > >>>> Sorry. I didn't say that well. > >>>> > >>>> The BOM files themselves contain information on the modification date of > >>>> each file installed, so it is easy to determine which supersedes which. > >>> > >>> no it isn't easy at all. > >>> > >>> you're *assuming* that a bom with a later date should supersede one > >>> with an earlier date. that's not a good assumption at all. > >> > >> No. "Not a BOM with a later date". > > > > then what metric are you going to use to resolve conflicts? > > > > previously, you said a later version fixes the mistakes of an earlier > > version. to me, that says 'date'. > > Yes. But a BOM files CONTAINS the dates of the files that were > installed. Every single one of them. that makes it even more complex to process, for absolutely no benefit. > >>> what you're also saying is that instead of simply iterating a list of > >>> bom files and resetting permissions to whatever they say, the repair > >>> permissions process would need to be significantly more complex, > >>> collecting all bom files, go through all of the data to eliminate any > >>> and all conflicts, somehow deciding which ones have priority over the > >>> others, and after that's done, then apply the results to the system's > >>> files. > >> > >> That is what it DOES do (or at least DID do until Apple removed it). > >> That's why you stopped getting the results as the process progressed and > >> instead got them all in one go at the end. > > > > definitely not. > > Sorry, but you're wrong. provide proof. authentic apple source code (with proof) is acceptable. > >>> and that ignores the fact that permission repair doesn't actually fix > >>> anything, which is why apple removed permissions repair entirely. > >> > >> Circular argument. > > > > nope to that too. > > > >>> it was somewhat useful a decade ago, but today, there is no reason for > >>> it to exist anymore so it's *gone*. end of story. > >>> > >>> if you disagree with apple, you're more than welcome to write your own > >>> permissions repair tool be sure to refer to the hfs+ documentation for > >>> further details, as well as how to disable/enable sip. > >> > >> What part of the HFS+ documentation are you referring to. > > > > the part about enumerating a directory. do try to keep up. > > > >> Quote and link, please. > > > > start here: > > <https://developer.apple.com/library/content/documentation/FileManagemen > > t/Conceptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/Acc > > essingFilesandDirectories.html> > > > > No quote... ...again. a direct link is sufficient.
[toc] | [prev] | [next] | [standalone]
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2017-05-19 16:45 -0700 |
| Message-ID | <ofo032$660$1@news.datemas.de> |
| In reply to | #107066 |
On 2017-05-19 4:32 PM, nospam wrote: > In article <ofnv2d$417$3@news.datemas.de>, Alan Baker > <alangbaker@telus.net> wrote: > >>>>>>> " >>>>>>> someone> except there is no way to know *which* bom file will come up >>>>>>> last, so >>>>>>> >>>>>>> you>Sure there is: >>>>>>> >>>>>>> you> The date created." >>>>>> >>>>>> Sorry. I didn't say that well. >>>>>> >>>>>> The BOM files themselves contain information on the modification date of >>>>>> each file installed, so it is easy to determine which supersedes which. >>>>> >>>>> no it isn't easy at all. >>>>> >>>>> you're *assuming* that a bom with a later date should supersede one >>>>> with an earlier date. that's not a good assumption at all. >>>> >>>> No. "Not a BOM with a later date". >>> >>> then what metric are you going to use to resolve conflicts? >>> >>> previously, you said a later version fixes the mistakes of an earlier >>> version. to me, that says 'date'. >> >> Yes. But a BOM files CONTAINS the dates of the files that were >> installed. Every single one of them. > > that makes it even more complex to process, for absolutely no benefit. For the benefit of correctly determining which permissions are correct when there is a discrepancy. > >>>>> what you're also saying is that instead of simply iterating a list of >>>>> bom files and resetting permissions to whatever they say, the repair >>>>> permissions process would need to be significantly more complex, >>>>> collecting all bom files, go through all of the data to eliminate any >>>>> and all conflicts, somehow deciding which ones have priority over the >>>>> others, and after that's done, then apply the results to the system's >>>>> files. >>>> >>>> That is what it DOES do (or at least DID do until Apple removed it). >>>> That's why you stopped getting the results as the process progressed and >>>> instead got them all in one go at the end. >>> >>> definitely not. >> >> Sorry, but you're wrong. > > provide proof. > > authentic apple source code (with proof) is acceptable. > >>>>> and that ignores the fact that permission repair doesn't actually fix >>>>> anything, which is why apple removed permissions repair entirely. >>>> >>>> Circular argument. >>> >>> nope to that too. >>> >>>>> it was somewhat useful a decade ago, but today, there is no reason for >>>>> it to exist anymore so it's *gone*. end of story. >>>>> >>>>> if you disagree with apple, you're more than welcome to write your own >>>>> permissions repair tool be sure to refer to the hfs+ documentation for >>>>> further details, as well as how to disable/enable sip. >>>> >>>> What part of the HFS+ documentation are you referring to. >>> >>> the part about enumerating a directory. do try to keep up. >>> >>>> Quote and link, please. >>> >>> start here: >>> <https://developer.apple.com/library/content/documentation/FileManagemen >>> t/Conceptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/Acc >>> essingFilesandDirectories.html> >>> >> >> No quote... ...again. > > a direct link is sufficient. Not when you just demanded I show you Apple's source code...
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2017-05-19 20:05 -0400 |
| Message-ID | <190520172005121442%nospam@nospam.invalid> |
| In reply to | #107067 |
In article <ofo032$660$1@news.datemas.de>, Alan Baker <alangbaker@telus.net> wrote: > >>>>>>> someone> except there is no way to know *which* bom file will come up > >>>>>>> last, so > >>>>>>> > >>>>>>> you>Sure there is: > >>>>>>> > >>>>>>> you> The date created." > >>>>>> > >>>>>> Sorry. I didn't say that well. > >>>>>> > >>>>>> The BOM files themselves contain information on the modification date > >>>>>> of > >>>>>> each file installed, so it is easy to determine which supersedes which. > >>>>> > >>>>> no it isn't easy at all. > >>>>> > >>>>> you're *assuming* that a bom with a later date should supersede one > >>>>> with an earlier date. that's not a good assumption at all. > >>>> > >>>> No. "Not a BOM with a later date". > >>> > >>> then what metric are you going to use to resolve conflicts? > >>> > >>> previously, you said a later version fixes the mistakes of an earlier > >>> version. to me, that says 'date'. > >> > >> Yes. But a BOM files CONTAINS the dates of the files that were > >> installed. Every single one of them. > > > > that makes it even more complex to process, for absolutely no benefit. > > For the benefit of correctly determining which permissions are correct > when there is a discrepancy. there is no single correct permissions. there are valid reasons for permissions to *not* be what apple thinks they should be. > >>>>> what you're also saying is that instead of simply iterating a list of > >>>>> bom files and resetting permissions to whatever they say, the repair > >>>>> permissions process would need to be significantly more complex, > >>>>> collecting all bom files, go through all of the data to eliminate any > >>>>> and all conflicts, somehow deciding which ones have priority over the > >>>>> others, and after that's done, then apply the results to the system's > >>>>> files. > >>>> > >>>> That is what it DOES do (or at least DID do until Apple removed it). > >>>> That's why you stopped getting the results as the process progressed and > >>>> instead got them all in one go at the end. > >>> > >>> definitely not. > >> > >> Sorry, but you're wrong. > > > > provide proof. > > > > authentic apple source code (with proof) is acceptable. > > > >>>>> and that ignores the fact that permission repair doesn't actually fix > >>>>> anything, which is why apple removed permissions repair entirely. > >>>> > >>>> Circular argument. > >>> > >>> nope to that too. > >>> > >>>>> it was somewhat useful a decade ago, but today, there is no reason for > >>>>> it to exist anymore so it's *gone*. end of story. > >>>>> > >>>>> if you disagree with apple, you're more than welcome to write your own > >>>>> permissions repair tool be sure to refer to the hfs+ documentation for > >>>>> further details, as well as how to disable/enable sip. > >>>> > >>>> What part of the HFS+ documentation are you referring to. > >>> > >>> the part about enumerating a directory. do try to keep up. > >>> > >>>> Quote and link, please. > >>> > >>> start here: > >>> <https://developer.apple.com/library/content/documentation/FileManagemen > >>> t/Conceptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/Acc > >>> essingFilesandDirectories.html> > >>> > >> > >> No quote... ...again. > > > > a direct link is sufficient. > > Not when you just demanded I show you Apple's source code... i did not demand that. i said that would be acceptable.
[toc] | [prev] | [next] | [standalone]
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2017-05-19 17:10 -0700 |
| Message-ID | <ofo1if$8l1$1@news.datemas.de> |
| In reply to | #107068 |
On 2017-05-19 5:05 PM, nospam wrote: > In article <ofo032$660$1@news.datemas.de>, Alan Baker > <alangbaker@telus.net> wrote: > >>>>>>>>> someone> except there is no way to know *which* bom file will come up >>>>>>>>> last, so >>>>>>>>> >>>>>>>>> you>Sure there is: >>>>>>>>> >>>>>>>>> you> The date created." >>>>>>>> >>>>>>>> Sorry. I didn't say that well. >>>>>>>> >>>>>>>> The BOM files themselves contain information on the modification date >>>>>>>> of >>>>>>>> each file installed, so it is easy to determine which supersedes which. >>>>>>> >>>>>>> no it isn't easy at all. >>>>>>> >>>>>>> you're *assuming* that a bom with a later date should supersede one >>>>>>> with an earlier date. that's not a good assumption at all. >>>>>> >>>>>> No. "Not a BOM with a later date". >>>>> >>>>> then what metric are you going to use to resolve conflicts? >>>>> >>>>> previously, you said a later version fixes the mistakes of an earlier >>>>> version. to me, that says 'date'. >>>> >>>> Yes. But a BOM files CONTAINS the dates of the files that were >>>> installed. Every single one of them. >>> >>> that makes it even more complex to process, for absolutely no benefit. >> >> For the benefit of correctly determining which permissions are correct >> when there is a discrepancy. > > there is no single correct permissions. > > there are valid reasons for permissions to *not* be what apple thinks > they should be. Give a concrete example. When choosing your example, please remember that repair permissions applies to Apple system files only. > >>>>>>> what you're also saying is that instead of simply iterating a list of >>>>>>> bom files and resetting permissions to whatever they say, the repair >>>>>>> permissions process would need to be significantly more complex, >>>>>>> collecting all bom files, go through all of the data to eliminate any >>>>>>> and all conflicts, somehow deciding which ones have priority over the >>>>>>> others, and after that's done, then apply the results to the system's >>>>>>> files. >>>>>> >>>>>> That is what it DOES do (or at least DID do until Apple removed it). >>>>>> That's why you stopped getting the results as the process progressed and >>>>>> instead got them all in one go at the end. >>>>> >>>>> definitely not. >>>> >>>> Sorry, but you're wrong. >>> >>> provide proof. >>> >>> authentic apple source code (with proof) is acceptable. >>> >>>>>>> and that ignores the fact that permission repair doesn't actually fix >>>>>>> anything, which is why apple removed permissions repair entirely. >>>>>> >>>>>> Circular argument. >>>>> >>>>> nope to that too. >>>>> >>>>>>> it was somewhat useful a decade ago, but today, there is no reason for >>>>>>> it to exist anymore so it's *gone*. end of story. >>>>>>> >>>>>>> if you disagree with apple, you're more than welcome to write your own >>>>>>> permissions repair tool be sure to refer to the hfs+ documentation for >>>>>>> further details, as well as how to disable/enable sip. >>>>>> >>>>>> What part of the HFS+ documentation are you referring to. >>>>> >>>>> the part about enumerating a directory. do try to keep up. >>>>> >>>>>> Quote and link, please. >>>>> >>>>> start here: >>>>> <https://developer.apple.com/library/content/documentation/FileManagemen >>>>> t/Conceptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/Acc >>>>> essingFilesandDirectories.html> >>>>> >>>> >>>> No quote... ...again. >>> >>> a direct link is sufficient. >> >> Not when you just demanded I show you Apple's source code... > > i did not demand that. i said that would be acceptable. Well it's not acceptable for you to vaguely hand wave at a huge mass of documentation and say "the answer is in there". If you KNOW the answer is in there, then that implies you've been there and seen it. But the point is moot anyway, because your whole argument about the ordering of files in a directory being the only way to determine which such succeed which is a strawman. >
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2017-05-20 15:04 +0000 |
| Message-ID | <eob474F8c9uU1@mid.individual.net> |
| In reply to | #107069 |
Alan Baker <alangbaker@telus.net> wrote: > On 2017-05-19 5:05 PM, nospam wrote: >> >> there is no single correct permissions. >> >> there are valid reasons for permissions to *not* be what apple thinks >> they should be. > > Give a concrete example. > > When choosing your example, please remember that repair permissions > applies to Apple system files only. Wrong again. Repair Permissions applies to anything listed in the receipt database BOM files, which include third-party applications (not Apple system files only), as well as Apple applications. In fact a great many system files are not included in the receipts database. > But the point is moot anyway, because your whole argument about the > ordering of files in a directory being the only way to determine which > such succeed which is a strawman. It's also irrelevant. You have so far been unable to back up your assertion that permissions are repaired in a certain order with any factual proof that is the case. You are chock full of FAIL. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2017-05-20 09:33 -0700 |
| Message-ID | <ofpr4s$1o43$2@gioia.aioe.org> |
| In reply to | #107078 |
On 2017-05-20 8:04 AM, Jolly Roger wrote: > Alan Baker <alangbaker@telus.net> wrote: >> On 2017-05-19 5:05 PM, nospam wrote: >>> >>> there is no single correct permissions. >>> >>> there are valid reasons for permissions to *not* be what apple thinks >>> they should be. >> >> Give a concrete example. >> >> When choosing your example, please remember that repair permissions >> applies to Apple system files only. > > Wrong again. Repair Permissions applies to anything listed in the receipt > database BOM files, which include third-party applications (not Apple > system files only), as well as Apple applications. In fact a great many > system files are not included in the receipts database. That is incorrect. Despite the way it is presented, repair permissions has a list of files within it that it will repair. > >> But the point is moot anyway, because your whole argument about the >> ordering of files in a directory being the only way to determine which >> such succeed which is a strawman. > > It's also irrelevant. You have so far been unable to back up your assertion > that permissions are repaired in a certain order with any factual proof > that is the case. You are chock full of FAIL. Actually, the initial claim was someone else's: That there were no right permissions and you could tell this because repair permissions didn't operate in any particular order. >
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2017-05-20 16:43 +0000 |
| Message-ID | <eoba1mF9ibsU1@mid.individual.net> |
| In reply to | #107080 |
On 2017-05-20, Alan Baker <alangbaker@telus.net> wrote: > On 2017-05-20 8:04 AM, Jolly Roger wrote: >> Alan Baker <alangbaker@telus.net> wrote: >> >>> please remember that repair permissions applies to Apple system >>> files only. >> >> Wrong again. Repair Permissions applies to anything listed in the >> receipt database BOM files, which include third-party applications >> (not Apple system files only), as well as Apple applications. In fact >> a great many system files are not included in the receipts database. > > That is incorrect. LOL! Which specific part of what I said is incorrect? Pick one: 1. Repair Permissions applies to anything listed in the receipt database BOM files. 2. BOM files include third-party applications (not Apple system files only), as well as Apple applications. 3. Many system files are not included in the receipts database. > Despite the way it is presented, repair permissions has a list of > files within it that it will repair. You haven't negated a single thing I said above. Meanwhile, your statement that "repair permissions applies to Apple system files only" couldn't be more wrong. >>> But the point is moot anyway, because your whole argument about the >>> ordering of files in a directory being the only way to determine >>> which such succeed which is a strawman. >> >> It's also irrelevant. You have so far been unable to back up your >> assertion that permissions are repaired in a certain order with any >> factual proof that is the case. You are chock full of FAIL. > > Actually, the initial claim was someone else's Squirm, squirm, little worm. #fail -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2017-05-20 16:45 +0000 |
| Message-ID | <eoba52F9ibsU2@mid.individual.net> |
| In reply to | #107081 |
On 2017-05-20, Jolly Roger <jollyroger@pobox.com> wrote: > > 2. BOM files include third-party applications (not Apple system files > only), as well as Apple applications. Obvious typo correction: 2. The receipt database includes third-party applications (not Apple system files only), as well as Apple applications. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2017-05-20 09:47 -0700 |
| Message-ID | <ofprv5$1o43$3@gioia.aioe.org> |
| In reply to | #107081 |
On 2017-05-20 9:43 AM, Jolly Roger wrote: > On 2017-05-20, Alan Baker <alangbaker@telus.net> wrote: >> On 2017-05-20 8:04 AM, Jolly Roger wrote: >>> Alan Baker <alangbaker@telus.net> wrote: >>> >>>> please remember that repair permissions applies to Apple system >>>> files only. >>> >>> Wrong again. Repair Permissions applies to anything listed in the >>> receipt database BOM files, which include third-party applications >>> (not Apple system files only), as well as Apple applications. In fact >>> a great many system files are not included in the receipts database. >> >> That is incorrect. > > LOL! Which specific part of what I said is incorrect? Pick one: > > 1. Repair Permissions applies to anything listed in the receipt database > BOM files. That. The actual software that does the repair keeps a list of strings on which it will operate. > > 2. BOM files include third-party applications (not Apple system files > only), as well as Apple applications. > > 3. Many system files are not included in the receipts database. > >> Despite the way it is presented, repair permissions has a list of >> files within it that it will repair. > > You haven't negated a single thing I said above. Meanwhile, your > statement that "repair permissions applies to Apple system files only" > couldn't be more wrong. > >>>> But the point is moot anyway, because your whole argument about the >>>> ordering of files in a directory being the only way to determine >>>> which such succeed which is a strawman. >>> >>> It's also irrelevant. You have so far been unable to back up your >>> assertion that permissions are repaired in a certain order with any >>> factual proof that is the case. You are chock full of FAIL. >> >> Actually, the initial claim was someone else's > > Squirm, squirm, little worm. #fail > Facts. Sorry.
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2017-05-20 17:08 +0000 |
| Message-ID | <eobbfkF9u2jU1@mid.individual.net> |
| In reply to | #107083 |
On 2017-05-20, Alan Baker <alangbaker@telus.net> wrote: > On 2017-05-20 9:43 AM, Jolly Roger wrote: >> On 2017-05-20, Alan Baker <alangbaker@telus.net> wrote: >>> On 2017-05-20 8:04 AM, Jolly Roger wrote: >>>> Alan Baker <alangbaker@telus.net> wrote: >>>> >>>>> please remember that repair permissions applies to Apple system >>>>> files only. >>>> >>>> Wrong again. Repair Permissions applies to anything listed in the >>>> receipt database BOM files, which include third-party applications >>>> (not Apple system files only), as well as Apple applications. In fact >>>> a great many system files are not included in the receipts database. >>> >>> That is incorrect. >> >> LOL! Which specific part of what I said is incorrect? Pick one: >> >> 1. Repair Permissions applies to anything listed in the receipt database >> BOM files. > > That. The actual software that does the repair keeps a list of strings > on which it will operate. "Disk Utility checks a file's permissions only if the file has a corresponding receipt in /var/db/receipts. The receipt tells Disk Utility what the permissions should be. Not all installers include a receipt with the files they install." <https://support.apple.com/en-us/HT201560> And this is *easily* verified by reading all of the available documentation and observing the tool in action. But by all means, keep trying, little guy! >> 2. BOM files include third-party applications (not Apple system files >> only), as well as Apple applications. >> >> 3. Many system files are not included in the receipts database. >> >>> Despite the way it is presented, repair permissions has a list of >>> files within it that it will repair. >> >> You haven't negated a single thing I said above. Meanwhile, your >> statement that "repair permissions applies to Apple system files only" >> couldn't be more wrong. >> >>>>> But the point is moot anyway, because your whole argument about the >>>>> ordering of files in a directory being the only way to determine >>>>> which such succeed which is a strawman. >>>> >>>> It's also irrelevant. You have so far been unable to back up your >>>> assertion that permissions are repaired in a certain order with any >>>> factual proof that is the case. You are chock full of FAIL. >>> >>> Actually, the initial claim was someone else's >> >> Squirm, squirm, little worm. #fail > > Facts. You haven't offered any. > Sorry. Yes, you are. Keep squirming! -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2017-05-22 15:21 +0000 |
| Message-ID | <eogdvjFf9fnU2@mid.individual.net> |
| In reply to | #107084 |
On 2017-05-20, Jolly Roger <jollyroger@pobox.com> wrote: > On 2017-05-20, Alan Baker <alangbaker@telus.net> wrote: >> On 2017-05-20 9:43 AM, Jolly Roger wrote: >>> On 2017-05-20, Alan Baker <alangbaker@telus.net> wrote: >>>> On 2017-05-20 8:04 AM, Jolly Roger wrote: >>>>> Alan Baker <alangbaker@telus.net> wrote: >>>>> >>>>>> please remember that repair permissions applies to Apple system >>>>>> files only. >>>>> >>>>> Wrong again. Repair Permissions applies to anything listed in the >>>>> receipt database BOM files, which include third-party applications >>>>> (not Apple system files only), as well as Apple applications. In fact >>>>> a great many system files are not included in the receipts database. >>>> >>>> That is incorrect. >>> >>> LOL! Which specific part of what I said is incorrect? Pick one: >>> >>> 1. Repair Permissions applies to anything listed in the receipt database >>> BOM files. >> >> That. The actual software that does the repair keeps a list of strings >> on which it will operate. > > "Disk Utility checks a file's permissions only if the file has a > corresponding receipt in /var/db/receipts. The receipt tells Disk > Utility what the permissions should be. Not all installers include a > receipt with the files they install." > ><https://support.apple.com/en-us/HT201560> > > And this is *easily* verified by reading all of the available > documentation and observing the tool in action. > > But by all means, keep trying, little guy! *crickets chirping*... I give you the Great Alan Baker, everyone! : ) -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2017-05-22 06:31 +0000 |
| Message-ID | <slrnoi51lc.1gnp.g.kreme@snow.local> |
| In reply to | #107083 |
In message <ofprv5$1o43$3@gioia.aioe.org> Alan Baker <alangbaker@telus.net> wrote: > On 2017-05-20 9:43 AM, Jolly Roger wrote: >> On 2017-05-20, Alan Baker <alangbaker@telus.net> wrote: >>> On 2017-05-20 8:04 AM, Jolly Roger wrote: >>>> Alan Baker <alangbaker@telus.net> wrote: >>>> >>>>> please remember that repair permissions applies to Apple system >>>>> files only. >>>> >>>> Wrong again. Repair Permissions applies to anything listed in the >>>> receipt database BOM files, which include third-party applications >>>> (not Apple system files only), as well as Apple applications. In fact >>>> a great many system files are not included in the receipts database. >>> >>> That is incorrect. >> >> LOL! Which specific part of what I said is incorrect? Pick one: >> >> 1. Repair Permissions applies to anything listed in the receipt database >> BOM files. > That. The actual software that does the repair keeps a list of strings > on which it will operate. The software keeps a list of files in the RECEIPTS FOLDER, you numpty fool. > Facts. Yes, get some. Please. > Sorry. Not Sorry enough, obviously. -- 'On whose authority?' demanded Wert. Trymon turned his grey eyes on him. 'Mine. I need no other.' --The Light Fantastic
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2017-05-22 15:23 +0000 |
| Message-ID | <eoge2uFf9fnU3@mid.individual.net> |
| In reply to | #107108 |
On 2017-05-22, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote: > In message <ofprv5$1o43$3@gioia.aioe.org> Alan Baker <alangbaker@telus.net> wrote: >> On 2017-05-20 9:43 AM, Jolly Roger wrote: >>> On 2017-05-20, Alan Baker <alangbaker@telus.net> wrote: >>>> On 2017-05-20 8:04 AM, Jolly Roger wrote: >>>>> Alan Baker <alangbaker@telus.net> wrote: >>>>> >>>>>> please remember that repair permissions applies to Apple system >>>>>> files only. >>>>> >>>>> Wrong again. Repair Permissions applies to anything listed in the >>>>> receipt database BOM files, which include third-party applications >>>>> (not Apple system files only), as well as Apple applications. In fact >>>>> a great many system files are not included in the receipts database. >>>> >>>> That is incorrect. >>> >>> LOL! Which specific part of what I said is incorrect? Pick one: >>> >>> 1. Repair Permissions applies to anything listed in the receipt database >>> BOM files. > >> That. The actual software that does the repair keeps a list of strings >> on which it will operate. > > The software keeps a list of files in the RECEIPTS FOLDER, you numpty > fool. Technically, the software that does the repair doesn't place anything in the receipts database; the installer does that. The software that does the repair simply scans the database to find out which files and permissions to set. Either way, Alan Baker is wrong, wrong, wrong. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2017-05-23 09:32 +0000 |
| Message-ID | <slrnoi80ji.2umq.g.kreme@snow.local> |
| In reply to | #107114 |
In message <eoge2uFf9fnU3@mid.individual.net> Jolly Roger <jollyroger@pobox.com> wrote: > On 2017-05-22, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote: >> In message <ofprv5$1o43$3@gioia.aioe.org> Alan Baker <alangbaker@telus.net> wrote: >>> On 2017-05-20 9:43 AM, Jolly Roger wrote: >>>> On 2017-05-20, Alan Baker <alangbaker@telus.net> wrote: >>>>> On 2017-05-20 8:04 AM, Jolly Roger wrote: >>>>>> Alan Baker <alangbaker@telus.net> wrote: >>>>>> >>>>>>> please remember that repair permissions applies to Apple system >>>>>>> files only. >>>>>> >>>>>> Wrong again. Repair Permissions applies to anything listed in the >>>>>> receipt database BOM files, which include third-party applications >>>>>> (not Apple system files only), as well as Apple applications. In fact >>>>>> a great many system files are not included in the receipts database. >>>>> >>>>> That is incorrect. >>>> >>>> LOL! Which specific part of what I said is incorrect? Pick one: >>>> >>>> 1. Repair Permissions applies to anything listed in the receipt database >>>> BOM files. >> >>> That. The actual software that does the repair keeps a list of strings >>> on which it will operate. >> >> The software keeps a list of files in the RECEIPTS FOLDER, you numpty >> fool. > Technically, the software that does the repair doesn't place anything in > the receipts database; the installer does that. True. > The software that does the repair simply scans the database to find > out which files and permissions to set. Either way, Alan Baker is > wrong, wrong, wrong. Yep. -- 'What can I do? I'm only human,' he said aloud. Someone said, Not all of you. --Pyramids
[toc] | [prev] | [next] | [standalone]
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2017-05-23 10:50 -0700 |
| Message-ID | <og1sp7$cgu$1@news.datemas.de> |
| In reply to | #107153 |
On 2017-05-23 2:32 AM, Lewis wrote: > In message <eoge2uFf9fnU3@mid.individual.net> Jolly Roger <jollyroger@pobox.com> wrote: >> On 2017-05-22, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote: >>> In message <ofprv5$1o43$3@gioia.aioe.org> Alan Baker <alangbaker@telus.net> wrote: >>>> On 2017-05-20 9:43 AM, Jolly Roger wrote: >>>>> On 2017-05-20, Alan Baker <alangbaker@telus.net> wrote: >>>>>> On 2017-05-20 8:04 AM, Jolly Roger wrote: >>>>>>> Alan Baker <alangbaker@telus.net> wrote: >>>>>>> >>>>>>>> please remember that repair permissions applies to Apple system >>>>>>>> files only. >>>>>>> >>>>>>> Wrong again. Repair Permissions applies to anything listed in the >>>>>>> receipt database BOM files, which include third-party applications >>>>>>> (not Apple system files only), as well as Apple applications. In fact >>>>>>> a great many system files are not included in the receipts database. >>>>>> >>>>>> That is incorrect. >>>>> >>>>> LOL! Which specific part of what I said is incorrect? Pick one: >>>>> >>>>> 1. Repair Permissions applies to anything listed in the receipt database >>>>> BOM files. >>> >>>> That. The actual software that does the repair keeps a list of strings >>>> on which it will operate. >>> >>> The software keeps a list of files in the RECEIPTS FOLDER, you numpty >>> fool. > >> Technically, the software that does the repair doesn't place anything in >> the receipts database; the installer does that. > > True. > >> The software that does the repair simply scans the database to find >> out which files and permissions to set. Either way, Alan Baker is >> wrong, wrong, wrong. > > Yep. > Nope. Sorry, but the Repair Permissions utility doesn't use the contents of everything in the Receipts folder. This can be confirmed by using "fs_usage" on the command line: 'But beyond that, only certain receipts are referenced, all of them associated with OS-X-related software. This limitation of the Repair Disk Permissions function has been debated around the Web, but you can confirm it yourself with a bit of Terminal savvy: By using the fs_usage command with the appropriate options, you can see exactly which receipt files are accessed when the Repair Disk Permissions function runs. The following is the list of such receipts on my Mac running Mac OS X 10.4: AdditionalAsianFonts.pkg AdditionalEssentials.pkg AdditionalFonts.pkg AddressBook.pkg ApplicationsServer.pkg Automator.pkg BaseSystem.pkg BrotherPrinterDrivers.pkg BSD.pkg BSDSDK.pkg CanonPrinterDrivers.pkg CommonAccessCard.pkg CommonCriteriaTools.pkg DevDocumentation.pkg DeveloperTools.pkg DevExamples.pkg DevFatLibraries.pkg DevInternal.pkg DevSDK.pkg ElectronicsForImagingPrinterDrivers.pkg EpsonPrinterDrivers.pkg Essentials.pkg FatLibraries.pkg GimpPrintPrinterDrivers.pkg HewlettPackardPrinterDrivers.pkg iCal.pkg iChat.pkg Internal.pkg iTunes.pkg Java.pkg LexmarkPrinterDrivers.pkg Mail.pkg MicrosoftIE.pkg MigrationAssistant.pkg OxfordDictionaries.pkg QuickTimeStreamingServer.pkg RicohPrinterDrivers.pkg Safari.pkg ServerAdminTools.pkg ServerEssentials.pkg ServerFatLibraries.pkg ServerInternal.pkg ServerSetup.pkg X11SDK.pkg X11User.pkg XeroxPrinterDrivers.pkg' <http://www.macworld.com/article/1052220/software-utilities/repairpermissions.html>
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2017-05-23 21:15 +0000 |
| Message-ID | <slrnoi99ph.h32.g.kreme@snow.local> |
| In reply to | #107159 |
In message <og1sp7$cgu$1@news.datemas.de> Alan Baker <alangbaker@telus.net> wrote: > On 2017-05-23 2:32 AM, Lewis wrote: >> In message <eoge2uFf9fnU3@mid.individual.net> Jolly Roger <jollyroger@pobox.com> wrote: >>> On 2017-05-22, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote: >>>> In message <ofprv5$1o43$3@gioia.aioe.org> Alan Baker <alangbaker@telus.net> wrote: >>>>> On 2017-05-20 9:43 AM, Jolly Roger wrote: >>>>>> On 2017-05-20, Alan Baker <alangbaker@telus.net> wrote: >>>>>>> On 2017-05-20 8:04 AM, Jolly Roger wrote: >>>>>>>> Alan Baker <alangbaker@telus.net> wrote: >>>>>>>> >>>>>>>>> please remember that repair permissions applies to Apple system >>>>>>>>> files only. >>>>>>>> >>>>>>>> Wrong again. Repair Permissions applies to anything listed in the >>>>>>>> receipt database BOM files, which include third-party applications >>>>>>>> (not Apple system files only), as well as Apple applications. In fact >>>>>>>> a great many system files are not included in the receipts database. >>>>>>> >>>>>>> That is incorrect. >>>>>> >>>>>> LOL! Which specific part of what I said is incorrect? Pick one: >>>>>> >>>>>> 1. Repair Permissions applies to anything listed in the receipt database >>>>>> BOM files. >>>> >>>>> That. The actual software that does the repair keeps a list of strings >>>>> on which it will operate. >>>> >>>> The software keeps a list of files in the RECEIPTS FOLDER, you numpty >>>> fool. >> >>> Technically, the software that does the repair doesn't place anything in >>> the receipts database; the installer does that. >> >> True. >> >>> The software that does the repair simply scans the database to find >>> out which files and permissions to set. Either way, Alan Baker is >>> wrong, wrong, wrong. >> >> Yep. >> > Nope. Yep. > Sorry, but the Repair Permissions utility doesn't use the contents of > everything in the Receipts folder. Nice try moving the goal posts. No one ever said *everything*. -- There are many reasons for being friends with someone. The fact that he's pointing a deadly weapon at you is among the top four. --The Last Continent
[toc] | [prev] | [next] | [standalone]
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2017-05-23 16:06 -0700 |
| Message-ID | <og2fab$cpq$1@news.datemas.de> |
| In reply to | #107161 |
On 2017-05-23 2:15 PM, Lewis wrote: > In message <og1sp7$cgu$1@news.datemas.de> Alan Baker <alangbaker@telus.net> wrote: >> On 2017-05-23 2:32 AM, Lewis wrote: >>> In message <eoge2uFf9fnU3@mid.individual.net> Jolly Roger <jollyroger@pobox.com> wrote: >>>> On 2017-05-22, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote: >>>>> In message <ofprv5$1o43$3@gioia.aioe.org> Alan Baker <alangbaker@telus.net> wrote: >>>>>> On 2017-05-20 9:43 AM, Jolly Roger wrote: >>>>>>> On 2017-05-20, Alan Baker <alangbaker@telus.net> wrote: >>>>>>>> On 2017-05-20 8:04 AM, Jolly Roger wrote: >>>>>>>>> Alan Baker <alangbaker@telus.net> wrote: >>>>>>>>> >>>>>>>>>> please remember that repair permissions applies to Apple system >>>>>>>>>> files only. >>>>>>>>> >>>>>>>>> Wrong again. Repair Permissions applies to anything listed in the >>>>>>>>> receipt database BOM files, which include third-party applications >>>>>>>>> (not Apple system files only), as well as Apple applications. In fact >>>>>>>>> a great many system files are not included in the receipts database. >>>>>>>> >>>>>>>> That is incorrect. >>>>>>> >>>>>>> LOL! Which specific part of what I said is incorrect? Pick one: >>>>>>> >>>>>>> 1. Repair Permissions applies to anything listed in the receipt database >>>>>>> BOM files. >>>>> >>>>>> That. The actual software that does the repair keeps a list of strings >>>>>> on which it will operate. >>>>> >>>>> The software keeps a list of files in the RECEIPTS FOLDER, you numpty >>>>> fool. >>> >>>> Technically, the software that does the repair doesn't place anything in >>>> the receipts database; the installer does that. >>> >>> True. >>> >>>> The software that does the repair simply scans the database to find >>>> out which files and permissions to set. Either way, Alan Baker is >>>> wrong, wrong, wrong. >>> >>> Yep. >>> > >> Nope. > > Yep. > >> Sorry, but the Repair Permissions utility doesn't use the contents of >> everything in the Receipts folder. > > Nice try moving the goal posts. No one ever said *everything*. That was certainly what was said: the repair permissions worked with every receipt in the Receipts folder. "Repair Permissions applies to anything listed in the receipt database BOM files." It doesn't.
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2017-05-18 21:47 +0000 |
| Message-ID | <slrnohs5qd.d7u.g.kreme@snow.local> |
| In reply to | #107005 |
In message <ofj98e$svj$1@news.datemas.de> Alan Baker <alangbaker@telus.net> wrote: > On 2017-05-17 9:43 PM, nospam wrote: >> In article <ofikfe$okb$1@news.datemas.de>, Alan Baker >> <alangbaker@telus.net> wrote: >> >>>>>>>>>>>>> It proves that someone changed their mind about what the >>>>>>>>>>>>> permissions >>>>>>>>>>>>> should be. That's all. >>>>>>>>>>>> >>>>>>>>>>>> which means there is no single correct value. >>>>>>>>>>> >>>>>>>>>>> No. Sorry. >>>>>>>>>>> >>>>>>>>>>> It means that someone realized they'd made an error (or introduced >>>>>>>>>>> one). >>>>>>>>>> >>>>>>>>>> if that were true, they'd have removed the conflicting ones, leaving >>>>>>>>>> only the correct one. >>>>>>>>>> >>>>>>>>>> they didn't. >>>>>>>>> >>>>>>>>> No need when they can simply read the BOM files in order and let the >>>>>>>>> final one win... >>>>>>>> >>>>>>>> there is no final one. >>>>>>> >>>>>>> If only you could support that... >>>>>> >>>>>> i did. it's in the hfs+ docs. why would i even mention that if it >>>>>> wasn't? >>>>> >>>>> You CLAIM it is in the HFS+ docs... >>>> >>>> it is. >>>> >>>>> ...but you can't produce a quote despite those documents being readily >>>>> available on the web. >>>> >>>> i'm not going through it to find what's obvious to nearly everyone. >>>> >>>>> Nor can you offer an adequate explanation of why documentation for a >>>>> file system would mention a system utility such as repair permissions. >>>> >>>> i didn't say the hfs docs mentions repair permissions. you're way over >>>> your head >>>> >>>> what i said was the order of files is indeterminate, and it is. >>> >>> And you said that that is document in the HFS+ documentation.... >> >> and it is. >> >> i don't see you showing where it contradicts that claim. i pointed you >> to the docs. feel free to find where it guarantees the order and states >> what order that is. that's because it ain't there. > You've now both claimed that it is in the documentation and NOT in the > documentation for HFS+ No he hasn't. You're doing your typical thing of twisting words. >> >>>>>> you clearly haven't a clue how permissions repair works or what it does. >>>>>> >>>>>>>>> Found that documentation in HFS+ yet? >>>>>>>> >>>>>>>> no point, because you'll argue about something else. >>>>>>> >>>>>>> You have nothing. >>>>>> >>>>>> that would be you. >>>>> >>>>> Still waiting on something concrete from you... >>>> >>>> it's been provided. >>>> >>>> like i said before you don't understand what's going on. >>>> >>> >>> And you're doing everything you can to avoid changing that it would seem. >> >> nope. several people have explained things to you, including myself. > Several people have made claims. > Only YOU have claimed that in the documentation of HFS+ is support for > your claim of indeterminate ordering of BOM files. And? Show where in the documentation it tells you that the BOM files (or any files on HFS+) have specific ordering? > Put up or shut up. Yes. We're all waiting for you to do one of those. -- he'd moved like music, like someone dancing to a rhythm inside his head. And his face for a moment in the moonlight was the skull of an angel...
[toc] | [prev] | [next] | [standalone]
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2017-05-18 16:19 -0700 |
| Message-ID | <ofla60$f48$1@news.datemas.de> |
| In reply to | #107026 |
On 2017-05-18 2:47 PM, Lewis wrote: > In message <ofj98e$svj$1@news.datemas.de> Alan Baker <alangbaker@telus.net> wrote: >> On 2017-05-17 9:43 PM, nospam wrote: >>> In article <ofikfe$okb$1@news.datemas.de>, Alan Baker >>> <alangbaker@telus.net> wrote: >>> >>>>>>>>>>>>>> It proves that someone changed their mind about what the >>>>>>>>>>>>>> permissions >>>>>>>>>>>>>> should be. That's all. >>>>>>>>>>>>> >>>>>>>>>>>>> which means there is no single correct value. >>>>>>>>>>>> >>>>>>>>>>>> No. Sorry. >>>>>>>>>>>> >>>>>>>>>>>> It means that someone realized they'd made an error (or introduced >>>>>>>>>>>> one). >>>>>>>>>>> >>>>>>>>>>> if that were true, they'd have removed the conflicting ones, leaving >>>>>>>>>>> only the correct one. >>>>>>>>>>> >>>>>>>>>>> they didn't. >>>>>>>>>> >>>>>>>>>> No need when they can simply read the BOM files in order and let the >>>>>>>>>> final one win... >>>>>>>>> >>>>>>>>> there is no final one. >>>>>>>> >>>>>>>> If only you could support that... >>>>>>> >>>>>>> i did. it's in the hfs+ docs. why would i even mention that if it >>>>>>> wasn't? >>>>>> >>>>>> You CLAIM it is in the HFS+ docs... >>>>> >>>>> it is. >>>>> >>>>>> ...but you can't produce a quote despite those documents being readily >>>>>> available on the web. >>>>> >>>>> i'm not going through it to find what's obvious to nearly everyone. >>>>> >>>>>> Nor can you offer an adequate explanation of why documentation for a >>>>>> file system would mention a system utility such as repair permissions. >>>>> >>>>> i didn't say the hfs docs mentions repair permissions. you're way over >>>>> your head >>>>> >>>>> what i said was the order of files is indeterminate, and it is. >>>> >>>> And you said that that is document in the HFS+ documentation.... >>> >>> and it is. >>> >>> i don't see you showing where it contradicts that claim. i pointed you >>> to the docs. feel free to find where it guarantees the order and states >>> what order that is. that's because it ain't there. > >> You've now both claimed that it is in the documentation and NOT in the >> documentation for HFS+ > > No he hasn't. You're doing your typical thing of twisting words. Yes. He really has. > >>> >>>>>>> you clearly haven't a clue how permissions repair works or what it does. >>>>>>> >>>>>>>>>> Found that documentation in HFS+ yet? >>>>>>>>> >>>>>>>>> no point, because you'll argue about something else. >>>>>>>> >>>>>>>> You have nothing. >>>>>>> >>>>>>> that would be you. >>>>>> >>>>>> Still waiting on something concrete from you... >>>>> >>>>> it's been provided. >>>>> >>>>> like i said before you don't understand what's going on. >>>>> >>>> >>>> And you're doing everything you can to avoid changing that it would seem. >>> >>> nope. several people have explained things to you, including myself. > >> Several people have made claims. > >> Only YOU have claimed that in the documentation of HFS+ is support for >> your claim of indeterminate ordering of BOM files. > > And? Show where in the documentation it tells you that the BOM files (or > any files on HFS+) have specific ordering? Show were it says that because files on disk don't have determinate ordering that repair permissions cannot determine their ordering by other means. > >> Put up or shut up. > > Yes. We're all waiting for you to do one of those. > >
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.sys.mac.system
csiph-web