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 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2017-05-16 17:44 -0700 |
| Message-ID | <ofg6d5$fob$7@news.datemas.de> |
| In reply to | #106937 |
On 2017-05-16 11:38 AM, nospam wrote: > In article <here-BFA50F.20360516052017@news.individual.net>, android > <here@there.was> wrote: > >>>>>>>> it resets permissions to what apple thinks they should be, which >>>>>>>> isn't the only valid choice. >>>>>>> >>>>>>> Ummm... ...no. >>>>>> >>>>>> um, yes. >>>>>> >>>>>> there is no single 'correct' permission setting. >>>>> >>>>> Yep. In fact the glaring design fault of Repair Permissions is that it >>>>> has no way to resolve the case where two different receipts have >>>>> differing permission settings for a given file, which actually happens >>>>> quite frequently. That means it's actually quite common for there to be >>>>> disagreement (even between two *Apple* installs) about what the correct >>>>> permissions should be for installed files. >>>>> >>>> >>>> Cite, please... >>> >>> have you even *used* repair permissions? >>> >>> run repair permissions and watch it change the permissions of certain >>> files (apple has a list of them in a tech note) and then back again. >>> >>> run it a second time and it does the same thing. >>> >>> repeat as often as necessary until you understand just how pointless >>> repair permissions actually is. >> >> It's not pointless. > > it is > >> It resets the permissions of files to those given to >> them by the APPL installer. > > which is one of numerous valid possibilities Says you... ...but why do you know more than Apple? > >> YMMV... Do you accuse the APPL of posting >> clunky stuff? > > yes. And yet, on the other hand, you turn around and say (imply at the very least) that their stuff is so good, there's no need to check for malware on a regular basis...
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2017-05-16 21:05 -0400 |
| Message-ID | <160520172105017986%nospam@nospam.invalid> |
| In reply to | #106953 |
In article <ofg6d5$fob$7@news.datemas.de>, Alan Baker <alangbaker@telus.net> wrote: > > > >>>>>>>> it resets permissions to what apple thinks they should be, which > >>>>>>>> isn't the only valid choice. > >>>>>>> > >>>>>>> Ummm... ...no. > >>>>>> > >>>>>> um, yes. > >>>>>> > >>>>>> there is no single 'correct' permission setting. > >>>>> > >>>>> Yep. In fact the glaring design fault of Repair Permissions is that it > >>>>> has no way to resolve the case where two different receipts have > >>>>> differing permission settings for a given file, which actually happens > >>>>> quite frequently. That means it's actually quite common for there to be > >>>>> disagreement (even between two *Apple* installs) about what the correct > >>>>> permissions should be for installed files. > >>>>> > >>>> > >>>> Cite, please... > >>> > >>> have you even *used* repair permissions? > >>> > >>> run repair permissions and watch it change the permissions of certain > >>> files (apple has a list of them in a tech note) and then back again. > >>> > >>> run it a second time and it does the same thing. > >>> > >>> repeat as often as necessary until you understand just how pointless > >>> repair permissions actually is. > >> > >> It's not pointless. > > > > it is > > > >> It resets the permissions of files to those given to > >> them by the APPL installer. > > > > which is one of numerous valid possibilities > > Says you... says everyone who understands unix, file permissions and mac os. > ...but why do you know more than Apple? i never said i did. > >> YMMV... Do you accuse the APPL of posting > >> clunky stuff? > > > > yes. > > And yet, on the other hand, you turn around and say (imply at the very > least) that their stuff is so good, there's no need to check for malware > on a regular basis... correct. do you swap hard drives every 3 years? because that's the point at which the failure rate starts to climb. the solution is not to waste time scanning for what doesn't exist, but to have a good solid backup strategy that covers *any* type of failure, including malware, hd failure, fire, theft and much more. people are *so* terrified about malware that they do stupid things, such as ignore all of the other things that are more likely to go wrong. that's bad.
[toc] | [prev] | [next] | [standalone]
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2017-05-16 18:09 -0700 |
| Message-ID | <ofg7t6$il7$4@news.datemas.de> |
| In reply to | #106954 |
On 2017-05-16 6:05 PM, nospam wrote: > In article <ofg6d5$fob$7@news.datemas.de>, Alan Baker > <alangbaker@telus.net> wrote: > >>> >>>>>>>>>> it resets permissions to what apple thinks they should be, which >>>>>>>>>> isn't the only valid choice. >>>>>>>>> >>>>>>>>> Ummm... ...no. >>>>>>>> >>>>>>>> um, yes. >>>>>>>> >>>>>>>> there is no single 'correct' permission setting. >>>>>>> >>>>>>> Yep. In fact the glaring design fault of Repair Permissions is that it >>>>>>> has no way to resolve the case where two different receipts have >>>>>>> differing permission settings for a given file, which actually happens >>>>>>> quite frequently. That means it's actually quite common for there to be >>>>>>> disagreement (even between two *Apple* installs) about what the correct >>>>>>> permissions should be for installed files. >>>>>>> >>>>>> >>>>>> Cite, please... >>>>> >>>>> have you even *used* repair permissions? >>>>> >>>>> run repair permissions and watch it change the permissions of certain >>>>> files (apple has a list of them in a tech note) and then back again. >>>>> >>>>> run it a second time and it does the same thing. >>>>> >>>>> repeat as often as necessary until you understand just how pointless >>>>> repair permissions actually is. >>>> >>>> It's not pointless. >>> >>> it is >>> >>>> It resets the permissions of files to those given to >>>> them by the APPL installer. >>> >>> which is one of numerous valid possibilities >> >> Says you... > > says everyone who understands unix, file permissions and mac os. > >> ...but why do you know more than Apple? > > i never said i did. Yeah. You just did say that. > >>>> YMMV... Do you accuse the APPL of posting >>>> clunky stuff? >>> >>> yes. >> >> And yet, on the other hand, you turn around and say (imply at the very >> least) that their stuff is so good, there's no need to check for malware >> on a regular basis... > > correct. > > do you swap hard drives every 3 years? because that's the point at > which the failure rate starts to climb. Cite > > the solution is not to waste time scanning for what doesn't exist, but > to have a good solid backup strategy that covers *any* type of failure, > including malware, hd failure, fire, theft and much more. > > people are *so* terrified about malware that they do stupid things, > such as ignore all of the other things that are more likely to go > wrong. that's bad. I agree. But that doesn't make imagining that a good strategy is to never check for malware. What if someone rights an encryption-ransomware that just formats your Time Machine backup?
[toc] | [prev] | [next] | [standalone]
| From | Your Name <YourName@YourISP.com> |
|---|---|
| Date | 2017-05-17 13:26 +1200 |
| Message-ID | <ofg8s0$fl4$1@gioia.aioe.org> |
| In reply to | #106955 |
On 2017-05-17 01:09:58 +0000, Alan Baker said: > On 2017-05-16 6:05 PM, nospam wrote: >> In article <ofg6d5$fob$7@news.datemas.de>, Alan Baker >> <alangbaker@telus.net> wrote: <snip> >> >> do you swap hard drives every 3 years? because that's the point at >> which the failure rate starts to climb. > > Cite The original 6GB hard drive from my old beige PowerMac G3 is still working fine ... it has outlived the G3 itself and is now in an external USB enclosure. :-) It has also outlived quite a few newer / bigger hard drives in various iMac models at various places I help out.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2017-05-16 21:35 -0400 |
| Message-ID | <160520172135488811%nospam@nospam.invalid> |
| In reply to | #106955 |
In article <ofg7t6$il7$4@news.datemas.de>, Alan Baker <alangbaker@telus.net> wrote: > >>> > >>>> It resets the permissions of files to those given to > >>>> them by the APPL installer. > >>> > >>> which is one of numerous valid possibilities > >> > >> Says you... > > > > says everyone who understands unix, file permissions and mac os. > > > >> ...but why do you know more than Apple? > > > > i never said i did. > > Yeah. You just did say that. nope. > >>>> YMMV... Do you accuse the APPL of posting > >>>> clunky stuff? > >>> > >>> yes. > >> > >> And yet, on the other hand, you turn around and say (imply at the very > >> least) that their stuff is so good, there's no need to check for malware > >> on a regular basis... > > > > correct. > > > > do you swap hard drives every 3 years? because that's the point at > > which the failure rate starts to climb. > > Cite <http://media.bestofmicro.com/4/A/302122/original/ssdfailurerates_1024.p ng> <http://storagemojo.com/wp-content/uploads/2007/02/afr_age.png> <https://www.extremetech.com/wp-content/uploads/2013/11/backblaze-drive- life-three-phases.jpg> <https://www.extremetech.com/wp-content/uploads/2013/11/backblaze-annual- hard-drive-failure-by-quarter.jpg> > > the solution is not to waste time scanning for what doesn't exist, but > > to have a good solid backup strategy that covers *any* type of failure, > > including malware, hd failure, fire, theft and much more. > > > > people are *so* terrified about malware that they do stupid things, > > such as ignore all of the other things that are more likely to go > > wrong. that's bad. > > I agree. > > But that doesn't make imagining that a good strategy is to never check > for malware. and if it shows something, you restore from backup, the same as if you didn't check and had malware, hd crashed, house burned down, etc. the solution is not checking for malware, but to *have* *a* *backup*. if you don't have a backup, then you're fucked. at least with ransomware, you can pay to get your data back. if your hd crashes, you're basically fucked. there are drive recovery services, but they will make ransomware look *cheap* in comparison. > What if someone rights an encryption-ransomware that just formats your > Time Machine backup? writes. and they can't. and time machine isn't my only backup, so even if they somehow did manage to encrypt that, it won't make a difference. i'll just use another backup. it would be an amazing bit of ransomware to encrypt the hard drive sitting on the shelf and not connected to anything or better yet, the one that's offsite.
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2017-05-17 02:04 +0000 |
| Message-ID | <eo1pdiF3223U2@mid.individual.net> |
| In reply to | #106953 |
Alan Baker <alangbaker@telus.net> wrote: > On 2017-05-16 11:38 AM, nospam wrote: >> In article <here-BFA50F.20360516052017@news.individual.net>, android >> <here@there.was> wrote: >> >>>>>>>>> it resets permissions to what apple thinks they should be, which >>>>>>>>> isn't the only valid choice. >>>>>>>> >>>>>>>> Ummm... ...no. >>>>>>> >>>>>>> um, yes. >>>>>>> >>>>>>> there is no single 'correct' permission setting. >>>>>> >>>>>> Yep. In fact the glaring design fault of Repair Permissions is that it >>>>>> has no way to resolve the case where two different receipts have >>>>>> differing permission settings for a given file, which actually happens >>>>>> quite frequently. That means it's actually quite common for there to be >>>>>> disagreement (even between two *Apple* installs) about what the correct >>>>>> permissions should be for installed files. >>>>>> >>>>> >>>>> Cite, please... >>>> >>>> have you even *used* repair permissions? >>>> >>>> run repair permissions and watch it change the permissions of certain >>>> files (apple has a list of them in a tech note) and then back again. >>>> >>>> run it a second time and it does the same thing. >>>> >>>> repeat as often as necessary until you understand just how pointless >>>> repair permissions actually is. >>> >>> It's not pointless. >> >> it is >> >>> It resets the permissions of files to those given to >>> them by the APPL installer. >> >> which is one of numerous valid possibilities > > Says you... Says a bunch of people who know what is going on behind the scenes. That clearly excludes people like you. > ...but why do you know more than Apple? Straw man. Lame. >>> YMMV... Do you accuse the APPL of posting >>> clunky stuff? >> >> yes. > > And yet, on the other hand, you turn around and say (imply at the very > least) that their stuff is so good, there's no need to check for malware > on a regular basis... Straw man again. Lame. -- 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-16 18:59 +0000 |
| Message-ID | <eo10frFs4pbU1@mid.individual.net> |
| In reply to | #106936 |
android <here@there.was> wrote: > > the APPL installer "Derr herr! I always refer to Apple with their stock symbol 'APPL' to show the rest of you I'm oh so witty and sly! I make stupid joke, see?! Me witty! Me smart! Me funny! Derr herr..." Pffft... -- 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 | android <here@there.was> |
|---|---|
| Date | 2017-05-16 21:07 +0200 |
| Message-ID | <here-B94B72.21070716052017@news.individual.net> |
| In reply to | #106938 |
In article <eo10frFs4pbU1@mid.individual.net>, Jolly Roger <jollyroger@pobox.com> wrote: > android <here@there.was> wrote: > > > > the APPL installer > > "Derr herr! I always refer to Apple with their stock symbol 'APPL' to show > the rest of you I'm oh so witty and sly! I make stupid joke, see?! Me > witty! Me smart! Me funny! Derr herr..." Shhhhh... It was supposed to be a secret! -- teleportation kills
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2017-05-16 20:28 +0000 |
| Message-ID | <eo15o8Ftar3U2@mid.individual.net> |
| In reply to | #106940 |
On 2017-05-16, android <here@there.was> wrote: > In article <eo10frFs4pbU1@mid.individual.net>, > Jolly Roger <jollyroger@pobox.com> wrote: > >> android <here@there.was> wrote: >> > >> > the APPL installer >> >> "Derr herr! I always refer to Apple with their stock symbol 'APPL' to show >> the rest of you I'm oh so witty and sly! I make stupid joke, see?! Me >> witty! Me smart! Me funny! Derr herr..." > > Shhhhh... It was supposed to be a secret! HERR HERRR HERRRR!!! I just spit my drink! You're so, so witty! -- 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-16 18:20 +0000 |
| Message-ID | <eo0u6vFrc96U2@mid.individual.net> |
| In reply to | #106929 |
On 2017-05-16, Alan Baker <alangbaker@telus.net> wrote: > On 2017-05-15 5:08 PM, Jolly Roger wrote: >> On 2017-05-15, nospam <nospam@nospam.invalid> wrote: >>> In article <ofd7v9$che$2@news.datemas.de>, Alan Baker >>> <alangbaker@telus.net> wrote: >>> >>>>>>>>> "Repair Permissions" is not useless since it does do something, >>>>>>>>> BUT whether running that process actually fixes *all* the >>>>>>>>> problems it supposedly does is a totally different question. >>>>>>>> >>>>>>>> it's useless and rarely fixes anything, if ever. >>>>>> >>>>>> It fixes what it was designed to fix ... Permissions. >>>>> >>>>> permissions do not break, so there's nothing to fix. >>>> >>>> I'm sorry, but at the very least, permissions DID (past tense) break. >>> >>> permissions are just a setting. they cannot break. >>> >>> they might be different than what apple thinks they should be but that >>> doesn't mean they're broken. it just means they're different. >>> >>> there are valid reasons for permissions to be different and without >>> causing any issues whatsoever. >>> >>>>> it resets permissions to what apple thinks they should be, which >>>>> isn't the only valid choice. >>>> >>>> Ummm... ...no. >>> >>> um, yes. >>> >>> there is no single 'correct' permission setting. >> >> Yep. In fact the glaring design fault of Repair Permissions is that it >> has no way to resolve the case where two different receipts have >> differing permission settings for a given file, which actually happens >> quite frequently. That means it's actually quite common for there to be >> disagreement (even between two *Apple* installs) about what the correct >> permissions should be for installed files. > > Cite, please... It's easily observed and confirmed: 1. Run repair permissions multiple times in a row. 2. Notice that the repair permissions log states that the permissions for certain files need repair over and over again (seemingly never get actually actually "fixed"). 3. Examine the receipt BOMs and note that those very files are actually mentioned in more than one receipt's BOM with differing permissions. No, I'm not going to do this exercise and document it for you. I don't care whether you ignorantly claim this isn't the case. Revel in your ignorance for all I care. -- 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-16 17:41 -0700 |
| Message-ID | <ofg68c$fob$5@news.datemas.de> |
| In reply to | #106934 |
On 2017-05-16 11:20 AM, Jolly Roger wrote: > On 2017-05-16, Alan Baker <alangbaker@telus.net> wrote: >> On 2017-05-15 5:08 PM, Jolly Roger wrote: >>> On 2017-05-15, nospam <nospam@nospam.invalid> wrote: >>>> In article <ofd7v9$che$2@news.datemas.de>, Alan Baker >>>> <alangbaker@telus.net> wrote: >>>> >>>>>>>>>> "Repair Permissions" is not useless since it does do something, >>>>>>>>>> BUT whether running that process actually fixes *all* the >>>>>>>>>> problems it supposedly does is a totally different question. >>>>>>>>> >>>>>>>>> it's useless and rarely fixes anything, if ever. >>>>>>> >>>>>>> It fixes what it was designed to fix ... Permissions. >>>>>> >>>>>> permissions do not break, so there's nothing to fix. >>>>> >>>>> I'm sorry, but at the very least, permissions DID (past tense) break. >>>> >>>> permissions are just a setting. they cannot break. >>>> >>>> they might be different than what apple thinks they should be but that >>>> doesn't mean they're broken. it just means they're different. >>>> >>>> there are valid reasons for permissions to be different and without >>>> causing any issues whatsoever. >>>> >>>>>> it resets permissions to what apple thinks they should be, which >>>>>> isn't the only valid choice. >>>>> >>>>> Ummm... ...no. >>>> >>>> um, yes. >>>> >>>> there is no single 'correct' permission setting. >>> >>> Yep. In fact the glaring design fault of Repair Permissions is that it >>> has no way to resolve the case where two different receipts have >>> differing permission settings for a given file, which actually happens >>> quite frequently. That means it's actually quite common for there to be >>> disagreement (even between two *Apple* installs) about what the correct >>> permissions should be for installed files. >> >> Cite, please... > > It's easily observed and confirmed: > > 1. Run repair permissions multiple times in a row. > 2. Notice that the repair permissions log states that the permissions > for certain files need repair over and over again (seemingly never get > actually actually "fixed"). > 3. Examine the receipt BOMs and note that those very files are actually > mentioned in more than one receipt's BOM with differing permissions. > > No, I'm not going to do this exercise and document it for you. I don't > care whether you ignorantly claim this isn't the case. Revel in your > ignorance for all I care. > Sorry, but all that demonstrates is that mistakes are being corrected. The fact that it happens to be accomplished by simply changing permissions more than once is a difference that makes no difference.
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2017-05-17 02:04 +0000 |
| Message-ID | <eo1pdhF3223U1@mid.individual.net> |
| In reply to | #106952 |
Alan Baker <alangbaker@telus.net> wrote: > On 2017-05-16 11:20 AM, Jolly Roger wrote: >> On 2017-05-16, Alan Baker <alangbaker@telus.net> wrote: >>> On 2017-05-15 5:08 PM, Jolly Roger wrote: >>>> On 2017-05-15, nospam <nospam@nospam.invalid> wrote: >>>>> In article <ofd7v9$che$2@news.datemas.de>, Alan Baker >>>>> <alangbaker@telus.net> wrote: >>>>> >>>>>>>>>>> "Repair Permissions" is not useless since it does do something, >>>>>>>>>>> BUT whether running that process actually fixes *all* the >>>>>>>>>>> problems it supposedly does is a totally different question. >>>>>>>>>> >>>>>>>>>> it's useless and rarely fixes anything, if ever. >>>>>>>> >>>>>>>> It fixes what it was designed to fix ... Permissions. >>>>>>> >>>>>>> permissions do not break, so there's nothing to fix. >>>>>> >>>>>> I'm sorry, but at the very least, permissions DID (past tense) break. >>>>> >>>>> permissions are just a setting. they cannot break. >>>>> >>>>> they might be different than what apple thinks they should be but that >>>>> doesn't mean they're broken. it just means they're different. >>>>> >>>>> there are valid reasons for permissions to be different and without >>>>> causing any issues whatsoever. >>>>> >>>>>>> it resets permissions to what apple thinks they should be, which >>>>>>> isn't the only valid choice. >>>>>> >>>>>> Ummm... ...no. >>>>> >>>>> um, yes. >>>>> >>>>> there is no single 'correct' permission setting. >>>> >>>> Yep. In fact the glaring design fault of Repair Permissions is that it >>>> has no way to resolve the case where two different receipts have >>>> differing permission settings for a given file, which actually happens >>>> quite frequently. That means it's actually quite common for there to be >>>> disagreement (even between two *Apple* installs) about what the correct >>>> permissions should be for installed files. >>> >>> Cite, please... >> >> It's easily observed and confirmed: >> >> 1. Run repair permissions multiple times in a row. >> 2. Notice that the repair permissions log states that the permissions >> for certain files need repair over and over again (seemingly never get >> actually actually "fixed"). >> 3. Examine the receipt BOMs and note that those very files are actually >> mentioned in more than one receipt's BOM with differing permissions. >> >> No, I'm not going to do this exercise and document it for you. I don't >> care whether you ignorantly claim this isn't the case. Revel in your >> ignorance for all I care. >> > > Sorry, but all that demonstrates is that mistakes are being corrected. Nope, it illustrates that the design of the repair permissions facility is faulty. You just can't accept it. -- 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-16 19:14 -0700 |
| Message-ID | <ofgbn3$p9c$3@news.datemas.de> |
| In reply to | #106959 |
On 2017-05-16 7:04 PM, Jolly Roger wrote: > Alan Baker <alangbaker@telus.net> wrote: >> On 2017-05-16 11:20 AM, Jolly Roger wrote: >>> On 2017-05-16, Alan Baker <alangbaker@telus.net> wrote: >>>> On 2017-05-15 5:08 PM, Jolly Roger wrote: >>>>> On 2017-05-15, nospam <nospam@nospam.invalid> wrote: >>>>>> In article <ofd7v9$che$2@news.datemas.de>, Alan Baker >>>>>> <alangbaker@telus.net> wrote: >>>>>> >>>>>>>>>>>> "Repair Permissions" is not useless since it does do something, >>>>>>>>>>>> BUT whether running that process actually fixes *all* the >>>>>>>>>>>> problems it supposedly does is a totally different question. >>>>>>>>>>> >>>>>>>>>>> it's useless and rarely fixes anything, if ever. >>>>>>>>> >>>>>>>>> It fixes what it was designed to fix ... Permissions. >>>>>>>> >>>>>>>> permissions do not break, so there's nothing to fix. >>>>>>> >>>>>>> I'm sorry, but at the very least, permissions DID (past tense) break. >>>>>> >>>>>> permissions are just a setting. they cannot break. >>>>>> >>>>>> they might be different than what apple thinks they should be but that >>>>>> doesn't mean they're broken. it just means they're different. >>>>>> >>>>>> there are valid reasons for permissions to be different and without >>>>>> causing any issues whatsoever. >>>>>> >>>>>>>> it resets permissions to what apple thinks they should be, which >>>>>>>> isn't the only valid choice. >>>>>>> >>>>>>> Ummm... ...no. >>>>>> >>>>>> um, yes. >>>>>> >>>>>> there is no single 'correct' permission setting. >>>>> >>>>> Yep. In fact the glaring design fault of Repair Permissions is that it >>>>> has no way to resolve the case where two different receipts have >>>>> differing permission settings for a given file, which actually happens >>>>> quite frequently. That means it's actually quite common for there to be >>>>> disagreement (even between two *Apple* installs) about what the correct >>>>> permissions should be for installed files. >>>> >>>> Cite, please... >>> >>> It's easily observed and confirmed: >>> >>> 1. Run repair permissions multiple times in a row. >>> 2. Notice that the repair permissions log states that the permissions >>> for certain files need repair over and over again (seemingly never get >>> actually actually "fixed"). >>> 3. Examine the receipt BOMs and note that those very files are actually >>> mentioned in more than one receipt's BOM with differing permissions. >>> >>> No, I'm not going to do this exercise and document it for you. I don't >>> care whether you ignorantly claim this isn't the case. Revel in your >>> ignorance for all I care. >>> >> >> Sorry, but all that demonstrates is that mistakes are being corrected. > > Nope, it illustrates that the design of the repair permissions facility is > faulty. You just can't accept it. > No. It doesn't illustrate that in the slightest.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2017-05-16 22:46 -0400 |
| Message-ID | <160520172246534682%nospam@nospam.invalid> |
| In reply to | #106961 |
In article <ofgbn3$p9c$3@news.datemas.de>, Alan Baker <alangbaker@telus.net> wrote: > >>>>>> there is no single 'correct' permission setting. > >>>>> > >>>>> Yep. In fact the glaring design fault of Repair Permissions is that it > >>>>> has no way to resolve the case where two different receipts have > >>>>> differing permission settings for a given file, which actually happens > >>>>> quite frequently. That means it's actually quite common for there to be > >>>>> disagreement (even between two *Apple* installs) about what the correct > >>>>> permissions should be for installed files. > >>>> > >>>> Cite, please... > >>> > >>> It's easily observed and confirmed: > >>> > >>> 1. Run repair permissions multiple times in a row. > >>> 2. Notice that the repair permissions log states that the permissions > >>> for certain files need repair over and over again (seemingly never get > >>> actually actually "fixed"). > >>> 3. Examine the receipt BOMs and note that those very files are actually > >>> mentioned in more than one receipt's BOM with differing permissions. > >>> > >>> No, I'm not going to do this exercise and document it for you. I don't > >>> care whether you ignorantly claim this isn't the case. Revel in your > >>> ignorance for all I care. > >>> > >> > >> Sorry, but all that demonstrates is that mistakes are being corrected. > > > > Nope, it illustrates that the design of the repair permissions facility is > > faulty. You just can't accept it. > > > > No. It doesn't illustrate that in the slightest. yes it does, and very clearly.
[toc] | [prev] | [next] | [standalone]
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2017-05-16 19:51 -0700 |
| Message-ID | <ofgdsf$tme$2@news.datemas.de> |
| In reply to | #106963 |
On 2017-05-16 7:46 PM, nospam wrote: > In article <ofgbn3$p9c$3@news.datemas.de>, Alan Baker > <alangbaker@telus.net> wrote: > >>>>>>>> there is no single 'correct' permission setting. >>>>>>> >>>>>>> Yep. In fact the glaring design fault of Repair Permissions is that it >>>>>>> has no way to resolve the case where two different receipts have >>>>>>> differing permission settings for a given file, which actually happens >>>>>>> quite frequently. That means it's actually quite common for there to be >>>>>>> disagreement (even between two *Apple* installs) about what the correct >>>>>>> permissions should be for installed files. >>>>>> >>>>>> Cite, please... >>>>> >>>>> It's easily observed and confirmed: >>>>> >>>>> 1. Run repair permissions multiple times in a row. >>>>> 2. Notice that the repair permissions log states that the permissions >>>>> for certain files need repair over and over again (seemingly never get >>>>> actually actually "fixed"). >>>>> 3. Examine the receipt BOMs and note that those very files are actually >>>>> mentioned in more than one receipt's BOM with differing permissions. >>>>> >>>>> No, I'm not going to do this exercise and document it for you. I don't >>>>> care whether you ignorantly claim this isn't the case. Revel in your >>>>> ignorance for all I care. >>>>> >>>> >>>> Sorry, but all that demonstrates is that mistakes are being corrected. >>> >>> Nope, it illustrates that the design of the repair permissions facility is >>> faulty. You just can't accept it. >>> >> >> No. It doesn't illustrate that in the slightest. > > yes it does, and very clearly. > No. The fact that it is convenient to simply let the repair permissions utility change permissions more than once rather than do it some other way doesn't change the fact that the permissions still get set properly in the end.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2017-05-16 23:41 -0400 |
| Message-ID | <160520172341502510%nospam@nospam.invalid> |
| In reply to | #106964 |
In article <ofgdsf$tme$2@news.datemas.de>, Alan Baker <alangbaker@telus.net> wrote: > >>>>>>>> there is no single 'correct' permission setting. > >>>>>>> > >>>>>>> Yep. In fact the glaring design fault of Repair Permissions is that it > >>>>>>> has no way to resolve the case where two different receipts have > >>>>>>> differing permission settings for a given file, which actually happens > >>>>>>> quite frequently. That means it's actually quite common for there to > >>>>>>> be > >>>>>>> disagreement (even between two *Apple* installs) about what the > >>>>>>> correct > >>>>>>> permissions should be for installed files. > >>>>>> > >>>>>> Cite, please... > >>>>> > >>>>> It's easily observed and confirmed: > >>>>> > >>>>> 1. Run repair permissions multiple times in a row. > >>>>> 2. Notice that the repair permissions log states that the permissions > >>>>> for certain files need repair over and over again (seemingly never get > >>>>> actually actually "fixed"). > >>>>> 3. Examine the receipt BOMs and note that those very files are actually > >>>>> mentioned in more than one receipt's BOM with differing permissions. > >>>>> > >>>>> No, I'm not going to do this exercise and document it for you. I don't > >>>>> care whether you ignorantly claim this isn't the case. Revel in your > >>>>> ignorance for all I care. > >>>>> > >>>> > >>>> Sorry, but all that demonstrates is that mistakes are being corrected. > >>> > >>> Nope, it illustrates that the design of the repair permissions facility is > >>> faulty. You just can't accept it. > >>> > >> > >> No. It doesn't illustrate that in the slightest. > > > > yes it does, and very clearly. > > No. The fact that it is convenient to simply let the repair permissions > utility change permissions more than once rather than do it some other > way doesn't change the fact that the permissions still get set properly > in the end. you clearly don't understand what permission repair does. the simple fact that it flip-flops permissions on the *same* files is proof that not only does it not know which one is correct, but that it's also a waste of time.
[toc] | [prev] | [next] | [standalone]
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2017-05-17 09:00 -0700 |
| Message-ID | <ofhs3a$10cp$2@gioia.aioe.org> |
| In reply to | #106965 |
On 2017-05-16 8:41 PM, nospam wrote: > In article <ofgdsf$tme$2@news.datemas.de>, Alan Baker > <alangbaker@telus.net> wrote: > >>>>>>>>>> there is no single 'correct' permission setting. >>>>>>>>> >>>>>>>>> Yep. In fact the glaring design fault of Repair Permissions is that it >>>>>>>>> has no way to resolve the case where two different receipts have >>>>>>>>> differing permission settings for a given file, which actually happens >>>>>>>>> quite frequently. That means it's actually quite common for there to >>>>>>>>> be >>>>>>>>> disagreement (even between two *Apple* installs) about what the >>>>>>>>> correct >>>>>>>>> permissions should be for installed files. >>>>>>>> >>>>>>>> Cite, please... >>>>>>> >>>>>>> It's easily observed and confirmed: >>>>>>> >>>>>>> 1. Run repair permissions multiple times in a row. >>>>>>> 2. Notice that the repair permissions log states that the permissions >>>>>>> for certain files need repair over and over again (seemingly never get >>>>>>> actually actually "fixed"). >>>>>>> 3. Examine the receipt BOMs and note that those very files are actually >>>>>>> mentioned in more than one receipt's BOM with differing permissions. >>>>>>> >>>>>>> No, I'm not going to do this exercise and document it for you. I don't >>>>>>> care whether you ignorantly claim this isn't the case. Revel in your >>>>>>> ignorance for all I care. >>>>>>> >>>>>> >>>>>> Sorry, but all that demonstrates is that mistakes are being corrected. >>>>> >>>>> Nope, it illustrates that the design of the repair permissions facility is >>>>> faulty. You just can't accept it. >>>>> >>>> >>>> No. It doesn't illustrate that in the slightest. >>> >>> yes it does, and very clearly. >> >> No. The fact that it is convenient to simply let the repair permissions >> utility change permissions more than once rather than do it some other >> way doesn't change the fact that the permissions still get set properly >> in the end. > > you clearly don't understand what permission repair does. > > the simple fact that it flip-flops permissions on the *same* files is > proof that not only does it not know which one is correct, but that > it's also a waste of time. > No. That is NOT proof of that. It proves that someone changed their mind about what the permissions should be. That's all.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2017-05-17 12:41 -0400 |
| Message-ID | <170520171241207870%nospam@nospam.invalid> |
| In reply to | #106979 |
In article <ofhs3a$10cp$2@gioia.aioe.org>, Alan Baker <alangbaker@telus.net> wrote: > >>>>>>>>>> there is no single 'correct' permission setting. > >>>>>>>>> > >>>>>>>>> Yep. In fact the glaring design fault of Repair Permissions is that > >>>>>>>>> it > >>>>>>>>> has no way to resolve the case where two different receipts have > >>>>>>>>> differing permission settings for a given file, which actually > >>>>>>>>> happens > >>>>>>>>> quite frequently. That means it's actually quite common for there to > >>>>>>>>> be > >>>>>>>>> disagreement (even between two *Apple* installs) about what the > >>>>>>>>> correct > >>>>>>>>> permissions should be for installed files. > >>>>>>>> > >>>>>>>> Cite, please... > >>>>>>> > >>>>>>> It's easily observed and confirmed: > >>>>>>> > >>>>>>> 1. Run repair permissions multiple times in a row. > >>>>>>> 2. Notice that the repair permissions log states that the permissions > >>>>>>> for certain files need repair over and over again (seemingly never get > >>>>>>> actually actually "fixed"). > >>>>>>> 3. Examine the receipt BOMs and note that those very files are > >>>>>>> actually > >>>>>>> mentioned in more than one receipt's BOM with differing permissions. > >>>>>>> > >>>>>>> No, I'm not going to do this exercise and document it for you. I don't > >>>>>>> care whether you ignorantly claim this isn't the case. Revel in your > >>>>>>> ignorance for all I care. > >>>>>>> > >>>>>> > >>>>>> Sorry, but all that demonstrates is that mistakes are being corrected. > >>>>> > >>>>> Nope, it illustrates that the design of the repair permissions facility > >>>>> is faulty. You just can't accept it. > >>>>> > >>>> > >>>> No. It doesn't illustrate that in the slightest. > >>> > >>> yes it does, and very clearly. > >> > >> No. The fact that it is convenient to simply let the repair permissions > >> utility change permissions more than once rather than do it some other > >> way doesn't change the fact that the permissions still get set properly > >> in the end. > > > > you clearly don't understand what permission repair does. > > > > the simple fact that it flip-flops permissions on the *same* files is > > proof that not only does it not know which one is correct, but that > > it's also a waste of time. > > > > No. That is NOT proof of that. > > It proves that someone changed their mind about what the permissions > should be. That's all. which means there is no single correct value. thanks for playing.
[toc] | [prev] | [next] | [standalone]
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2017-05-17 09:45 -0700 |
| Message-ID | <ofhun5$j5f$1@news.datemas.de> |
| In reply to | #106981 |
On 2017-05-17 9:41 AM, nospam wrote: > In article <ofhs3a$10cp$2@gioia.aioe.org>, Alan Baker > <alangbaker@telus.net> wrote: > >>>>>>>>>>>> there is no single 'correct' permission setting. >>>>>>>>>>> >>>>>>>>>>> Yep. In fact the glaring design fault of Repair Permissions is that >>>>>>>>>>> it >>>>>>>>>>> has no way to resolve the case where two different receipts have >>>>>>>>>>> differing permission settings for a given file, which actually >>>>>>>>>>> happens >>>>>>>>>>> quite frequently. That means it's actually quite common for there to >>>>>>>>>>> be >>>>>>>>>>> disagreement (even between two *Apple* installs) about what the >>>>>>>>>>> correct >>>>>>>>>>> permissions should be for installed files. >>>>>>>>>> >>>>>>>>>> Cite, please... >>>>>>>>> >>>>>>>>> It's easily observed and confirmed: >>>>>>>>> >>>>>>>>> 1. Run repair permissions multiple times in a row. >>>>>>>>> 2. Notice that the repair permissions log states that the permissions >>>>>>>>> for certain files need repair over and over again (seemingly never get >>>>>>>>> actually actually "fixed"). >>>>>>>>> 3. Examine the receipt BOMs and note that those very files are >>>>>>>>> actually >>>>>>>>> mentioned in more than one receipt's BOM with differing permissions. >>>>>>>>> >>>>>>>>> No, I'm not going to do this exercise and document it for you. I don't >>>>>>>>> care whether you ignorantly claim this isn't the case. Revel in your >>>>>>>>> ignorance for all I care. >>>>>>>>> >>>>>>>> >>>>>>>> Sorry, but all that demonstrates is that mistakes are being corrected. >>>>>>> >>>>>>> Nope, it illustrates that the design of the repair permissions facility >>>>>>> is faulty. You just can't accept it. >>>>>>> >>>>>> >>>>>> No. It doesn't illustrate that in the slightest. >>>>> >>>>> yes it does, and very clearly. >>>> >>>> No. The fact that it is convenient to simply let the repair permissions >>>> utility change permissions more than once rather than do it some other >>>> way doesn't change the fact that the permissions still get set properly >>>> in the end. >>> >>> you clearly don't understand what permission repair does. >>> >>> the simple fact that it flip-flops permissions on the *same* files is >>> proof that not only does it not know which one is correct, but that >>> it's also a waste of time. >>> >> >> No. That is NOT proof of that. >> >> 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). > > thanks for playing. >
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2017-05-17 12:50 -0400 |
| Message-ID | <170520171250441736%nospam@nospam.invalid> |
| In reply to | #106982 |
In article <ofhun5$j5f$1@news.datemas.de>, Alan Baker <alangbaker@telus.net> wrote: > >>>>>>>>> > >>>>>>>> > >>>>>>>> Sorry, but all that demonstrates is that mistakes are being > >>>>>>>> corrected. > >>>>>>> > >>>>>>> Nope, it illustrates that the design of the repair permissions > >>>>>>> facility > >>>>>>> is faulty. You just can't accept it. > >>>>>>> > >>>>>> > >>>>>> No. It doesn't illustrate that in the slightest. > >>>>> > >>>>> yes it does, and very clearly. > >>>> > >>>> No. The fact that it is convenient to simply let the repair permissions > >>>> utility change permissions more than once rather than do it some other > >>>> way doesn't change the fact that the permissions still get set properly > >>>> in the end. > >>> > >>> you clearly don't understand what permission repair does. > >>> > >>> the simple fact that it flip-flops permissions on the *same* files is > >>> proof that not only does it not know which one is correct, but that > >>> it's also a waste of time. > >>> > >> > >> No. That is NOT proof of that. > >> > >> 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.
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.sys.mac.system
csiph-web