info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Formatting a USB Stick as FAT32
201 views
Skip to first unread message
Davoud
Jun 14, 2016, 10:10:13 PM6/14/16
to
On at least one of my Macs the system is /apparently/ not equivalent to
Windows in formatting a USB stick as FAT32.
I have always had success formatting USB sticks as FAT32 from Mac OS.
By "success" I mean that others and myself have been able read and
write to the FAT32 sticks from a variety of Mac OS and Windows
computers without apparent errors.
I recently bought a car that allows uploading startup-screen photos to
its 12.3-in. GPS/Audio/Etc. display. It requires that a FAT32 drive be
inserted into either of two USB ports in the center console. The drive
must contain a top-level folder named "Image" that contains jpg (or
jpeg) images. I formatted a USB drive as FAT32 under El Capitan and
followed all instructions to the letter. Upon inserting the stick in
the USB port the car's electronics apparently recognized it, reporting
(correctly) that no music files were on the drive. When I went to the
"Upload Photos" menu the system reported that no photos could be found.
After a couple of tries I booted my MBP in Win 7 Pro. I reformatted the
drive and copied the "Images" directory from within Win 7. This time
the car recognized the "Images" folder and quickly uploaded the images.
That done, I rebooted El Capitan and repeated the process--formatting,
etc.--and the car again could not read the drive. Curiously, the car
manufacturer's instructional video shows a man copying files to the
drive from a MacBook Pro (but says nothing about where the drive was
formatted).
Anyone know what gives here?
TIA!
--
I agree with almost everything that you have said and almost everything that
you will say in your entire life.
usenet *at* davidillig dawt cawm
Windows in formatting a USB stick as FAT32.
I have always had success formatting USB sticks as FAT32 from Mac OS.
By "success" I mean that others and myself have been able read and
write to the FAT32 sticks from a variety of Mac OS and Windows
computers without apparent errors.
I recently bought a car that allows uploading startup-screen photos to
its 12.3-in. GPS/Audio/Etc. display. It requires that a FAT32 drive be
inserted into either of two USB ports in the center console. The drive
must contain a top-level folder named "Image" that contains jpg (or
jpeg) images. I formatted a USB drive as FAT32 under El Capitan and
followed all instructions to the letter. Upon inserting the stick in
the USB port the car's electronics apparently recognized it, reporting
(correctly) that no music files were on the drive. When I went to the
"Upload Photos" menu the system reported that no photos could be found.
After a couple of tries I booted my MBP in Win 7 Pro. I reformatted the
drive and copied the "Images" directory from within Win 7. This time
the car recognized the "Images" folder and quickly uploaded the images.
That done, I rebooted El Capitan and repeated the process--formatting,
etc.--and the car again could not read the drive. Curiously, the car
manufacturer's instructional video shows a man copying files to the
drive from a MacBook Pro (but says nothing about where the drive was
formatted).
Anyone know what gives here?
TIA!
--
I agree with almost everything that you have said and almost everything that
you will say in your entire life.
usenet *at* davidillig dawt cawm
David Empson
Jun 14, 2016, 10:35:34 PM6/14/16
to
drive which throw the car's file management into confusion. For example,
.DS_Store, and extended attributes in "._xxx" files which as far as the
car is concerned claim to be photos (e.g. they have a ".jpg" extension).
Windows wouldn't put anything like that on the drive.
Solution: use a Mac utility which deletes any such files before the
drive is ejeced. BlueHarvest comes to mind, and I've also come across
CleanMyDrive.
That might not be a complete solution, because there could be root-level
folders such as .Trashes and .Spotlight-V100 which the utility can't
delete, but they may be far enough out of the way to not cause problems.
--
David Empson
dem...@actrix.gen.nz
Davoud
Jun 14, 2016, 11:20:40 PM6/14/16
to
Davoud:
David Empson:
Unix shell, but I ran ls -a and found .Spotlight-V100, ._.Trashes,
.Trashes, and .fseventsd. I ran rm -r and seem to have gotten rid of
everything. I'll try this USB stick tomorrow and also your suggestion
if what I did doesn't work.
I did learn that once the drive had been formatted under Win 7 I could
copy the jpg's from Mac OS and the car system read them OK.
> > On at least one of my Macs the system is /apparently/ not equivalent to
> > Windows in formatting a USB stick as FAT32....
David Empson:
> This might be a case of Finder putting hidden metadata files on the
> drive which throw the car's file management into confusion. For example,
> .DS_Store, and extended attributes in "._xxx" files which as far as the
> car is concerned claim to be photos (e.g. they have a ".jpg" extension).
>
> Windows wouldn't put anything like that on the drive.
>
> Solution: use a Mac utility which deletes any such files before the
> drive is ejeced. BlueHarvest comes to mind, and I've also come across
> CleanMyDrive.
>
> That might not be a complete solution, because there could be root-level
> folders such as .Trashes and .Spotlight-V100 which the utility can't
> delete, but they may be far enough out of the way to not cause problems.
Thanks. I hadn't thought of invisible files. I'm not much at using the
> drive which throw the car's file management into confusion. For example,
> .DS_Store, and extended attributes in "._xxx" files which as far as the
> car is concerned claim to be photos (e.g. they have a ".jpg" extension).
>
> Windows wouldn't put anything like that on the drive.
>
> Solution: use a Mac utility which deletes any such files before the
> drive is ejeced. BlueHarvest comes to mind, and I've also come across
> CleanMyDrive.
>
> That might not be a complete solution, because there could be root-level
> folders such as .Trashes and .Spotlight-V100 which the utility can't
> delete, but they may be far enough out of the way to not cause problems.
Unix shell, but I ran ls -a and found .Spotlight-V100, ._.Trashes,
.Trashes, and .fseventsd. I ran rm -r and seem to have gotten rid of
everything. I'll try this USB stick tomorrow and also your suggestion
if what I did doesn't work.
I did learn that once the drive had been formatted under Win 7 I could
copy the jpg's from Mac OS and the car system read them OK.
Your Name
Jun 15, 2016, 12:13:18 AM6/15/16
to
In article <1mow2yd.c86ja1d8ut1zN%dem...@actrix.gen.nz>, David Empson
It's been a while since I used BlueHarvest (to make a pile of freebie
USB drives for a promotion), but I'm pretty sure that it removed the
.Trashes and .Spotlight-V100 folders as well (I have a vague
recollection of needing to turn on a preference option in it to do so)
... but it was an old version of both OS X and BlueHarvest, so maybe
newer changes to OS X have stopped that working.
Apple really needs to include such an option at the OS level. Those
extra files can be annoying when you constantly have to tell Windoze
users that it's not the "._" file they should be opening when they
complain that the file is "corrupt". :-\
USB drives for a promotion), but I'm pretty sure that it removed the
.Trashes and .Spotlight-V100 folders as well (I have a vague
recollection of needing to turn on a preference option in it to do so)
... but it was an old version of both OS X and BlueHarvest, so maybe
newer changes to OS X have stopped that working.
Apple really needs to include such an option at the OS level. Those
extra files can be annoying when you constantly have to tell Windoze
users that it's not the "._" file they should be opening when they
complain that the file is "corrupt". :-\
JF Mezei
Jun 15, 2016, 1:33:47 AM6/15/16
to
On 2016-06-14 22:10, Davoud wrote:
> On at least one of my Macs the system is /apparently/ not equivalent to
> Windows in formatting a USB stick as FAT32.
You need diskutil at command line for it. It supports greater range of
> On at least one of my Macs the system is /apparently/ not equivalent to
> Windows in formatting a USB stick as FAT32.
file systems than the GUI diskutil.
diskutil listFilesystems => list supported filesystems
ls /Volumes to find the name of your existing drive.
diskutil erasevolume FAT32 NEWNAME /Volumes/ExistingDisk/
(MSDOS volume names need to be uppercase it appears).
JF Mezei
Jun 15, 2016, 1:41:30 AM6/15/16
to
On 2016-06-14 22:35, David Empson wrote:
> This might be a case of Finder putting hidden metadata files on the
> drive which throw the car's file management into confusion.
That confuses my GPS and prevents it from booting.
> This might be a case of Finder putting hidden metadata files on the
> drive which throw the car's file management into confusion.
So afrer mounting the GPS card on my Mac and doing what I needed to do:
cd /Volumes/MYGPS
ls -a
rm -v -R .*
(you may have to do this twice).
The files that get created behind the scenes: (actually directories)
.Spotlight-V100 .Trashes ._.Trashes .fseventsd
once done:
cd ~
diskutil unmount /Volumes/MYGPS
(when your current directory is on that device, the directopry file is
conidered "opened" and the volume can't be unmounted).
Neill Massello
Jun 15, 2016, 3:07:22 AM6/15/16
to
David Empson <dem...@actrix.gen.nz> wrote:
> Solution: use a Mac utility which deletes any such files before the
> drive is ejeced. BlueHarvest comes to mind, and I've also come across
> CleanMyDrive.
>
> That might not be a complete solution, because there could be root-level
> folders such as .Trashes and .Spotlight-V100 which the utility can't
> delete, but they may be far enough out of the way to not cause problems.
TinkerTool System kills them all.
> Solution: use a Mac utility which deletes any such files before the
> drive is ejeced. BlueHarvest comes to mind, and I've also come across
> CleanMyDrive.
>
> That might not be a complete solution, because there could be root-level
> folders such as .Trashes and .Spotlight-V100 which the utility can't
> delete, but they may be far enough out of the way to not cause problems.
<http://www.bresink.com/osx/TinkerToolSys4.html>
Lewis
Jun 15, 2016, 12:02:11 PM6/15/16
to
In message <140620162210100599%st...@sky.net>
> I recently bought a car that allows uploading startup-screen photos to
> its 12.3-in. GPS/Audio/Etc. display. It requires that a FAT32 drive be
> inserted into either of two USB ports in the center console. The drive
> must contain a top-level folder named "Image" that contains jpg (or
> jpeg) images. I formatted a USB drive as FAT32 under El Capitan and
> followed all instructions to the letter. Upon inserting the stick in
> the USB port the car's electronics apparently recognized it, reporting
> (correctly) that no music files were on the drive. When I went to the
> "Upload Photos" menu the system reported that no photos could be found.
Probably you car is confused by the existence of dot files.
> After a couple of tries I booted my MBP in Win 7 Pro. I reformatted the
> drive and copied the "Images" directory from within Win 7. This time
> the car recognized the "Images" folder and quickly uploaded the images.
See above.
--
The very existence of flame-throwers proves that some time, somewhere,
someone said to themselves, You know, I want to set those people over
there on fire, but I'm just not close enough to get the job done.
Davoud <st...@sky.net> wrote:
> On at least one of my Macs the system is /apparently/ not equivalent to
> Windows in formatting a USB stick as FAT32.
> I have always had success formatting USB sticks as FAT32 from Mac OS.
> By "success" I mean that others and myself have been able read and
> write to the FAT32 sticks from a variety of Mac OS and Windows
> computers without apparent errors.
Yes, though I use exFAT now for most everything.
> On at least one of my Macs the system is /apparently/ not equivalent to
> Windows in formatting a USB stick as FAT32.
> I have always had success formatting USB sticks as FAT32 from Mac OS.
> By "success" I mean that others and myself have been able read and
> write to the FAT32 sticks from a variety of Mac OS and Windows
> computers without apparent errors.
> I recently bought a car that allows uploading startup-screen photos to
> its 12.3-in. GPS/Audio/Etc. display. It requires that a FAT32 drive be
> inserted into either of two USB ports in the center console. The drive
> must contain a top-level folder named "Image" that contains jpg (or
> jpeg) images. I formatted a USB drive as FAT32 under El Capitan and
> followed all instructions to the letter. Upon inserting the stick in
> the USB port the car's electronics apparently recognized it, reporting
> (correctly) that no music files were on the drive. When I went to the
> "Upload Photos" menu the system reported that no photos could be found.
> After a couple of tries I booted my MBP in Win 7 Pro. I reformatted the
> drive and copied the "Images" directory from within Win 7. This time
> the car recognized the "Images" folder and quickly uploaded the images.
--
The very existence of flame-throwers proves that some time, somewhere,
someone said to themselves, You know, I want to set those people over
there on fire, but I'm just not close enough to get the job done.
Lewis
Jun 15, 2016, 12:02:45 PM6/15/16
to
In message <5760e8b9$0$34678$c3e8da3$dbd...@news.astraweb.com>
--
'If you sow dragons' teeth, you should get dragons. Not fighting
skeletons. What did it say on the packet?' 'I don't know! The myth never
said anything about them coming in a packet!' 'Should have said "Comes
up Dragons" on the packet.'
JF Mezei <jfmezei...@vaxination.ca> wrote:
> On 2016-06-14 22:10, Davoud wrote:
>> On at least one of my Macs the system is /apparently/ not equivalent to
>> Windows in formatting a USB stick as FAT32.
> You need diskutil at command line for it. It supports greater range of
> file systems than the GUI diskutil.
No you don't.
> On 2016-06-14 22:10, Davoud wrote:
>> On at least one of my Macs the system is /apparently/ not equivalent to
>> Windows in formatting a USB stick as FAT32.
> You need diskutil at command line for it. It supports greater range of
> file systems than the GUI diskutil.
--
'If you sow dragons' teeth, you should get dragons. Not fighting
skeletons. What did it say on the packet?' 'I don't know! The myth never
said anything about them coming in a packet!' 'Should have said "Comes
up Dragons" on the packet.'
Jolly Roger
Jun 15, 2016, 12:24:44 PM6/15/16
to
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
>
> Probably you car is confused by the existence of dot files.
Software that malfunctions due to the mere existence of extraneous files is
>
> Probably you car is confused by the existence of dot files.
pretty crappy software.
--
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
nospam
Jun 15, 2016, 12:27:28 PM6/15/16
to
In article <dsddq8...@mid.individual.net>, Jolly Roger
<jolly...@pobox.com> wrote:
> > Probably you car is confused by the existence of dot files.
>
> Software that malfunctions due to the mere existence of extraneous files is
> pretty crappy software.
there's a lot of crappy software out there.
> > Probably you car is confused by the existence of dot files.
>
> Software that malfunctions due to the mere existence of extraneous files is
> pretty crappy software.
Lewis
Jun 15, 2016, 1:27:31 PM6/15/16
to
In message <dsddq8...@mid.individual.net>
My after-market car stereo, when the rear camera is activated, says
"Check behind for safety with your eyes."
The firmware has been updated twice. Still says that.
--
The truth may be out there, but lies are inside your head. --Hogfather
Jolly Roger <jolly...@pobox.com> wrote:
> Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
>>
>> Probably you car is confused by the existence of dot files.
> Software that malfunctions due to the mere existence of extraneous files is
> pretty crappy software.
All all car software is *very* crappy.
> Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
>>
>> Probably you car is confused by the existence of dot files.
> Software that malfunctions due to the mere existence of extraneous files is
> pretty crappy software.
My after-market car stereo, when the rear camera is activated, says
"Check behind for safety with your eyes."
The firmware has been updated twice. Still says that.
--
The truth may be out there, but lies are inside your head. --Hogfather
JF Mezei
Jun 15, 2016, 2:01:26 PM6/15/16
to
On 2016-06-15 12:24, Jolly Roger wrote:
> Software that malfunctions due to the mere existence of extraneous files is
> pretty crappy software.
a lot of embedded software may expect a file system that is populated
> Software that malfunctions due to the mere existence of extraneous files is
> pretty crappy software.
with files that fit the DOS 8.3.
Encountering a directory called .fseventsd would make such embedded
software barf (no file name, and an extension that is way too long).
Jolly Roger
Jun 15, 2016, 5:29:18 PM6/15/16
to
On 2016-06-15, JF Mezei <jfmezei...@vaxination.ca> wrote:
> On 2016-06-15 12:24, Jolly Roger wrote:
>
>> Software that malfunctions due to the mere existence of extraneous files is
>> pretty crappy software.
>
> a lot of embedded software may expect a file system that is populated
> with files that fit the DOS 8.3.
Extraneous files on a USB stick shouldn't cause software to malfunction
> On 2016-06-15 12:24, Jolly Roger wrote:
>
>> Software that malfunctions due to the mere existence of extraneous files is
>> pretty crappy software.
>
> a lot of embedded software may expect a file system that is populated
> with files that fit the DOS 8.3.
since it doesn't need access to those files for opertion.
> Encountering a directory called .fseventsd would make such embedded
> software barf (no file name, and an extension that is way too long).
JF Mezei
Jun 15, 2016, 5:37:42 PM6/15/16
to
On 2016-06-15 17:29, Jolly Roger wrote:
> Extraneous files on a USB stick shouldn't cause software to malfunction
> since it doesn't need access to those files for opertion.
At boot many devices scan the storage medium for all files. Software
> Extraneous files on a USB stick shouldn't cause software to malfunction
> since it doesn't need access to those files for opertion.
updates process kicks in if it finds a file with specific file
extension. (and this happens at very early stage in power up so that
system files not yet used.
> Then it's crappy software.
foreign file formats.
Can't expect a device which uses FAT to be coded to expect unix filenames.
Davoud
Jun 15, 2016, 5:46:20 PM6/15/16
to
JF Mezei:
extension; the dot signifies that the directory is an invisible one.
> Encountering a directory called .fseventsd would make such embedded
> software barf (no file name, and an extension that is way too long).
As you point out, that's a directory name. It's not an overly long
> software barf (no file name, and an extension that is way too long).
extension; the dot signifies that the directory is an invisible one.
JF Mezei
Jun 15, 2016, 6:28:18 PM6/15/16
to
On 2016-06-15 17:46, Davoud wrote:
> As you point out, that's a directory name. It's not an overly long
> extension; the dot signifies that the directory is an invisible one.
OS-X (and Unix) treat a filename that begins with a dot as hidden.
> As you point out, that's a directory name. It's not an overly long
> extension; the dot signifies that the directory is an invisible one.
But some embedded device which doesn't run Unix/OS-X and expects a DOS
filename specification can easily barf on that. These devices are not
general purpose computers, they likely have verry narrow coding with
regards to accessing a file system.
JF Mezei
Jun 15, 2016, 6:29:48 PM6/15/16
to
On 2016-06-15 17:48, Tim Streater wrote:
> In article <5761caa3$0$9145$c3e8da3$5d8f...@news.astraweb.com>, JF
I agree. But if the company who built the device did not think about the
possibilityy that the storage medium would be mounted on a Mac which
adds files to it, it wouldn't think about coding the file system access
routines to ignore such files.
> In article <5761caa3$0$9145$c3e8da3$5d8f...@news.astraweb.com>, JF
> Mezei <jfmezei...@vaxination.ca> wrote:
>
>>Can't expect a device which uses FAT to be coded to expect unix filenames.
>
> It can simply ignore them.
>
>>Can't expect a device which uses FAT to be coded to expect unix filenames.
>
I agree. But if the company who built the device did not think about the
possibilityy that the storage medium would be mounted on a Mac which
adds files to it, it wouldn't think about coding the file system access
routines to ignore such files.
Jolly Roger
Jun 15, 2016, 10:19:07 PM6/15/16
to
On 2016-06-15, JF Mezei <jfmezei...@vaxination.ca> wrote:
> On 2016-06-15 17:29, Jolly Roger wrote:
>
>> Extraneous files on a USB stick shouldn't cause software to malfunction
>> since it doesn't need access to those files for opertion.
>
> At boot many devices scan the storage medium for all files. Software
> updates process kicks in if it finds a file with specific file
> extension. (and this happens at very early stage in power up so that
> system files not yet used.
Bad design.
>
>> Extraneous files on a USB stick shouldn't cause software to malfunction
>> since it doesn't need access to those files for opertion.
>
> At boot many devices scan the storage medium for all files. Software
> updates process kicks in if it finds a file with specific file
> extension. (and this happens at very early stage in power up so that
> system files not yet used.
>> Then it's crappy software.
>
> Sorry, but OS-X is crappy for installing its native control files onto
> foreign file formats.
> Can't expect a device which uses FAT to be coded to expect unix filenames.
malfunction simply because I placed some extraneous files on a USB
stick. OS X doesn't malfunction when I do it, and neither should other
operating systems. If they do, it's due to bad design.
Jolly Roger
Jun 15, 2016, 10:19:43 PM6/15/16
to
Jolly Roger
Jun 15, 2016, 10:20:30 PM6/15/16
to
Lewis
Jun 16, 2016, 12:01:56 AM6/16/16
to
In message <5761d6da$0$11913$c3e8da3$3a1a...@news.astraweb.com>
Ad we are back to "Crappy software" which you keep objecting too.
--
Traveling through hyperspace ain't like dusting crops, boy.
--
Traveling through hyperspace ain't like dusting crops, boy.
dorayme
Jun 16, 2016, 1:46:16 AM6/16/16
to
> Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> >
> > Probably you car is confused by the existence of dot files.
>
> Software that malfunctions due to the mere existence of extraneous files is
> pretty crappy software.
Maybe. My FAT USB sticks with files made on the Mac appear on the Sony
> >
> > Probably you car is confused by the existence of dot files.
>
> Software that malfunctions due to the mere existence of extraneous files is
> pretty crappy software.
TV fine and some can open and play as wanted and others (Mac specific
things like spotlight etc) just sit there harmlessly but cannot be
opened on the TV (nor would they be welcomed, the TV would probably
blow up or horrible people like Trump would step right out and cause
trouble in the lounge room, who knows?)
--
dorayme
Your Name
Jun 16, 2016, 2:51:18 AM6/16/16
to
In article <mev94303y-7EF77...@news.individual.net>,
Michael Vilain <mev9...@yahoo.com> wrote:
> In article <dsegko...@mid.individual.net>,
> and you have to take it. Or you can rip out the thing and install
> something you designed. Or you can pull the eprom (you may have to
> desoder it with ChipQuic), dup it, and re-write it. A friend did that
> with his Tevo so he could record whatever he wanted.
>
> Kvetch all you want. It won't do any good. But thank you for sharing.
The software isn't malfunctioning ... it's almost certainly simply
trying to load the wrong file. Instead of Image.jpg, the software is
trying to load the Mac OS X system file ._Image.jpg which it thinks is
an image file due to the filename extension.
Michael Vilain <mev9...@yahoo.com> wrote:
> In article <dsegko...@mid.individual.net>,
> Jolly Roger <jolly...@pobox.com> wrote:
> > On 2016-06-15, JF Mezei <jfmezei...@vaxination.ca> wrote:
> > > On 2016-06-15 17:29, Jolly Roger wrote:
> > >>
> > >> Extraneous files on a USB stick shouldn't cause software to malfunction
> > >> since it doesn't need access to those files for opertion.
> > >
> > > At boot many devices scan the storage medium for all files. Software
> > > updates process kicks in if it finds a file with specific file
> > > extension. (and this happens at very early stage in power up so that
> > > system files not yet used.
> >
> > Bad design.
> >
> > >> Then it's crappy software.
> > >
> > > Sorry, but OS-X is crappy for installing its native control files onto
> > > foreign file formats.
> >
> > Irrelevant, and two wrongs don't make a right anyway.
> >
> > > Can't expect a device which uses FAT to be coded to expect unix filenames.
> >
> > I don't expect a device or any standard file system software to
> > malfunction simply because I placed some extraneous files on a USB
> > stick. OS X doesn't malfunction when I do it, and neither should other
> > operating systems. If they do, it's due to bad design.
>
> It's an embedded system. The vendor can do whatever the fuck they want
> > On 2016-06-15, JF Mezei <jfmezei...@vaxination.ca> wrote:
> > > On 2016-06-15 17:29, Jolly Roger wrote:
> > >>
> > >> Extraneous files on a USB stick shouldn't cause software to malfunction
> > >> since it doesn't need access to those files for opertion.
> > >
> > > At boot many devices scan the storage medium for all files. Software
> > > updates process kicks in if it finds a file with specific file
> > > extension. (and this happens at very early stage in power up so that
> > > system files not yet used.
> >
> > Bad design.
> >
> > >> Then it's crappy software.
> > >
> > > Sorry, but OS-X is crappy for installing its native control files onto
> > > foreign file formats.
> >
> > Irrelevant, and two wrongs don't make a right anyway.
> >
> > > Can't expect a device which uses FAT to be coded to expect unix filenames.
> >
> > I don't expect a device or any standard file system software to
> > malfunction simply because I placed some extraneous files on a USB
> > stick. OS X doesn't malfunction when I do it, and neither should other
> > operating systems. If they do, it's due to bad design.
>
> and you have to take it. Or you can rip out the thing and install
> something you designed. Or you can pull the eprom (you may have to
> desoder it with ChipQuic), dup it, and re-write it. A friend did that
> with his Tevo so he could record whatever he wanted.
>
> Kvetch all you want. It won't do any good. But thank you for sharing.
The software isn't malfunctioning ... it's almost certainly simply
trying to load the wrong file. Instead of Image.jpg, the software is
trying to load the Mac OS X system file ._Image.jpg which it thinks is
an image file due to the filename extension.
Jolly Roger
Jun 16, 2016, 4:14:17 AM6/16/16
to
Michael Vilain <mev9...@yahoo.com> wrote:
> In article <dsegko...@mid.individual.net>,
> Jolly Roger <jolly...@pobox.com> wrote:
>
> In article <dsegko...@mid.individual.net>,
> Jolly Roger <jolly...@pobox.com> wrote:
>
>> On 2016-06-15, JF Mezei <jfmezei...@vaxination.ca> wrote:
>>> On 2016-06-15 17:29, Jolly Roger wrote:
>>>
>>>> Extraneous files on a USB stick shouldn't cause software to malfunction
>>>> since it doesn't need access to those files for opertion.
>>>
>>> At boot many devices scan the storage medium for all files. Software
>>> updates process kicks in if it finds a file with specific file
>>> extension. (and this happens at very early stage in power up so that
>>> system files not yet used.
>>
>> Bad design.
>>
>>>> Then it's crappy software.
>>>
>>> Sorry, but OS-X is crappy for installing its native control files onto
>>> foreign file formats.
>>
>> Irrelevant, and two wrongs don't make a right anyway.
>>
>>> Can't expect a device which uses FAT to be coded to expect unix filenames.
>>
>> I don't expect a device or any standard file system software to
>> malfunction simply because I placed some extraneous files on a USB
>> stick. OS X doesn't malfunction when I do it, and neither should other
>> operating systems. If they do, it's due to bad design.
>
>>> On 2016-06-15 17:29, Jolly Roger wrote:
>>>
>>>> Extraneous files on a USB stick shouldn't cause software to malfunction
>>>> since it doesn't need access to those files for opertion.
>>>
>>> At boot many devices scan the storage medium for all files. Software
>>> updates process kicks in if it finds a file with specific file
>>> extension. (and this happens at very early stage in power up so that
>>> system files not yet used.
>>
>> Bad design.
>>
>>>> Then it's crappy software.
>>>
>>> Sorry, but OS-X is crappy for installing its native control files onto
>>> foreign file formats.
>>
>> Irrelevant, and two wrongs don't make a right anyway.
>>
>>> Can't expect a device which uses FAT to be coded to expect unix filenames.
>>
>> I don't expect a device or any standard file system software to
>> malfunction simply because I placed some extraneous files on a USB
>> stick. OS X doesn't malfunction when I do it, and neither should other
>> operating systems. If they do, it's due to bad design.
>
> It's an embedded system. The vendor can do whatever the fuck they want
> and you have to take it.
I don't have to take anything. None of the few things I've plugged a USB
> and you have to take it.
stick into have ever malfunctioned due to extraneous files.
Jolly Roger
Jun 16, 2016, 4:19:17 AM6/16/16
to
Your Name <Your...@YourISP.com> wrote:
>
> The software isn't malfunctioning ... it's almost certainly simply
> trying to load the wrong file. Instead of Image.jpg, the software is
> trying to load the Mac OS X system file ._Image.jpg which it thinks is
> an image file due to the filename extension.
The malfunction is that it's unable to ignore the file and proceed from
>
> The software isn't malfunctioning ... it's almost certainly simply
> trying to load the wrong file. Instead of Image.jpg, the software is
> trying to load the Mac OS X system file ._Image.jpg which it thinks is
> an image file due to the filename extension.
there.
Davoud
Jun 16, 2016, 9:51:11 AM6/16/16
to
Jolly Roger:
> I don't recall if the OP specified the car's make and model, but I would
> guess that the embedded system they're running isn't very robust.
OP reports: It's a 2016 Lexus RX 350 AWD SUV*. Since the only "fault"
I've found with the voice-controlled nav/audio/climate/etc. system is
that it won't read custom startup-screen jpeg's from a FAT32 thumb
drive that was formatted in a certain one of my six Macs (I didn't try
the other five) I'm not ready to say that the system is not "robust."
There's a lot to like about the Lexus system, from the 12.3 inch
uncluttered map display with easy programming (destinations can be sent
to the nav system from a computer or mobile device via the car's
built-in cellular phone link even when the car is not running) to
built-in Siri** to the broad control that hands-free voice commands
allow with audio, including Sirius XM, navigation, climate, iPhone, and
other utilities.
* I traded a 2014 Subaru Forester for the Lexus. The Subaru was a great
car, IMO, though it lacked a bit in interior comfort and finish, and
most importantly, it had a useless nav system
<https://www.flickr.com/photos/primeval/8893582696> and a useless
rear-view camera that used a separate, small, poorly placed display
(both fixed for 2016, I'm told). The Subaru had a bit more cargo space
than the Lexus, while the Lexus has more passenger space and a much
higher level of creature comfort and quietness, fit and finish.
** Sorry, Android users. This is Apple's Siri, and it only works with
iPhone (and not iPad or iPod, though the latter two can play music via
the USB ports). Siri queries are limited to those that can be answered
verbally, as the idea is to keep the driver's eyes on the road. So you
can't ask for a map or a web page. That leaves a reasonably broad
range, however, from weather queries to sports to news, to sending and
receiving e-mails and texts (Siri reads incoming on command) to audio
playback. Apple Car Play is not included, but is coming via a third
party later in 2016. I'm going to give Car Play a miss, as the Lexus
system already does what I need it to do, and Lexus has its own
voice-controlled "Enform" app suite. I had Car Play in a previous car
and while it worked well enough, I didn't use it because I thought that
interacting with it was dangerously distracting.
> At least my Roku and Samsung blu-ray player can read MacOS-formatted
> thumb drives.
Blu-ray? How quaint! I have a working Edison cylinder talking machine
that I demonstrate to certain first-time visitors to my home, but it
can't stream over the Internet, so it's not something I rely on as a
main source of entertainment media. Roku is good, but I prefer Apple
TV's interaction with Mac OS. And, speaking of quaintness, the Lexus
contains a CD player. I have two 10-year old Toyotas in which the CD
players have never been used.
> > Then it's crappy software.
Michael Vilain:
> I don't recall if the OP specified the car's make and model, but I would
> guess that the embedded system they're running isn't very robust.
OP reports: It's a 2016 Lexus RX 350 AWD SUV*. Since the only "fault"
I've found with the voice-controlled nav/audio/climate/etc. system is
that it won't read custom startup-screen jpeg's from a FAT32 thumb
drive that was formatted in a certain one of my six Macs (I didn't try
the other five) I'm not ready to say that the system is not "robust."
There's a lot to like about the Lexus system, from the 12.3 inch
uncluttered map display with easy programming (destinations can be sent
to the nav system from a computer or mobile device via the car's
built-in cellular phone link even when the car is not running) to
built-in Siri** to the broad control that hands-free voice commands
allow with audio, including Sirius XM, navigation, climate, iPhone, and
other utilities.
* I traded a 2014 Subaru Forester for the Lexus. The Subaru was a great
car, IMO, though it lacked a bit in interior comfort and finish, and
most importantly, it had a useless nav system
<https://www.flickr.com/photos/primeval/8893582696> and a useless
rear-view camera that used a separate, small, poorly placed display
(both fixed for 2016, I'm told). The Subaru had a bit more cargo space
than the Lexus, while the Lexus has more passenger space and a much
higher level of creature comfort and quietness, fit and finish.
** Sorry, Android users. This is Apple's Siri, and it only works with
iPhone (and not iPad or iPod, though the latter two can play music via
the USB ports). Siri queries are limited to those that can be answered
verbally, as the idea is to keep the driver's eyes on the road. So you
can't ask for a map or a web page. That leaves a reasonably broad
range, however, from weather queries to sports to news, to sending and
receiving e-mails and texts (Siri reads incoming on command) to audio
playback. Apple Car Play is not included, but is coming via a third
party later in 2016. I'm going to give Car Play a miss, as the Lexus
system already does what I need it to do, and Lexus has its own
voice-controlled "Enform" app suite. I had Car Play in a previous car
and while it worked well enough, I didn't use it because I thought that
interacting with it was dangerously distracting.
> At least my Roku and Samsung blu-ray player can read MacOS-formatted
> thumb drives.
Blu-ray? How quaint! I have a working Edison cylinder talking machine
that I demonstrate to certain first-time visitors to my home, but it
can't stream over the Internet, so it's not something I rely on as a
main source of entertainment media. Roku is good, but I prefer Apple
TV's interaction with Mac OS. And, speaking of quaintness, the Lexus
contains a CD player. I have two 10-year old Toyotas in which the CD
players have never been used.
Happy.Hobo
Jun 16, 2016, 2:27:39 PM6/16/16
to
On 06-15-2016 07:41, JF Mezei wrote:
> So afrer mounting the GPS card on my Mac and doing what I needed to do:
>
> cd /Volumes/MYGPS
> ls -a
>
> rm -v -R .*
Try
> So afrer mounting the GPS card on my Mac and doing what I needed to do:
>
> cd /Volumes/MYGPS
> ls -a
>
> rm -v -R .*
rm -v -R .??*
Happy.Hobo
Jun 16, 2016, 4:47:53 PM6/16/16
to
On 06-15-2016 23:37, HF Mei wrote:
> On 2016-06-15 17:29, Jolly Roger wrote:
>
>> Extraneous files on a USB stick shouldn't cause software to malfunction
>> since it doesn't need access to those files for opertion.
>
> At boot many devices scan the storage medium for all files. Software
> updates process kicks in if it finds a file with specific file
> extension. (and this happens at very early stage in power up so that
> system files not yet used.
>
>> Then it's crappy software.
>
> Sorry, but OS-X is crappy for installing its native control files onto
> foreign file formats.
When you open a file with Finder, it's not very logical to expect Finder
> On 2016-06-15 17:29, Jolly Roger wrote:
>
>> Extraneous files on a USB stick shouldn't cause software to malfunction
>> since it doesn't need access to those files for opertion.
>
> At boot many devices scan the storage medium for all files. Software
> updates process kicks in if it finds a file with specific file
> extension. (and this happens at very early stage in power up so that
> system files not yet used.
>
>> Then it's crappy software.
>
> Sorry, but OS-X is crappy for installing its native control files onto
> foreign file formats.
to not create the files it uses to do what it's designed to do.
Happy.Hobo
Jun 16, 2016, 4:50:42 PM6/16/16
to
On 06-15-2016 23:29, Jolly Roger wrote:
> On 2016-06-15, JF Mezei <jfmezei...@vaxination.ca> wrote:
>> On 2016-06-15 12:24, Jolly Roger wrote:
>>
>>> Software that malfunctions due to the mere existence of extraneous files is
>>> pretty crappy software.
>>
>> a lot of embedded software may expect a file system that is populated
>> with files that fit the DOS 8.3.
>
> Extraneous files on a USB stick shouldn't cause software to malfunction
> since it doesn't need access to those files for opertion.
>
>> Encountering a directory called .fseventsd would make such embedded
>> software barf (no file name, and an extension that is way too long).
>
> Then it's crappy software.
There is a lot of that in the world. One can ignore it or complain
> On 2016-06-15, JF Mezei <jfmezei...@vaxination.ca> wrote:
>> On 2016-06-15 12:24, Jolly Roger wrote:
>>
>>> Software that malfunctions due to the mere existence of extraneous files is
>>> pretty crappy software.
>>
>> a lot of embedded software may expect a file system that is populated
>> with files that fit the DOS 8.3.
>
> Extraneous files on a USB stick shouldn't cause software to malfunction
> since it doesn't need access to those files for opertion.
>
>> Encountering a directory called .fseventsd would make such embedded
>> software barf (no file name, and an extension that is way too long).
>
> Then it's crappy software.
about it or change it. The first option is the easiest; the second
accomplishes little that's healthy.
Happy.Hobo
Jun 16, 2016, 4:55:33 PM6/16/16
to
On 06-16-2016 00:29, JF Mezei wrote:
> On 2016-06-15 17:48, Tim Streater wrote:
>> > In article <5761caa3$0$9145$c3e8da3$5d8f...@news.astraweb.com>, JF
>> > Mezei <jfmezei...@vaxination.ca> wrote:
>> >
>>> >>Can't expect a device which uses FAT to be coded to expect unix filenames.
Why not? Unix/Linux/Mac have been using FAT for decades.
> On 2016-06-15 17:48, Tim Streater wrote:
>> > In article <5761caa3$0$9145$c3e8da3$5d8f...@news.astraweb.com>, JF
>> > Mezei <jfmezei...@vaxination.ca> wrote:
>> >
>>> >>Can't expect a device which uses FAT to be coded to expect unix filenames.
>> > It can simply ignore them.
>
> I agree. But if the company who built the device did not think about the
> possibilityy that the storage medium would be mounted on a Mac which
> adds files to it, it wouldn't think about coding the file system access
> routines to ignore such files.
don't write code to look for them. But, if you write code to scan a
directory, you don't explicitly define your data structure to choke on
files that you _know_ might be there.
Happy.Hobo
Jun 16, 2016, 5:01:32 PM6/16/16
to
On 06-16-2016 00:28, JF Mezei wrote:
> But some embedded device which doesn't run Unix/OS-X and expects a DOS
> filename specification can easily barf on that. These devices are not
> general purpose computers, they likely have verry narrow coding with
> regards to accessing a file system.
Anyone who doesn't know that a lot of non-DOS systems¹ can read and
> But some embedded device which doesn't run Unix/OS-X and expects a DOS
> filename specification can easily barf on that. These devices are not
> general purpose computers, they likely have verry narrow coding with
> regards to accessing a file system.
write FAT and have done so for ages is not qualified to do any coding.
¹Such as Windows …
nospam
Jun 16, 2016, 5:30:30 PM6/16/16
to
In article <njv3o0$1p10$1...@gioia.aioe.org>, Happy.Hobo
> >> > It can simply ignore them.
> >
> > I agree. But if the company who built the device did not think about the
> > possibilityy that the storage medium would be mounted on a Mac which
> > adds files to it, it wouldn't think about coding the file system access
> > routines to ignore such files.
>
> You don't add code to ignore files. If you don't need those files, you
> don't write code to look for them. But, if you write code to scan a
> directory, you don't explicitly define your data structure to choke on
> files that you _know_ might be there.
normally, they aren't there, so there's no need to check.
only macs add invisible files on foreign file systems.
you can argue all day long about how it *should* work, but the reality
is that there are devices that will fail if a memory card or usb stick
is inserted after having used with a mac.
and it's not just devices failing. ask a sysadmin about all .ds_store
pollution left by macs that connect to a shared drive.
<Happy...@Spam.Invalid> wrote:
> >>> >>Can't expect a device which uses FAT to be coded to expect unix
> >>> >>filenames.
>
> Why not? Unix/Linux/Mac have been using FAT for decades.
because it's an embedded device, not a unix/linux/mac box.
> >>> >>Can't expect a device which uses FAT to be coded to expect unix
> >>> >>filenames.
>
> Why not? Unix/Linux/Mac have been using FAT for decades.
> >> > It can simply ignore them.
> >
> > I agree. But if the company who built the device did not think about the
> > possibilityy that the storage medium would be mounted on a Mac which
> > adds files to it, it wouldn't think about coding the file system access
> > routines to ignore such files.
>
> You don't add code to ignore files. If you don't need those files, you
> don't write code to look for them. But, if you write code to scan a
> directory, you don't explicitly define your data structure to choke on
> files that you _know_ might be there.
only macs add invisible files on foreign file systems.
you can argue all day long about how it *should* work, but the reality
is that there are devices that will fail if a memory card or usb stick
is inserted after having used with a mac.
and it's not just devices failing. ask a sysadmin about all .ds_store
pollution left by macs that connect to a shared drive.
Jolly Roger
Jun 16, 2016, 6:05:14 PM6/16/16
to
maximizing my use of my own storage medium. I'm just here for the
popcorn.
Jolly Roger
Jun 16, 2016, 6:10:53 PM6/16/16
to
On 2016-06-16, Happy.Hobo <Happy...@Spam.Invalid> wrote:
unknown origin will check each file before attempting to process it to
be sure it actually is in fact a valid image (or whatever type of file
is expected) before opening it.
Jolly Roger
Jun 16, 2016, 6:16:27 PM6/16/16
to
On 2016-06-16, nospam <nos...@nospam.invalid> wrote:
>
> you can argue all day long about how it *should* work, but the reality
> is that there are devices that will fail if a memory card or usb stick
> is inserted after having used with a mac.
Yep, that's true.
>
> you can argue all day long about how it *should* work, but the reality
> is that there are devices that will fail if a memory card or usb stick
> is inserted after having used with a mac.
> and it's not just devices failing. ask a sysadmin about all .ds_store
> pollution left by macs that connect to a shared drive.
All gone.
nospam
Jun 16, 2016, 6:25:24 PM6/16/16
to
In article <160620162308520363%timst...@greenbee.net>, Tim Streater
>
> If your software barfs on things it doesn't expect, it must be
> explicitly coded to do that. So don't do that. Simples.
not necessarily.
there are always edge cases that people don't think of or test for.
but again, it doesn't matter how it *should* be done, the reality is
that there are devices that will have problems and there's no way to
know ahead of time which devices will or will not.
<timst...@greenbee.net> wrote:
> >> >> > It can simply ignore them.
> >> >
> >> > I agree. But if the company who built the device did not think about the
> >> > possibilityy that the storage medium would be mounted on a Mac which
> >> > adds files to it, it wouldn't think about coding the file system access
> >> > routines to ignore such files.
> >>
> >> You don't add code to ignore files. If you don't need those files, you
> >> don't write code to look for them. But, if you write code to scan a
> >> directory, you don't explicitly define your data structure to choke on
> >> files that you _know_ might be there.
> >
> >normally, they aren't there, so there's no need to check.
> >
> >only macs add invisible files on foreign file systems.
> >
> >you can argue all day long about how it *should* work, but the reality
> >is that there are devices that will fail if a memory card or usb stick
> >is inserted after having used with a mac.
> >
> >and it's not just devices failing. ask a sysadmin about all .ds_store
> >pollution left by macs that connect to a shared drive.
>
> Why are these a problem?
> >> >> > It can simply ignore them.
> >> >
> >> > I agree. But if the company who built the device did not think about the
> >> > possibilityy that the storage medium would be mounted on a Mac which
> >> > adds files to it, it wouldn't think about coding the file system access
> >> > routines to ignore such files.
> >>
> >> You don't add code to ignore files. If you don't need those files, you
> >> don't write code to look for them. But, if you write code to scan a
> >> directory, you don't explicitly define your data structure to choke on
> >> files that you _know_ might be there.
> >
> >normally, they aren't there, so there's no need to check.
> >
> >only macs add invisible files on foreign file systems.
> >
> >you can argue all day long about how it *should* work, but the reality
> >is that there are devices that will fail if a memory card or usb stick
> >is inserted after having used with a mac.
> >
> >and it's not just devices failing. ask a sysadmin about all .ds_store
> >pollution left by macs that connect to a shared drive.
>
>
> If your software barfs on things it doesn't expect, it must be
> explicitly coded to do that. So don't do that. Simples.
not necessarily.
there are always edge cases that people don't think of or test for.
but again, it doesn't matter how it *should* be done, the reality is
that there are devices that will have problems and there's no way to
know ahead of time which devices will or will not.
nospam
Jun 16, 2016, 6:25:25 PM6/16/16
to
In article <dsgmpo...@mid.individual.net>, Jolly Roger
non-geek user who does something as simple as copy photos from a camera
to a mac and then finds their camera doesn't work anymore.
<jolly...@pobox.com> wrote:
> >
> > you can argue all day long about how it *should* work, but the reality
> > is that there are devices that will fail if a memory card or usb stick
> > is inserted after having used with a mac.
>
> Yep, that's true.
>
> > and it's not just devices failing. ask a sysadmin about all .ds_store
> > pollution left by macs that connect to a shared drive.
>
> find . -type f -name ".DS_Store" -print -delete
>
> All gone.
that might work for you or me but try to explain that to an average
> >
> > you can argue all day long about how it *should* work, but the reality
> > is that there are devices that will fail if a memory card or usb stick
> > is inserted after having used with a mac.
>
> Yep, that's true.
>
> > and it's not just devices failing. ask a sysadmin about all .ds_store
> > pollution left by macs that connect to a shared drive.
>
> find . -type f -name ".DS_Store" -print -delete
>
> All gone.
non-geek user who does something as simple as copy photos from a camera
to a mac and then finds their camera doesn't work anymore.
Jolly Roger
Jun 16, 2016, 6:45:59 PM6/16/16
to
On 2016-06-16, nospam <nos...@nospam.invalid> wrote:
Jolly Roger
Jun 16, 2016, 6:47:12 PM6/16/16
to
On 2016-06-16, nospam <nos...@nospam.invalid> wrote:
>
>
> but again, it doesn't matter how it *should* be done, the reality is
> that there are devices that will have problems and there's no way to
> know ahead of time which devices will or will not.
You can rest assured it does matter to those concerned with quality. : )
> that there are devices that will have problems and there's no way to
> know ahead of time which devices will or will not.
nospam
Jun 16, 2016, 7:25:48 PM6/16/16
to
In article <dsgoh3...@mid.individual.net>, Jolly Roger
typically, a web cam might have problems, not a top tier digicam.
the point is that a non-geek isn't going to know why it stopped
working. all they see is the camera used to work and now it doesn't.
<jolly...@pobox.com> wrote:
> >>> you can argue all day long about how it *should* work, but the reality
> >>> is that there are devices that will fail if a memory card or usb stick
> >>> is inserted after having used with a mac.
> >>
> >> Yep, that's true.
> >>
> >> > and it's not just devices failing. ask a sysadmin about all .ds_store
> >> > pollution left by macs that connect to a shared drive.
> >>
> >> find . -type f -name ".DS_Store" -print -delete
> >>
> >> All gone.
> >
> > that might work for you or me but try to explain that to an average
> > non-geek user who does something as simple as copy photos from a camera
> > to a mac and then finds their camera doesn't work anymore.
>
> Which cameras do that? Not my Nikon or Olympus.
it was an example, not an actual event.
> >>> you can argue all day long about how it *should* work, but the reality
> >>> is that there are devices that will fail if a memory card or usb stick
> >>> is inserted after having used with a mac.
> >>
> >> Yep, that's true.
> >>
> >> > and it's not just devices failing. ask a sysadmin about all .ds_store
> >> > pollution left by macs that connect to a shared drive.
> >>
> >> find . -type f -name ".DS_Store" -print -delete
> >>
> >> All gone.
> >
> > that might work for you or me but try to explain that to an average
> > non-geek user who does something as simple as copy photos from a camera
> > to a mac and then finds their camera doesn't work anymore.
>
> Which cameras do that? Not my Nikon or Olympus.
typically, a web cam might have problems, not a top tier digicam.
the point is that a non-geek isn't going to know why it stopped
working. all they see is the camera used to work and now it doesn't.
nospam
Jun 16, 2016, 7:25:49 PM6/16/16
to
In article <dsgojc...@mid.individual.net>, Jolly Roger
there's a lot of crap out there.
<jolly...@pobox.com> wrote:
> > but again, it doesn't matter how it *should* be done, the reality is
> > that there are devices that will have problems and there's no way to
> > know ahead of time which devices will or will not.
>
> You can rest assured it does matter to those concerned with quality. : )
sure, but the reality is that you can't always get that.
> > but again, it doesn't matter how it *should* be done, the reality is
> > that there are devices that will have problems and there's no way to
> > know ahead of time which devices will or will not.
>
> You can rest assured it does matter to those concerned with quality. : )
there's a lot of crap out there.
Jolly Roger
Jun 16, 2016, 8:14:07 PM6/16/16
to
On 2016-06-16, nospam <nos...@nospam.invalid> wrote:
> In article <dsgoh3...@mid.individual.net>, Jolly Roger
><jolly...@pobox.com> wrote:
>
>> >>> you can argue all day long about how it *should* work, but the reality
>> >>> is that there are devices that will fail if a memory card or usb stick
>> >>> is inserted after having used with a mac.
>> >>
>> >> Yep, that's true.
>> >>
>> >> > and it's not just devices failing. ask a sysadmin about all .ds_store
>> >> > pollution left by macs that connect to a shared drive.
>> >>
>> >> find . -type f -name ".DS_Store" -print -delete
>> >>
>> >> All gone.
>> >
>> > that might work for you or me but try to explain that to an average
>> > non-geek user who does something as simple as copy photos from a camera
>> > to a mac and then finds their camera doesn't work anymore.
>>
>> Which cameras do that? Not my Nikon or Olympus.
>
> it was an example, not an actual event.
>
> typically, a web cam might have problems, not a top tier digicam.
None of my web cameras require or support removable media. And they all
><jolly...@pobox.com> wrote:
>
>> >>> you can argue all day long about how it *should* work, but the reality
>> >>> is that there are devices that will fail if a memory card or usb stick
>> >>> is inserted after having used with a mac.
>> >>
>> >> Yep, that's true.
>> >>
>> >> > and it's not just devices failing. ask a sysadmin about all .ds_store
>> >> > pollution left by macs that connect to a shared drive.
>> >>
>> >> find . -type f -name ".DS_Store" -print -delete
>> >>
>> >> All gone.
>> >
>> > that might work for you or me but try to explain that to an average
>> > non-geek user who does something as simple as copy photos from a camera
>> > to a mac and then finds their camera doesn't work anymore.
>>
>> Which cameras do that? Not my Nikon or Olympus.
>
> it was an example, not an actual event.
>
> typically, a web cam might have problems, not a top tier digicam.
run Linux, which doesn't fall down if I place extraneous files in the
file system. : )
> the point is that a non-geek isn't going to know why it stopped
> working. all they see is the camera used to work and now it doesn't.
That doesn't prevent those of us who know better from pointing out the
root cause of why such a problem exists. Like it or not, there is a way
to avoid such issues: make more informed purchasing decisions. : )
Jolly Roger
Jun 16, 2016, 8:15:07 PM6/16/16
to
On 2016-06-16, nospam <nos...@nospam.invalid> wrote:
our wallets.
Lewis
Jun 17, 2016, 5:28:01 AM6/17/16
to
In message <dsf5em...@mid.individual.net>
I had a Garmin that crashed when I tried to load new maps on it because
there were other files on the SD card. As I recall the directory
structure had to be exactly:
\garmin\mapfile.bin
Any other files, directories, or variation in the name would cause the
device to lock up until you reset it.
This was years ago, though. I think current map files for the newer
Garmin's are too large to be put on a FAT32 device at all.
--
It is one thing to be mistaken; it is quite another to be willfully
ignorant ~Cecil Adams
there were other files on the SD card. As I recall the directory
structure had to be exactly:
\garmin\mapfile.bin
Any other files, directories, or variation in the name would cause the
device to lock up until you reset it.
This was years ago, though. I think current map files for the newer
Garmin's are too large to be put on a FAT32 device at all.
--
It is one thing to be mistaken; it is quite another to be willfully
ignorant ~Cecil Adams
Happy.Hobo
Jun 17, 2016, 6:05:20 PM6/17/16
to
On 06-17-2016 11:27, Lewis wrote:
> I had a Garmin that crashed when I tried to load new maps on it because
> there were other files on the SD card. As I recall the directory
> structure had to be exactly:
>
> \garmin\mapfile.bin
>
> Any other files, directories, or variation in the name would cause the
> device to lock up until you reset it.
>
> This was years ago, though. I think current map files for the newer
> Garmin's are too large to be put on a FAT32 device at all.
I look at my Garmin with Finder frequently. The resulting extra files
> I had a Garmin that crashed when I tried to load new maps on it because
> there were other files on the SD card. As I recall the directory
> structure had to be exactly:
>
> \garmin\mapfile.bin
>
> Any other files, directories, or variation in the name would cause the
> device to lock up until you reset it.
>
> This was years ago, though. I think current map files for the newer
> Garmin's are too large to be put on a FAT32 device at all.
have no effect.
JF Mezei
Jun 17, 2016, 7:42:35 PM6/17/16
to
On 2016-06-17 18:05, Happy.Hobo wrote:
> I look at my Garmin with Finder frequently. The resulting extra files
> have no effect.
Garmin GPSmap 60Csx will not boot when the "apple" files are present on
> I look at my Garmin with Finder frequently. The resulting extra files
> have no effect.
its card.
So whenever I plug the GPS in USB disk mode or plug the card in, I have
to make sure I cleanup after those files, and dismount from command line
to not give finder a chance to put the files back.
Lewis
Jun 18, 2016, 12:18:48 AM6/18/16
to
In message <170620161214027148%timst...@greenbee.net>
Tim Streater <timst...@greenbee.net> wrote:
> In article <slrnnm7gl1....@amelia.local>, Lewis
> Then they must have explicitly coded it to do that.
Not at all. If they simply scanned the entire card and then fed the
results into their loader then when the results contained anything more
than a single file it could easily fuck everything up.
--
So now you know the words to our song, pretty soon you'll all be singing
along, when you're sad, when you're lonely and it all turns out wrong...
Tim Streater <timst...@greenbee.net> wrote:
> In article <slrnnm7gl1....@amelia.local>, Lewis
Not at all. If they simply scanned the entire card and then fed the
results into their loader then when the results contained anything more
than a single file it could easily fuck everything up.
--
So now you know the words to our song, pretty soon you'll all be singing
along, when you're sad, when you're lonely and it all turns out wrong...
Jolly Roger
Jun 18, 2016, 12:48:53 PM6/18/16
to
On 2016-06-18, Tim Streater <timst...@greenbee.net> wrote:
> In article <slrnnm9it6....@amelia.local>, Lewis
> So they did it the hard way, then.
s/hard/stupid
> In article <slrnnm9it6....@amelia.local>, Lewis
s/hard/stupid
JF Mezei
Jun 18, 2016, 1:10:44 PM6/18/16
to
On 2016-06-18 12:48, Jolly Roger wrote:
\
because at boot time, presence of certain files may affect what boots.
(for instance, presence of new firmware file would cause the boot loader
to boot the firmware upgrade software instead of the GPS/camera software).
\
>>>Not at all. If they simply scanned the entire card and then fed the
>>>results into their loader then when the results contained anything more
>>>than a single file it could easily fuck everything up.
>>
>> So they did it the hard way, then.
Many embedded devices need to scan the whole top directory of a card
>>>results into their loader then when the results contained anything more
>>>than a single file it could easily fuck everything up.
>>
>> So they did it the hard way, then.
because at boot time, presence of certain files may affect what boots.
(for instance, presence of new firmware file would cause the boot loader
to boot the firmware upgrade software instead of the GPS/camera software).
Jolly Roger
Jun 18, 2016, 1:21:57 PM6/18/16
to
On 2016-06-18, JF Mezei <jfmezei...@vaxination.ca> wrote:
> On 2016-06-18 12:48, Jolly Roger wrote:
> \
>>>>Not at all. If they simply scanned the entire card and then fed the
>>>>results into their loader then when the results contained anything more
>>>>than a single file it could easily fuck everything up.
>>>
>>> So they did it the hard way, then.
I didn't write anything above, yet you attributed me...
> On 2016-06-18 12:48, Jolly Roger wrote:
> \
>>>>Not at all. If they simply scanned the entire card and then fed the
>>>>results into their loader then when the results contained anything more
>>>>than a single file it could easily fuck everything up.
>>>
>>> So they did it the hard way, then.
> Many embedded devices need to scan the whole top directory of a card
> because at boot time, presence of certain files may affect what boots.
> (for instance, presence of new firmware file would cause the boot loader
> to boot the firmware upgrade software instead of the GPS/camera software).
JF Mezei
Jun 18, 2016, 1:52:15 PM6/18/16
to
On 2016-06-18 13:21, Jolly Roger wrote:
> Crappy software is crappy software. End of story.
Crappy when using a Mac, yes. But for vast majority, the people wouldn't
> Crappy software is crappy software. End of story.
have a problem.
There are devices that require very "precise" setting up of the card,
and devices that are more consumer friendly and tolerate messing up with
the card.
garmin started off as a serious company catering to highly technmical
people with very precise standards. After GPS became "consumer"
products, the original OS continued for a few generation before they
apparently relaxed the disk file system rules. my 60csx is of the
previous generation. Newer models apparently have more flexible boot
software.
Jolly Roger
Jun 18, 2016, 7:52:18 PM6/18/16
to
On 2016-06-18, JF Mezei <jfmezei...@vaxination.ca> wrote:
> On 2016-06-18 13:21, Jolly Roger wrote:
>
>> Crappy software is crappy software. End of story.
>
> Crappy when using a Mac, yes.
Bullshit. I can use any of the above desktop or server operating
>
>> Crappy software is crappy software. End of story.
>
> Crappy when using a Mac, yes.
systems on the market to place any number of files I wish onto my
devices with FAT (or any other) file systems. This crappy software
doesn't care what OS you use to place files into the file system - it
fucks up and malfunctions indiscriminately in that regard.
> But for vast majority, the people wouldn't have a problem.
extraneous files are obviously best used by light users and are not a
good fit for power users.
> There are devices that require very "precise" setting up of the card,
> and devices that are more consumer friendly and tolerate messing up with
> the card.
David Empson
Jun 18, 2016, 8:46:56 PM6/18/16
to
JF Mezei <jfmezei...@vaxination.ca> wrote:
> On 2016-06-18 13:21, Jolly Roger wrote:
>
> > Crappy software is crappy software. End of story.
>
> Crappy when using a Mac, yes. But for vast majority, the people wouldn't
> have a problem.
Speaking as an embedded systems programmer, crappy is a good
> On 2016-06-18 13:21, Jolly Roger wrote:
>
> > Crappy software is crappy software. End of story.
>
> Crappy when using a Mac, yes. But for vast majority, the people wouldn't
> have a problem.
description. Software should be designed to deal with unexpected input
data and not misbehave. Same for embedded systems as anything else (in
some cases, MORE important for embedded systems, especially those which
need to operate autonomously out in the middle of nowhere).
--
David Empson
dem...@actrix.gen.nz
Lewis
Jun 19, 2016, 1:28:17 PM6/19/16
to
In message <180620160856396443%timst...@greenbee.net>
Tim Streater <timst...@greenbee.net> wrote:
> In article <slrnnm9it6....@amelia.local>, Lewis
--
'Who's that playing now, Mr. Dibbler?' "'And you".' 'Sorry, Mr.
Dibbler?' 'Only they write it &U,' said Dibbler. --Soul Music
Tim Streater <timst...@greenbee.net> wrote:
> In article <slrnnm9it6....@amelia.local>, Lewis
> So they did it the hard way, then.
Hard and dumb, that seems to be the source of many problems.
--
'Who's that playing now, Mr. Dibbler?' "'And you".' 'Sorry, Mr.
Dibbler?' 'Only they write it &U,' said Dibbler. --Soul Music
Elden
Jun 26, 2016, 8:52:57 PM6/26/16
to
On 2016-06-16, nospam <nos...@nospam.invalid> wrote:
> and it's not just devices failing. ask a sysadmin about all .ds_store
> pollution left by macs that connect to a shared drive.
Yep. It leaves little turds everywhere. It's embarassing. Probably my
> pollution left by macs that connect to a shared drive.
number one complaint about the Mac.
--
-=Elden=-
Jolly Roger
Jun 26, 2016, 8:57:19 PM6/26/16
to
other hand, it's not a huge problem and they are easily removed if they
offend you. : )
Davoud
Jun 26, 2016, 9:28:22 PM6/26/16
to
Elden:
USB sticks in Macs and successfully reading and writing to them in
other devices, I have encountered exactly one problem. I am the OP in
this thread. The problem was that my new Lexus nav system would not
read a jpg from the Mac formatted stick, possibly due to the extra
files the Mac put in place during the format. Most assuredly a First
World problem. I have never seen another instance in which a computer,
be it Mac, Windows, or *ix, or a computer-like device, failed to read a
Mac-formatted FAT32 stick.
--
I agree with almost everything that you have said and almost everything that
you will say in your entire life.
usenet *at* davidillig dawt cawm
> Yep. It leaves little turds everywhere. It's embarassing. Probably my
> number one complaint about the Mac.
Then you're in very good shape indeed. After many years of formatting
> number one complaint about the Mac.
USB sticks in Macs and successfully reading and writing to them in
other devices, I have encountered exactly one problem. I am the OP in
this thread. The problem was that my new Lexus nav system would not
read a jpg from the Mac formatted stick, possibly due to the extra
files the Mac put in place during the format. Most assuredly a First
World problem. I have never seen another instance in which a computer,
be it Mac, Windows, or *ix, or a computer-like device, failed to read a
Mac-formatted FAT32 stick.
--
I agree with almost everything that you have said and almost everything that
you will say in your entire life.
usenet *at* davidillig dawt cawm
Lewis
Jun 26, 2016, 9:43:30 PM6/26/16
to
In message <6e6dnR9yPv9-5e3K...@giganews.com>
Maybe you should read up on how to prevent that. It's trivial.
--
'Pcharn'kov!' Footnote: 'Your feet shall be cut off and be buried
several yards from your body so your ghost won't walk.' --Interesting
Times
--
'Pcharn'kov!' Footnote: 'Your feet shall be cut off and be buried
several yards from your body so your ghost won't walk.' --Interesting
Times
Elden
Jun 26, 2016, 10:17:40 PM6/26/16
to
On 2016-06-27, Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> In message <6e6dnR9yPv9-5e3K...@giganews.com>
> Elden <use...@moondog.org> wrote:
>> Yep. It leaves little turds everywhere. It's embarassing. Probably my
>> number one complaint about the Mac.
>
> Maybe you should read up on how to prevent that. It's trivial.
Is that your attempt at being helpful? Thanks. At least now I know there
> In message <6e6dnR9yPv9-5e3K...@giganews.com>
> Elden <use...@moondog.org> wrote:
>> Yep. It leaves little turds everywhere. It's embarassing. Probably my
>> number one complaint about the Mac.
>
> Maybe you should read up on how to prevent that. It's trivial.
is an answer out there. Unfortunately I still have no idea what it is.
--
-=Elden=-
Elden
Jun 26, 2016, 10:19:56 PM6/26/16
to
On 2016-06-27, Jolly Roger <jolly...@pobox.com> wrote:
> On 2016-06-27, Elden <use...@moondog.org> wrote:
>> Yep. It leaves little turds everywhere. It's embarassing. Probably my
>> number one complaint about the Mac.
>
> I haven't ever met anyone who *likes the way that was designed. On the
> other hand, it's not a huge problem and they are easily removed if
> they offend you. : )
Yeah, back in the days when I actually cared, I had a killdsstore script
> On 2016-06-27, Elden <use...@moondog.org> wrote:
>> Yep. It leaves little turds everywhere. It's embarassing. Probably my
>> number one complaint about the Mac.
>
> I haven't ever met anyone who *likes the way that was designed. On the
> other hand, it's not a huge problem and they are easily removed if
> they offend you. : )
that I'd just run occasionally and it would clean things up. It was just
always one of those little irritating things. Probably compounded by
some amount of OCD.
--
-=Elden=-
Elden
Jun 26, 2016, 10:22:58 PM6/26/16
to
On 2016-06-27, Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> In message <6e6dnR9yPv9-5e3K...@giganews.com>
> Elden <use...@moondog.org> wrote:
>> Yep. It leaves little turds everywhere. It's embarassing. Probably my
>> number one complaint about the Mac.
>
> Maybe you should read up on how to prevent that. It's trivial.
And to clarify... I'm not looking for a solution. I just like bitching
> Elden <use...@moondog.org> wrote:
>> Yep. It leaves little turds everywhere. It's embarassing. Probably my
>> number one complaint about the Mac.
>
> Maybe you should read up on how to prevent that. It's trivial.
about the problem. There was a time when I might have felt like worrying
about it. That time is past.
--
-=Elden=-
Jim
Jun 27, 2016, 7:32:21 AM6/27/16
to
In article <260620162128193008%st...@sky.net>, Davoud <st...@sky.net>
wrote:
> Elden:
> > Yep. It leaves little turds everywhere. It's embarassing. Probably my
> > number one complaint about the Mac.
>
> Then you're in very good shape indeed. After many years of formatting
> USB sticks in Macs and successfully reading and writing to them in
> other devices, I have encountered exactly one problem. I am the OP in
> this thread. The problem was that my new Lexus nav system would not
> read a jpg from the Mac formatted stick, possibly due to the extra
> files the Mac put in place during the format. Most assuredly a First
> World problem. I have never seen another instance in which a computer,
> be it Mac, Windows, or *ix, or a computer-like device, failed to read a
> Mac-formatted FAT32 stick.
My sister's Hyundai had that problem with music files. It turned out
that the vehicle could only handle very specific block sizes, and my
Mac wasn't able to format the stick with the right size. Reading the
car's manual, and using a PC to format the stick (they have options for
block size), I was able to load her tunes.
--
Jim
wrote:
> Elden:
> > Yep. It leaves little turds everywhere. It's embarassing. Probably my
> > number one complaint about the Mac.
>
> Then you're in very good shape indeed. After many years of formatting
> USB sticks in Macs and successfully reading and writing to them in
> other devices, I have encountered exactly one problem. I am the OP in
> this thread. The problem was that my new Lexus nav system would not
> read a jpg from the Mac formatted stick, possibly due to the extra
> files the Mac put in place during the format. Most assuredly a First
> World problem. I have never seen another instance in which a computer,
> be it Mac, Windows, or *ix, or a computer-like device, failed to read a
> Mac-formatted FAT32 stick.
that the vehicle could only handle very specific block sizes, and my
Mac wasn't able to format the stick with the right size. Reading the
car's manual, and using a PC to format the stick (they have options for
block size), I was able to load her tunes.
--
Jim
Elden
Jun 27, 2016, 9:36:40 AM6/27/16
to
On Jun 26, 2016, Davoud wrote:
> Elden:
> > Yep. It leaves little turds everywhere. It's embarassing. Probably my
> > number one complaint about the Mac.
>
> Then you're in very good shape indeed.
This is true. If something that minor is my biggest gripe, not doing too
> Elden:
> > Yep. It leaves little turds everywhere. It's embarassing. Probably my
> > number one complaint about the Mac.
>
> Then you're in very good shape indeed.
shabby. :)
--
-=Elden=-
JF Mezei
Jun 27, 2016, 11:34:51 AM6/27/16
to
On 2016-06-26 22:17, Elden wrote:
> Is that your attempt at being helpful? Thanks. At least now I know there
> is an answer out there. Unfortunately I still have no idea what it is.
Tinker Tools has an option to prevent "Macification" of remote drives.
> Is that your attempt at being helpful? Thanks. At least now I know there
> is an answer out there. Unfortunately I still have no idea what it is.
You can also specify that Spotify not touch remote drives. I do not know
what the definition of "remote drive" is however. (NFS ? SMB ? AFS ? USB
? not sure).
Jolly Roger
Jun 27, 2016, 11:47:52 AM6/27/16
to
JF Mezei <jfmezei...@vaxination.ca> wrote:
> On 2016-06-26 22:17, Elden wrote:
>
>> Is that your attempt at being helpful? Thanks. At least now I know there
>> is an answer out there. Unfortunately I still have no idea what it is.
>
> Tinker Tools has an option to prevent "Macification" of remote drives.
You don't need TinkerTool. Just issue this one-line terminal command:
> On 2016-06-26 22:17, Elden wrote:
>
>> Is that your attempt at being helpful? Thanks. At least now I know there
>> is an answer out there. Unfortunately I still have no idea what it is.
>
> Tinker Tools has an option to prevent "Macification" of remote drives.
defaults write com.apple.desktopservices DSDontWriteNetworkStores true
> I do not know
> what the definition of "remote drive" is however. (NFS ? SMB ? AFS ? USB
> ? not sure).
nospam
Jun 27, 2016, 11:48:21 AM6/27/16
to
In article <57714798$0$51803$c3e8da3$f626...@news.astraweb.com>, JF
Mezei <jfmezei...@vaxination.ca> wrote:
> Tinker Tools has an option to prevent "Macification" of remote drives.
> You can also specify that Spotify not touch remote drives. I do not know
> what the definition of "remote drive" is however. (NFS ? SMB ? AFS ? USB
> ? not sure).
network shares.
> Tinker Tools has an option to prevent "Macification" of remote drives.
> You can also specify that Spotify not touch remote drives. I do not know
> what the definition of "remote drive" is however. (NFS ? SMB ? AFS ? USB
> ? not sure).
Neill Massello
Jun 27, 2016, 12:21:25 PM6/27/16
to
Jolly Roger <jolly...@pobox.com> wrote:
> It applies only to *network* volumes that are mounted on the machine.
And only (AFAIK) prevents DS_Store files, not the other files that Macs
> It applies only to *network* volumes that are mounted on the machine.
may place on remote volumes. A more comprehensive (but not free) tool is
Blue Harvest.
<http://zeroonetwenty.com>
Jolly Roger
Jun 27, 2016, 1:15:02 PM6/27/16
to
On 2016-06-27, Neill Massello <nmas...@yahoo.com> wrote:
> Jolly Roger <jolly...@pobox.com> wrote:
>
>> It applies only to *network* volumes that are mounted on the machine.
>
> And only (AFAIK) prevents DS_Store files, not the other files that Macs
> may place on remote volumes.
You're referring to AppleDouble files that are placed on non-HFS file
> Jolly Roger <jolly...@pobox.com> wrote:
>
>> It applies only to *network* volumes that are mounted on the machine.
>
> And only (AFAIK) prevents DS_Store files, not the other files that Macs
> may place on remote volumes.
systems when you add Mac files with resource forks to them. These files
hold all of the resource fork data that would otherwise be missing. As
such, deleting them can cause data loss. Depending on what your plans
are for the files, this could cause problems - particularly if you
expect to use those files on Mac systems later on.
Elden
Jun 27, 2016, 11:39:35 PM6/27/16
to
folks. Spotlight. Way back when I used to use a little app called
“Spotless” that would keep Spotlight from taking over drives with it’s
indexing. I don’t pay much attention to it now.
I think now that I’m on my second time around with a Mac, I’m much more
inclined to just use the thing the way it was intended to be used if at all
possible.
Thanks for the tip on Tinker Tools.
--
-=Elden=-
Elden
Jun 27, 2016, 11:44:56 PM6/27/16
to
On Jun 27, 2016, Jolly Roger wrote:
> On 2016-06-27, Neill Massello<nmas...@yahoo.com>wrote:
> > Jolly Roger<jolly...@pobox.com>wrote:
> >
> > > It applies only to *network* volumes that are mounted on the machine.
> >
> > And only (AFAIK) prevents DS_Store files, not the other files that Macs
> > may place on remote volumes.
>
> You're referring to AppleDouble files that are placed on non-HFS file
> systems when you add Mac files with resource forks to them. These files
> hold all of the resource fork data that would otherwise be missing. As
> such, deleting them can cause data loss. Depending on what your plans
> are for the files, this could cause problems - particularly if you
> expect to use those files on Mac systems later on.
That’s what I was trying to remember! The whole resource fork thing. Do you
> On 2016-06-27, Neill Massello<nmas...@yahoo.com>wrote:
> > Jolly Roger<jolly...@pobox.com>wrote:
> >
> > > It applies only to *network* volumes that are mounted on the machine.
> >
> > And only (AFAIK) prevents DS_Store files, not the other files that Macs
> > may place on remote volumes.
>
> You're referring to AppleDouble files that are placed on non-HFS file
> systems when you add Mac files with resource forks to them. These files
> hold all of the resource fork data that would otherwise be missing. As
> such, deleting them can cause data loss. Depending on what your plans
> are for the files, this could cause problems - particularly if you
> expect to use those files on Mac systems later on.
have any idea how or if that whole mess will be dealt with on the new APFS?
Hopefully they have something a bit less ridiculous. I haven’t done much
reading on the new file system and I’ve seen nothing about the metadata
issue.
--
-=Elden=-
Jolly Roger
Jun 28, 2016, 12:30:08 AM6/28/16
to
On 2016-06-28, Elden <use...@moondog.org> wrote:
> On Jun 27, 2016, Jolly Roger wrote:
>> On 2016-06-27, Neill Massello<nmas...@yahoo.com>wrote:
>>> Jolly Roger<jolly...@pobox.com>wrote:
>>
> On Jun 27, 2016, Jolly Roger wrote:
>> On 2016-06-27, Neill Massello<nmas...@yahoo.com>wrote:
>>> Jolly Roger<jolly...@pobox.com>wrote:
>>
>> You're referring to AppleDouble files that are placed on non-HFS file
>> systems when you add Mac files with resource forks to them. These
>> files hold all of the resource fork data that would otherwise be
>> missing. As such, deleting them can cause data loss. Depending on
>> what your plans are for the files, this could cause problems -
>> particularly if you expect to use those files on Mac systems later
>> on.
>
> That’s what I was trying to remember! The whole resource fork thing.
> Do you have any idea how or if that whole mess will be dealt with on
> the new APFS? Hopefully they have something a bit less ridiculous.
I wouldn't call forks ridiculous at all - they are a pretty cool
>> systems when you add Mac files with resource forks to them. These
>> files hold all of the resource fork data that would otherwise be
>> missing. As such, deleting them can cause data loss. Depending on
>> what your plans are for the files, this could cause problems -
>> particularly if you expect to use those files on Mac systems later
>> on.
>
> That’s what I was trying to remember! The whole resource fork thing.
> Do you have any idea how or if that whole mess will be dealt with on
> the new APFS? Hopefully they have something a bit less ridiculous.
innovation IMO - it's just that other mainstream file systems don't
offer support for them. Anyhow, my understanding is that APFS doesn't
have forks. It does support extended file attributes.
nospam
Jun 28, 2016, 10:39:07 AM6/28/16
to
In article <dtecqc...@mid.individual.net>, Jolly Roger
them.
<jolly...@pobox.com> wrote:
> >> You're referring to AppleDouble files that are placed on non-HFS file
> >> systems when you add Mac files with resource forks to them. These
> >> files hold all of the resource fork data that would otherwise be
> >> missing. As such, deleting them can cause data loss. Depending on
> >> what your plans are for the files, this could cause problems -
> >> particularly if you expect to use those files on Mac systems later
> >> on.
> >
> > That零 what I was trying to remember! The whole resource fork thing.
> >> You're referring to AppleDouble files that are placed on non-HFS file
> >> systems when you add Mac files with resource forks to them. These
> >> files hold all of the resource fork data that would otherwise be
> >> missing. As such, deleting them can cause data loss. Depending on
> >> what your plans are for the files, this could cause problems -
> >> particularly if you expect to use those files on Mac systems later
> >> on.
> >
> > Do you have any idea how or if that whole mess will be dealt with on
> > the new APFS? Hopefully they have something a bit less ridiculous.
>
> I wouldn't call forks ridiculous at all - they are a pretty cool
> innovation IMO - it's just that other mainstream file systems don't
> offer support for them. Anyhow, my understanding is that APFS doesn't
> have forks. It does support extended file attributes.
it's going to have to support resource forks since macos still uses
> > the new APFS? Hopefully they have something a bit less ridiculous.
>
> I wouldn't call forks ridiculous at all - they are a pretty cool
> innovation IMO - it's just that other mainstream file systems don't
> offer support for them. Anyhow, my understanding is that APFS doesn't
> have forks. It does support extended file attributes.
them.
Neill Massello
Jun 28, 2016, 12:38:22 PM6/28/16
to
nospam <nos...@nospam.invalid> wrote:
> it's going to have to support resource forks since macos still uses
> them.
What component of the current OS requires a file system resource fork?
> it's going to have to support resource forks since macos still uses
> them.
In any case, there's no requirement that APFS support anything older
than whatever Apple specifies for it. They do occasionally drop support
for old stuff.
nospam
Jun 28, 2016, 12:42:21 PM6/28/16
to
In article <1mpjtgo.tk6vau4eacqwN%nmas...@yahoo.com>, Neill Massello
> In any case, there's no requirement that APFS support anything older
> than whatever Apple specifies for it. They do occasionally drop support
> for old stuff.
it will be a huge problem if they drop resource fork support, if for no
other reason than backups from other devices.
<nmas...@yahoo.com> wrote:
> > it's going to have to support resource forks since macos still uses
> > them.
>
> What component of the current OS requires a file system resource fork?
finder, for one. i'm sure there's more.
> > it's going to have to support resource forks since macos still uses
> > them.
>
> What component of the current OS requires a file system resource fork?
> In any case, there's no requirement that APFS support anything older
> than whatever Apple specifies for it. They do occasionally drop support
> for old stuff.
other reason than backups from other devices.
Neill Massello
Jun 28, 2016, 1:52:18 PM6/28/16
to
nospam <nos...@nospam.invalid> wrote:
> finder, for one. i'm sure there's more.
I can't see anything in Finder 10.11.4 that has a resource fork. In any
> finder, for one. i'm sure there's more.
case (again), any version of the OS that is designed to run in APFS
obviously won't require resource forks, which were deprecated years ago.
Alan Baker
Jun 28, 2016, 3:29:40 PM6/28/16
to
On 2016-06-28 7:39 AM, nospam wrote:
> In article <dtecqc...@mid.individual.net>, Jolly Roger
> <jolly...@pobox.com> wrote:
>
>>>> You're referring to AppleDouble files that are placed on non-HFS file
>>>> systems when you add Mac files with resource forks to them. These
>>>> files hold all of the resource fork data that would otherwise be
>>>> missing. As such, deleting them can cause data loss. Depending on
>>>> what your plans are for the files, this could cause problems -
>>>> particularly if you expect to use those files on Mac systems later
>>>> on.
>>>
>>> That¹s what I was trying to remember! The whole resource fork thing.
> In article <dtecqc...@mid.individual.net>, Jolly Roger
> <jolly...@pobox.com> wrote:
>
>>>> You're referring to AppleDouble files that are placed on non-HFS file
>>>> systems when you add Mac files with resource forks to them. These
>>>> files hold all of the resource fork data that would otherwise be
>>>> missing. As such, deleting them can cause data loss. Depending on
>>>> what your plans are for the files, this could cause problems -
>>>> particularly if you expect to use those files on Mac systems later
>>>> on.
>>>
>>> Do you have any idea how or if that whole mess will be dealt with on
>>> the new APFS? Hopefully they have something a bit less ridiculous.
>>
>> I wouldn't call forks ridiculous at all - they are a pretty cool
>> innovation IMO - it's just that other mainstream file systems don't
>> offer support for them. Anyhow, my understanding is that APFS doesn't
>> have forks. It does support extended file attributes.
>
> it's going to have to support resource forks since macos still uses
> them.
>
Where does the OS itself still do that?
>>> the new APFS? Hopefully they have something a bit less ridiculous.
>>
>> I wouldn't call forks ridiculous at all - they are a pretty cool
>> innovation IMO - it's just that other mainstream file systems don't
>> offer support for them. Anyhow, my understanding is that APFS doesn't
>> have forks. It does support extended file attributes.
>
> it's going to have to support resource forks since macos still uses
> them.
>
Alan Baker
Jun 28, 2016, 3:30:02 PM6/28/16
to
On 2016-06-28 9:42 AM, nospam wrote:
> In article <1mpjtgo.tk6vau4eacqwN%nmas...@yahoo.com>, Neill Massello
> <nmas...@yahoo.com> wrote:
>
>>> it's going to have to support resource forks since macos still uses
>>> them.
>>
>> What component of the current OS requires a file system resource fork?
>
> finder, for one. i'm sure there's more.
Cite, please...
> In article <1mpjtgo.tk6vau4eacqwN%nmas...@yahoo.com>, Neill Massello
> <nmas...@yahoo.com> wrote:
>
>>> it's going to have to support resource forks since macos still uses
>>> them.
>>
>> What component of the current OS requires a file system resource fork?
>
> finder, for one. i'm sure there's more.
Jolly Roger
Jun 28, 2016, 3:36:42 PM6/28/16
to
created by dragging the favicon of macsurfer.com from the Safari
location bar to my desktop:
# ls -l MacSurfer\'s\ Headline\ News™.webloc
-rw-r--r--@ 1 jr staff 78B Jun 28 12:32 MacSurfer's Headline
News™.webloc
# ls -l MacSurfer\'s\ Headline\ News™.webloc/..namedfork/rsrc
-rw-r--r-- 1 jr staff 524B Jun 28 12:32 MacSurfer's Headline
News™.webloc/..namedfork/rsrc
# DeRez MacSurfer\'s\ Headline\ News™.webloc
data 'drag' (128) {
$"0000 0001 0000 0000 0000 0000 0000 0003" /*
................ */
$"5445 5854 0000 0100 0000 0000 0000 0000" /*
TEXT............ */
$"7572 6C20 0000 0100 0000 0000 0000 0000" /* url
............ */
$"7572 6C6E 0000 0100 0000 0000 0000 0000" /*
urln............ */
};
data 'url ' (256) {
$"6874 7470 3A2F 2F77 7777 2E6D 6163 7375" /*
http://www.macsu */
$"7266 6572 2E63 6F6D 2F" /*
rfer.com/ */
};
data 'TEXT' (256) {
$"6874 7470 3A2F 2F77 7777 2E6D 6163 7375" /*
http://www.macsu */
$"7266 6572 2E63 6F6D 2F" /*
rfer.com/ */
};
data 'urln' (256) {
$"4D61 6353 7572 6665 7227 7320 4865 6164" /*
MacSurfer's Head */
$"6C69 6E65 204E 6577 73E2 84A2" /* line
News™ */
};
Jolly Roger
Jun 28, 2016, 3:37:49 PM6/28/16
to
On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
> On 2016-06-28 9:42 AM, nospam wrote:
>>
>>> What component of the current OS requires a file system resource fork?
>>
>> finder, for one. i'm sure there's more.
>
> Cite, please...
No cite needed, really. Just look around for yourself and you'll find
>>
>>> What component of the current OS requires a file system resource fork?
>>
>> finder, for one. i'm sure there's more.
>
> Cite, please...
*plenty* of files with resource forks.
nospam
Jun 28, 2016, 4:14:03 PM6/28/16
to
In article <dtg20a...@mid.individual.net>, Jolly Roger
<jolly...@pobox.com> wrote:
> >>> What component of the current OS requires a file system resource fork?
> >>
> >> finder, for one. i'm sure there's more.
> >
> > Cite, please...
>
> No cite needed, really. Just look around for yourself and you'll find
> *plenty* of files with resource forks.
no shit.
> >>> What component of the current OS requires a file system resource fork?
> >>
> >> finder, for one. i'm sure there's more.
> >
> > Cite, please...
>
> No cite needed, really. Just look around for yourself and you'll find
> *plenty* of files with resource forks.
nospam
Jun 28, 2016, 4:14:04 PM6/28/16
to
In article <1mpjx29.wxo0eo2l7ifoN%nmas...@yahoo.com>, Neill Massello
the easiest way is do the following:
- select any document (text, pdf, mp3, mp4, etc., it doesn't matter)
- choose get info from the file menu
- in the open with panel, choose a different app to open the document.
alternately, add a custom icon to the file.
finder just modified the file by *adding* *a* *resource* so the system
knows to use a different app when opening that file and/or added a
custom icon.
in mavericks and earlier, the modification date changes, while in
yosemite it does not, but it still shows up as a resource fork in both
when examining the file.
i did not test in el capitan but i doubt it's any different, as it's
been this way for *years*.
> In any
> case (again), any version of the OS that is designed to run in APFS
> obviously won't require resource forks, which were deprecated years ago.
apple might have said that but they lied.
they're actively using resources *today*.
apple might come up with another mechanism going forward, but they
still need to read old files with resources or there will be a *lot* of
*very* pissed off users and a lot of bad press about how data is lost
simply by using the new file system. that would be incredibly bad.
<nmas...@yahoo.com> wrote:
>
> > finder, for one. i'm sure there's more.
>
> I can't see anything in Finder 10.11.4 that has a resource fork.
you didn't look.
>
> > finder, for one. i'm sure there's more.
>
> I can't see anything in Finder 10.11.4 that has a resource fork.
the easiest way is do the following:
- select any document (text, pdf, mp3, mp4, etc., it doesn't matter)
- choose get info from the file menu
- in the open with panel, choose a different app to open the document.
alternately, add a custom icon to the file.
finder just modified the file by *adding* *a* *resource* so the system
knows to use a different app when opening that file and/or added a
custom icon.
in mavericks and earlier, the modification date changes, while in
yosemite it does not, but it still shows up as a resource fork in both
when examining the file.
i did not test in el capitan but i doubt it's any different, as it's
been this way for *years*.
> In any
> case (again), any version of the OS that is designed to run in APFS
> obviously won't require resource forks, which were deprecated years ago.
they're actively using resources *today*.
apple might come up with another mechanism going forward, but they
still need to read old files with resources or there will be a *lot* of
*very* pissed off users and a lot of bad press about how data is lost
simply by using the new file system. that would be incredibly bad.
nospam
Jun 28, 2016, 4:14:05 PM6/28/16
to
In article <nkuj7o$82j$3...@news.datemas.de>, Alan Baker
tl;dr - change a file's default app via open with.. and/or add a custom
icon and finder will add one or more resources.
<alang...@telus.net> wrote:
> >>> it's going to have to support resource forks since macos still uses
> >>> them.
> >>
> >> What component of the current OS requires a file system resource fork?
> >
> > finder, for one. i'm sure there's more.
>
> Cite, please...
see other post for details.
> >>> it's going to have to support resource forks since macos still uses
> >>> them.
> >>
> >> What component of the current OS requires a file system resource fork?
> >
> > finder, for one. i'm sure there's more.
>
> Cite, please...
tl;dr - change a file's default app via open with.. and/or add a custom
icon and finder will add one or more resources.
Alan Baker
Jun 28, 2016, 5:51:55 PM6/28/16
to
Alan Baker
Jun 28, 2016, 5:52:48 PM6/28/16
to
On 2016-06-28 12:37 PM, Jolly Roger wrote:
> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>> On 2016-06-28 9:42 AM, nospam wrote:
>>>
>>>> What component of the current OS requires a file system resource fork?
>>>
>>> finder, for one. i'm sure there's more.
>>
>> Cite, please...
>
> No cite needed, really. Just look around for yourself and you'll find
> *plenty* of files with resource forks.
>
The existence of files with resource forks isn't at issue.
> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>> On 2016-06-28 9:42 AM, nospam wrote:
>>>
>>>> What component of the current OS requires a file system resource fork?
>>>
>>> finder, for one. i'm sure there's more.
>>
>> Cite, please...
>
> No cite needed, really. Just look around for yourself and you'll find
> *plenty* of files with resource forks.
>
Your claim is that the Finder REQUIRES at least one resource fork...
...somewhere.
Jolly Roger
Jun 28, 2016, 5:56:03 PM6/28/16
to
On 2016-06-28, nospam <nos...@nospam.invalid> wrote:
> In article <1mpjx29.wxo0eo2l7ifoN%nmas...@yahoo.com>, Neill Massello
><nmas...@yahoo.com> wrote:
>
>>> finder, for one. i'm sure there's more.
>>
>> I can't see anything in Finder 10.11.4 that has a resource fork.
>
> you didn't look.
Yep. It's fairly easy to list all files in a given directory with
> In article <1mpjx29.wxo0eo2l7ifoN%nmas...@yahoo.com>, Neill Massello
><nmas...@yahoo.com> wrote:
>
>>> finder, for one. i'm sure there's more.
>>
>> I can't see anything in Finder 10.11.4 that has a resource fork.
>
> you didn't look.
resource forks - something like this will do:
find ~/Desktop -type f -exec test -s {}/..namedfork/rsrc \; -print
You can use the /usr/bin/DeRez utility to dump the contents of a file's
resource fork, if you are curious.
Alan Baker
Jun 28, 2016, 5:56:46 PM6/28/16
to
That an OS component can USE a resource for is something quite different.
nospam
Jun 28, 2016, 6:10:23 PM6/28/16
to
nospam
Jun 28, 2016, 6:10:24 PM6/28/16
to
In article <nkurjd$mmf$2...@news.datemas.de>, Alan Baker
apfs needs to support resource forks or emulate them somehow.
otherwise, users will lose data and they're not going to be very happy
about that.
> Your claim is that the Finder REQUIRES at least one resource fork...
> ...somewhere.
i didn't say requires. neill did:
because that's how it stores the necessary info (file path, custom
icon).
there may also be other ways in which it uses resources.
anyone who claims that resources are long forgotten is very mistaken.
resources are alive and well.
<alang...@telus.net> wrote:
> >>>> What component of the current OS requires a file system resource fork?
> >>>
> >>> finder, for one. i'm sure there's more.
> >>
> >> Cite, please...
> >
> > No cite needed, really. Just look around for yourself and you'll find
> > *plenty* of files with resource forks.
> >
>
> The existence of files with resource forks isn't at issue.
yes it is.
> >>>> What component of the current OS requires a file system resource fork?
> >>>
> >>> finder, for one. i'm sure there's more.
> >>
> >> Cite, please...
> >
> > No cite needed, really. Just look around for yourself and you'll find
> > *plenty* of files with resource forks.
> >
>
> The existence of files with resource forks isn't at issue.
apfs needs to support resource forks or emulate them somehow.
otherwise, users will lose data and they're not going to be very happy
about that.
> Your claim is that the Finder REQUIRES at least one resource fork...
> ...somewhere.
> nospam <nos...@nospam.invalid> wrote:
> > it's going to have to support resource forks since macos still uses
> > them.
>
> > it's going to have to support resource forks since macos still uses
> > them.
>
> What component of the current OS requires a file system resource fork?
> In any case, there's no requirement that APFS support anything older
> than whatever Apple specifies for it. They do occasionally drop support
> for old stuff.
>
for certain functionality, however, finder *does* require resources
> than whatever Apple specifies for it. They do occasionally drop support
> for old stuff.
>
because that's how it stores the necessary info (file path, custom
icon).
there may also be other ways in which it uses resources.
anyone who claims that resources are long forgotten is very mistaken.
resources are alive and well.
nospam
Jun 28, 2016, 6:10:26 PM6/28/16
to
In article <nkurqr$nl3$1...@news.datemas.de>, Alan Baker
> That an OS component can USE a resource for is something quite different.
not at all.
the fact is that resources are actively used and must be supported in
some form in apfs or there will be all sorts of problems.
resources are not dead.
<alang...@telus.net> wrote:
> >
> >> In any
> >> case (again), any version of the OS that is designed to run in APFS
> >> obviously won't require resource forks, which were deprecated years ago.
> >
> > apple might have said that but they lied.
> >
> > they're actively using resources *today*.
> >
> > apple might come up with another mechanism going forward, but they
> > still need to read old files with resources or there will be a *lot* of
> > *very* pissed off users and a lot of bad press about how data is lost
> > simply by using the new file system. that would be incredibly bad.
>
> The question was what OS component REQUIRES a resource fork.
nope. that's not the question but the answer is still the same.
> >
> >> In any
> >> case (again), any version of the OS that is designed to run in APFS
> >> obviously won't require resource forks, which were deprecated years ago.
> >
> > apple might have said that but they lied.
> >
> > they're actively using resources *today*.
> >
> > apple might come up with another mechanism going forward, but they
> > still need to read old files with resources or there will be a *lot* of
> > *very* pissed off users and a lot of bad press about how data is lost
> > simply by using the new file system. that would be incredibly bad.
>
> The question was what OS component REQUIRES a resource fork.
> That an OS component can USE a resource for is something quite different.
the fact is that resources are actively used and must be supported in
some form in apfs or there will be all sorts of problems.
resources are not dead.
Jolly Roger
Jun 28, 2016, 6:10:31 PM6/28/16
to
On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
> On 2016-06-28 12:36 PM, Jolly Roger wrote:
>> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>>> On 2016-06-28 7:39 AM, nospam wrote:
>>>> In article <dtecqc...@mid.individual.net>, Jolly Roger
>>>> <jolly...@pobox.com> wrote:
>>>>
>>>> it's going to have to support resource forks since macos still uses
>>>> them.
>>>
>>> Where does the OS itself still do that?
>>
>> Resource forks are still used all over the place. Here's a webloc file I
>> created by dragging the favicon of macsurfer.com from the Safari
>> location bar to my desktop:
>>
>> [snip]
> On 2016-06-28 12:36 PM, Jolly Roger wrote:
>> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>>> On 2016-06-28 7:39 AM, nospam wrote:
>>>> In article <dtecqc...@mid.individual.net>, Jolly Roger
>>>> <jolly...@pobox.com> wrote:
>>>>
>>>> it's going to have to support resource forks since macos still uses
>>>> them.
>>>
>>> Where does the OS itself still do that?
>>
>> Resource forks are still used all over the place. Here's a webloc file I
>> created by dragging the favicon of macsurfer.com from the Safari
>> location bar to my desktop:
>>
>
> None of that is a part of the OS.
He said macOS *uses* resource forks. Safari is a built-in Apple
> None of that is a part of the OS.
application that comes with the OS, and it definitely does use resource
forks. So does the Finder, which is definitely part of the OS. I have
better things to do argue with you about what is or is not technically
part of the OS since it is mostly irrelevant to whether Apple will
continue support for resource forks. The example above is just one small
sample of how resource forks are used in current versions of OS X. There
are *plenty* of others for anyone who cares to just look for themselves.
Want to find more? Go forth and prosper - or don't. I care not. Whether
you care to admit it or not, the fact remains resource forks are in wide
use today.
Jolly Roger
Jun 28, 2016, 6:13:35 PM6/28/16
to
On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
> On 2016-06-28 12:37 PM, Jolly Roger wrote:
>> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>>> On 2016-06-28 9:42 AM, nospam wrote:
>>>>
>>>>> What component of the current OS requires a file system resource fork?
>>>>
>>>> finder, for one. i'm sure there's more.
>>>
>>> Cite, please...
>>
>> No cite needed, really. Just look around for yourself and you'll find
>> *plenty* of files with resource forks.
>
> The existence of files with resource forks isn't at issue.
Wrong. It's precisely the issue since we are talking about whether APFS
> On 2016-06-28 12:37 PM, Jolly Roger wrote:
>> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>>> On 2016-06-28 9:42 AM, nospam wrote:
>>>>
>>>>> What component of the current OS requires a file system resource fork?
>>>>
>>>> finder, for one. i'm sure there's more.
>>>
>>> Cite, please...
>>
>> No cite needed, really. Just look around for yourself and you'll find
>> *plenty* of files with resource forks.
>
> The existence of files with resource forks isn't at issue.
will support resource forks. The fact is Finder, Safari, and other parts
of OS X do indeed use resource forks.
> Your claim is that the Finder REQUIRES at least one resource fork...
> ...somewhere.
you made it up.
You are apparently here just to argue. And I have better things to do.
Alan Baker
Jun 28, 2016, 6:35:03 PM6/28/16
to
up to date.
Alan Baker
Jun 28, 2016, 6:36:04 PM6/28/16
to
On 2016-06-28 3:10 PM, nospam wrote:
> In article <nkurjd$mmf$2...@news.datemas.de>, Alan Baker
> <alang...@telus.net> wrote:
>
>>>>>> What component of the current OS requires a file system resource fork?
>>>>>
>>>>> finder, for one. i'm sure there's more.
>>>>
>>>> Cite, please...
>>>
>>> No cite needed, really. Just look around for yourself and you'll find
>>> *plenty* of files with resource forks.
>>>
>>
>> The existence of files with resource forks isn't at issue.
>
> yes it is.
Nope.
> <alang...@telus.net> wrote:
>
>>>>>> What component of the current OS requires a file system resource fork?
>>>>>
>>>>> finder, for one. i'm sure there's more.
>>>>
>>>> Cite, please...
>>>
>>> No cite needed, really. Just look around for yourself and you'll find
>>> *plenty* of files with resource forks.
>>>
>>
>> The existence of files with resource forks isn't at issue.
>
> yes it is.
>
> apfs needs to support resource forks or emulate them somehow.
>
> otherwise, users will lose data and they're not going to be very happy
> about that.
>
>> Your claim is that the Finder REQUIRES at least one resource fork...
>> ...somewhere.
>
> i didn't say requires. neill did:
>
>
> In article <1mpjtgo.tk6vau4eacqwN%nmas...@yahoo.com>, Neill Massello
> <nmas...@yahoo.com> wrote:
>> nospam <nos...@nospam.invalid> wrote:
>>> it's going to have to support resource forks since macos still uses
>>> them.
>>
>> What component of the current OS requires a file system resource fork?
>> In any case, there's no requirement that APFS support anything older
>> than whatever Apple specifies for it. They do occasionally drop support
>> for old stuff.
>>
>
>
>
> for certain functionality, however, finder *does* require resources
> because that's how it stores the necessary info (file path, custom
> icon).
>
> there may also be other ways in which it uses resources.
>
> anyone who claims that resources are long forgotten is very mistaken.
>
> resources are alive and well.
Alan Baker
Jun 28, 2016, 6:36:54 PM6/28/16
to
On 2016-06-28 3:10 PM, nospam wrote:
> In article <nkurqr$nl3$1...@news.datemas.de>, Alan Baker
> <alang...@telus.net> wrote:
>
>>>
>>>> In any
>>>> case (again), any version of the OS that is designed to run in APFS
>>>> obviously won't require resource forks, which were deprecated years ago.
>>>
>>> apple might have said that but they lied.
>>>
>>> they're actively using resources *today*.
>>>
>>> apple might come up with another mechanism going forward, but they
>>> still need to read old files with resources or there will be a *lot* of
>>> *very* pissed off users and a lot of bad press about how data is lost
>>> simply by using the new file system. that would be incredibly bad.
>>
>> The question was what OS component REQUIRES a resource fork.
>
> nope. that's not the question but the answer is still the same.
That was PRECISELY the question:
> <alang...@telus.net> wrote:
>
>>>
>>>> In any
>>>> case (again), any version of the OS that is designed to run in APFS
>>>> obviously won't require resource forks, which were deprecated years ago.
>>>
>>> apple might have said that but they lied.
>>>
>>> they're actively using resources *today*.
>>>
>>> apple might come up with another mechanism going forward, but they
>>> still need to read old files with resources or there will be a *lot* of
>>> *very* pissed off users and a lot of bad press about how data is lost
>>> simply by using the new file system. that would be incredibly bad.
>>
>> The question was what OS component REQUIRES a resource fork.
>
> nope. that's not the question but the answer is still the same.
"What component of the current OS REQUIRES a file system resource fork?"
>
>> That an OS component can USE a resource for is something quite different.
>
> not at all.
>
> the fact is that resources are actively used and must be supported in
> some form in apfs or there will be all sorts of problems.
>
> resources are not dead.
>
Alan Baker
Jun 28, 2016, 6:37:43 PM6/28/16
to
On 2016-06-28 3:10 PM, Jolly Roger wrote:
> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>> On 2016-06-28 12:36 PM, Jolly Roger wrote:
>>> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>>>> On 2016-06-28 7:39 AM, nospam wrote:
>>>>> In article <dtecqc...@mid.individual.net>, Jolly Roger
>>>>> <jolly...@pobox.com> wrote:
>>>>>
>>>>> it's going to have to support resource forks since macos still uses
>>>>> them.
>>>>
>>>> Where does the OS itself still do that?
>>>
>>> Resource forks are still used all over the place. Here's a webloc file I
>>> created by dragging the favicon of macsurfer.com from the Safari
>>> location bar to my desktop:
>>>
>>> [snip]
>>
>> None of that is a part of the OS.
>
> He said macOS *uses* resource forks. Safari is a built-in Apple
But the question he was answering was what part of the OS REQUIRES
> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>> On 2016-06-28 12:36 PM, Jolly Roger wrote:
>>> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>>>> On 2016-06-28 7:39 AM, nospam wrote:
>>>>> In article <dtecqc...@mid.individual.net>, Jolly Roger
>>>>> <jolly...@pobox.com> wrote:
>>>>>
>>>>> it's going to have to support resource forks since macos still uses
>>>>> them.
>>>>
>>>> Where does the OS itself still do that?
>>>
>>> Resource forks are still used all over the place. Here's a webloc file I
>>> created by dragging the favicon of macsurfer.com from the Safari
>>> location bar to my desktop:
>>>
>>> [snip]
>>
>> None of that is a part of the OS.
>
> He said macOS *uses* resource forks. Safari is a built-in Apple
resource forks.
> application that comes with the OS, and it definitely does use resource
> forks. So does the Finder, which is definitely part of the OS. I have
Alan Baker
Jun 28, 2016, 6:38:05 PM6/28/16
to
On 2016-06-28 3:13 PM, Jolly Roger wrote:
> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>> On 2016-06-28 12:37 PM, Jolly Roger wrote:
>>> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>>>> On 2016-06-28 9:42 AM, nospam wrote:
>>>>>
>>>>>> What component of the current OS requires a file system resource fork?
>>>>>
>>>>> finder, for one. i'm sure there's more.
>>>>
>>>> Cite, please...
>>>
>>> No cite needed, really. Just look around for yourself and you'll find
>>> *plenty* of files with resource forks.
>>
>> The existence of files with resource forks isn't at issue.
>
> Wrong. It's precisely the issue since we are talking about whether APFS
> will support resource forks. The fact is Finder, Safari, and other parts
> of OS X do indeed use resource forks.
>
>> Your claim is that the Finder REQUIRES at least one resource fork...
>> ...somewhere.
>
> Don't try to put words I never said into my mouth. I never said that -
> you made it up.
That is the question that was at hand:
> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>> On 2016-06-28 12:37 PM, Jolly Roger wrote:
>>> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>>>> On 2016-06-28 9:42 AM, nospam wrote:
>>>>>
>>>>>> What component of the current OS requires a file system resource fork?
>>>>>
>>>>> finder, for one. i'm sure there's more.
>>>>
>>>> Cite, please...
>>>
>>> No cite needed, really. Just look around for yourself and you'll find
>>> *plenty* of files with resource forks.
>>
>> The existence of files with resource forks isn't at issue.
>
> Wrong. It's precisely the issue since we are talking about whether APFS
> will support resource forks. The fact is Finder, Safari, and other parts
> of OS X do indeed use resource forks.
>
>> Your claim is that the Finder REQUIRES at least one resource fork...
>> ...somewhere.
>
> Don't try to put words I never said into my mouth. I never said that -
> you made it up.
"What component of the current OS requires a file system resource fork?"
>
Jolly Roger
Jun 28, 2016, 7:14:15 PM6/28/16
to
On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
> On 2016-06-28 3:10 PM, nospam wrote:
>> In article <nkurhp$mmf$1...@news.datemas.de>, Alan Baker
>> <alang...@telus.net> wrote:
>>
>>>>>> it's going to have to support resource forks since macos still uses
>>>>>> them.
>>>>>
>>>>> Where does the OS itself still do that?
>>>>
>>>> Resource forks are still used all over the place. Here's a webloc file I
>>>> created by dragging the favicon of macsurfer.com from the Safari
>>>> location bar to my desktop:
>>>>
>>>> [snip]
>> In article <nkurhp$mmf$1...@news.datemas.de>, Alan Baker
>> <alang...@telus.net> wrote:
>>
>>>>>> it's going to have to support resource forks since macos still uses
>>>>>> them.
>>>>>
>>>>> Where does the OS itself still do that?
>>>>
>>>> Resource forks are still used all over the place. Here's a webloc file I
>>>> created by dragging the favicon of macsurfer.com from the Safari
>>>> location bar to my desktop:
>>>>
>>>
>>> None of that is a part of the OS.
>>
>> of course it is.
>
> Nope. It is a part of a third party application
Safari is *not* a third-party application, since it is (a) made by
>>> None of that is a part of the OS.
>>
>> of course it is.
>
> Nope. It is a part of a third party application
Apple, the first party, and (b) is included with every single copy of OS
X. The same applies to Finder. It is also not a third-party application.
Why are you here, except to make nonsensical arguments in an otherwise
productive thread?
Jolly Roger
Jun 28, 2016, 7:16:33 PM6/28/16
to
> "What component of the current OS REQUIRES a file system resource fork?"
The parts that create resource forks require the file system to support
resource forks, obviously. In this thread two examples have been given:
Finder and Safari. And there are plenty of others.
Jolly Roger
Jun 28, 2016, 7:19:43 PM6/28/16
to
On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
> On 2016-06-28 3:10 PM, Jolly Roger wrote:
>> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>>> On 2016-06-28 12:36 PM, Jolly Roger wrote:
>>>> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>>>>> On 2016-06-28 7:39 AM, nospam wrote:
>>>>>> In article <dtecqc...@mid.individual.net>, Jolly Roger
>>>>>> <jolly...@pobox.com> wrote:
>>>>>>
>>>>>> it's going to have to support resource forks since macos still uses
>>>>>> them.
>>>>>
>>>>> Where does the OS itself still do that?
>>>>
>>>> Resource forks are still used all over the place. Here's a webloc file I
>>>> created by dragging the favicon of macsurfer.com from the Safari
>>>> location bar to my desktop:
>>>>
>>>> [snip]
>>>
>>> None of that is a part of the OS.
>>
>> He said macOS *uses* resource forks. Safari is a built-in Apple
>
> But the question he was answering was what part of the OS REQUIRES
> resource forks.
And the answer is still Safari since it cannot create resource forks if
> On 2016-06-28 3:10 PM, Jolly Roger wrote:
>> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>>> On 2016-06-28 12:36 PM, Jolly Roger wrote:
>>>> On 2016-06-28, Alan Baker <alang...@telus.net> wrote:
>>>>> On 2016-06-28 7:39 AM, nospam wrote:
>>>>>> In article <dtecqc...@mid.individual.net>, Jolly Roger
>>>>>> <jolly...@pobox.com> wrote:
>>>>>>
>>>>>> it's going to have to support resource forks since macos still uses
>>>>>> them.
>>>>>
>>>>> Where does the OS itself still do that?
>>>>
>>>> Resource forks are still used all over the place. Here's a webloc file I
>>>> created by dragging the favicon of macsurfer.com from the Safari
>>>> location bar to my desktop:
>>>>
>>>> [snip]
>>>
>>> None of that is a part of the OS.
>>
>> He said macOS *uses* resource forks. Safari is a built-in Apple
>
> But the question he was answering was what part of the OS REQUIRES
> resource forks.
the file system does not support them. Same for Finder. And yes, they
are part of the OS.
Keep moving the goal post though, if you wish. You're arguing for the
sake of argument at this point, which is not constructive.
> Cite please (for Safari).
None needed. Drag a favicon from Safari's location bar to the Finder,
and Safari creates resources in the file's resource fork.
It is loading more messages.
0 new messages