Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.apps > #36674 > unrolled thread

tar: Pathname too long

Back to article view | Back to comp.sys.mac.apps

Contents

  tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-05 10:46 -0400
    Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-05 13:08 -0400
    Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-05 17:29 +0000
    Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-05 14:37 -0400
      Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-05 18:56 +0000
    Re: tar: Pathname too long Lewis <g.kreme@gmail.com.dontsendmecopies> - 2016-10-05 20:22 +0000
    Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-05 19:35 -0400
      Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-11 13:07 -0400
        Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-11 17:15 +0000
          Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-11 14:57 -0400
            Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-11 19:22 +0000
          Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-11 14:57 -0400
            Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-11 19:22 +0000
              Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-13 10:13 -0400
                Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-13 15:09 +0000
                Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-13 11:17 -0400
                  Re: tar: Pathname too long Barry Margolin <barmar@alum.mit.edu> - 2016-10-13 11:43 -0400
                    Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-13 15:43 -0400
                  Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-13 18:00 -0400
                    Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-13 22:01 +0000
    Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-14 09:05 -0400
      Re: tar: Pathname too long Barry Margolin <barmar@alum.mit.edu> - 2016-10-14 10:55 -0400
        Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-14 11:15 -0400
          Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-14 15:52 +0000
          Re: tar: Pathname too long Barry Margolin <barmar@alum.mit.edu> - 2016-10-14 12:48 -0400
            Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-14 13:11 -0400
              Re: tar: Pathname too long "Happy.Hobo" <Happy.Hobo@Spam.Invalid> - 2016-10-14 23:06 -0500
                Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-15 11:44 -0400
            Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-14 13:14 -0400
            Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-14 17:12 -0400
              Re: tar: Pathname too long "Happy.Hobo" <Happy.Hobo@Spam.Invalid> - 2016-10-14 23:08 -0500
                Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-15 11:52 -0400
              Re: tar: Pathname too long rlhamil@smart.net (Richard L. Hamilton) - 2016-10-16 08:43 +0000
                Re: tar: Pathname too long "Happy.Hobo" <Happy.Hobo@Spam.Invalid> - 2016-10-16 16:43 -0500
                  Re: tar: Pathname too long rlhamil@smart.net (Richard L. Hamilton) - 2016-10-17 17:46 +0000
                  Re: tar: Pathname too long Paul Sture <nospam@sture.ch> - 2016-10-18 06:39 +0200
                    Re: tar: Pathname too long dempson@actrix.gen.nz (David Empson) - 2016-10-18 20:39 +1300
                      Re: tar: Pathname too long "Happy.Hobo" <Happy.Hobo@Spam.Invalid> - 2016-10-18 12:20 -0500
                        Re: tar: Pathname too long dempson@actrix.gen.nz (David Empson) - 2016-10-19 09:15 +1300
                          Re: tar: Pathname too long nospam <nospam@nospam.invalid> - 2016-10-18 16:37 -0400
                          Re: tar: Pathname too long "Happy.Hobo" <Happy.Hobo@Spam.Invalid> - 2016-10-19 00:26 -0500
                            Re: tar: Pathname too long dempson@actrix.gen.nz (David Empson) - 2016-10-19 23:02 +1300
                              Re: tar: Pathname too long "Happy.Hobo" <Happy.Hobo@Spam.Invalid> - 2016-10-19 18:02 -0500
                                Re: tar: Pathname too long dempson@actrix.gen.nz (David Empson) - 2016-10-20 14:06 +1300
                                  Re: tar: Pathname too long "Happy.Hobo" <Happy.Hobo@Spam.Invalid> - 2016-10-19 22:57 -0500
                                    Re: tar: Pathname too long dempson@actrix.gen.nz (David Empson) - 2016-10-20 17:47 +1300
                                      Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-20 15:23 +0000
                            Re: tar: Pathname too long nospam <nospam@nospam.invalid> - 2016-10-19 08:38 -0400
                              Re: tar: Pathname too long Barry Margolin <barmar@alum.mit.edu> - 2016-10-19 11:31 -0400
                                Re: tar: Pathname too long nospam <nospam@nospam.invalid> - 2016-10-19 11:38 -0400
                                  Re: tar: Pathname too long Barry Margolin <barmar@alum.mit.edu> - 2016-10-19 11:49 -0400
                                    Re: tar: Pathname too long nospam <nospam@nospam.invalid> - 2016-10-19 12:09 -0400
                                  Re: tar: Pathname too long Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-10-19 18:22 +0200
                                    Re: tar: Pathname too long nospam <nospam@nospam.invalid> - 2016-10-19 12:33 -0400
                                      Re: tar: Pathname too long Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-10-19 18:44 +0200
                                        Re: tar: Pathname too long nospam <nospam@nospam.invalid> - 2016-10-19 12:58 -0400
                                      Re: tar: Pathname too long Lewis <g.kreme@gmail.com.dontsendmecopies> - 2016-10-20 04:25 +0000
                                        Re: tar: Pathname too long "Happy.Hobo" <Happy.Hobo@Spam.Invalid> - 2016-10-21 20:16 -0500
                                Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-19 15:47 +0000
                            Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-19 15:40 +0000
                              Re: tar: Pathname too long "Happy.Hobo" <Happy.Hobo@Spam.Invalid> - 2016-10-19 18:06 -0500
                                Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-20 00:15 +0000
                                  Re: tar: Pathname too long "Happy.Hobo" <Happy.Hobo@Spam.Invalid> - 2016-10-19 22:58 -0500
                                    Re: tar: Pathname too long nospam <nospam@nospam.invalid> - 2016-10-20 08:19 -0400
                                    Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-20 14:21 +0000
                                      Re: tar: Pathname too long "Happy.Hobo" <Happy.Hobo@Spam.Invalid> - 2016-10-21 20:23 -0500
                                        Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-22 04:26 +0000
                                          Re: tar: Pathname too long "Happy.Hobo" <Happy.Hobo@Spam.Invalid> - 2016-10-22 16:53 -0500
                                            Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-22 22:14 +0000
        Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-14 12:33 -0400
      Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-14 11:03 -0400
        Re: tar: Pathname too long Jolly Roger <jollyroger@pobox.com> - 2016-10-14 15:53 +0000
          Re: tar: Pathname too long Robert Peirce <bob@peirce-family.com> - 2016-10-14 12:56 -0400

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#37099

On 10-18-2016 15:15, David Empson wrote:
> Believe it. The Icon\r file has existed for a long time - I'm aware it
> from Mac OS 9 or earlier, and it is still being used in El Capitan (I
> haven't tried in Sierra).

I am on Sierra now.  I do most of my work in that directory in Terminal, 
and I saw the file for the first time today.  Coincidentally after using 
Windows on that directory for the first time in a week.

And if adding a custom icon is supposed to cause it, well, I haven't 
done that in years on Mac and never on Windows.  And never on the 
directory that gained one of those files today.

So it's STILL hard to believe the Mac created it.  But if so, it's a 
rather stupid bug for a Unix O.S. to make its own end-of-line character 
part of a filename.

[toc] | [prev] | [next] | [standalone]

#37105

Happy.Hobo <Happy.Hobo@Spam.Invalid> wrote:

> On 10-18-2016 15:15, David Empson wrote:
> > Believe it. The Icon\r file has existed for a long time - I'm aware it
> > from Mac OS 9 or earlier, and it is still being used in El Capitan (I
> > haven't tried in Sierra).
> 
> I am on Sierra now.  I do most of my work in that directory in Terminal,
> and I saw the file for the first time today.  Coincidentally after using
> Windows on that directory for the first time in a week.
> 
> And if adding a custom icon is supposed to cause it, well, I haven't 
> done that in years on Mac and never on Windows.  And never on the 
> directory that gained one of those files today.

I can't think of any reason for Windows to create one and I've never
seen Windows do that, nor had unexpected Icon\r files appear when
copying folders without custom icons between HFS+ and FAT volumes.

If you aren't adding your own custom icon to the folder, an obvious
candidate would be cloud sync software like Google Drive which uses
custom icons to indicate sync status, and actually modifies the icon on
the file/folder in the process.

https://www.quora.com/Why-is-Google-adding-an-invisible-corrupted-file-in-every-folder-on-my-computer

I'm not aware of Dropbox doing that, probably because Dropbox intercepts
it at a higher level and changes the icon displayed without modifying
the file.

> So it's STILL hard to believe the Mac created it.  But if so, it's a 
> rather stupid bug for a Unix O.S. to make its own end-of-line character
> part of a filename.

\r is not the end of line character on OS X, nor any other Unix system.

It was on classic Mac OS, which was why Apple chose that filename: it
was impossible to type on the keyboard so nobody was likely to have a
file with that name or be able to create one.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#37136

On 10-19-2016 05:02, David Empson wrote:
> Happy.Hobo <Happy.Hobo@Spam.Invalid> wrote:
>
>> On 10-18-2016 15:15, David Empson wrote:
>>> Believe it. The Icon\r file has existed for a long time - I'm aware it
>>> from Mac OS 9 or earlier, and it is still being used in El Capitan (I
>>> haven't tried in Sierra).
>>
>> I am on Sierra now.  I do most of my work in that directory in Terminal,
>> and I saw the file for the first time today.  Coincidentally after using
>> Windows on that directory for the first time in a week.
>>
>> And if adding a custom icon is supposed to cause it, well, I haven't
>> done that in years on Mac and never on Windows.  And never on the
>> directory that gained one of those files today.
>
> I can't think of any reason for Windows to create one and I've never
> seen Windows do that, nor had unexpected Icon\r files appear when
> copying folders without custom icons between HFS+ and FAT volumes.
>
> If you aren't adding your own custom icon to the folder, an obvious
> candidate would be cloud sync software like Google Drive which uses
> custom icons to indicate sync status, and actually modifies the icon on
> the file/folder in the process.

Hmmm.  I've never used Google Drive.   I have used Dropbox, but not with 
Windows.  I'm using MS OneDrive now, so maybe that did it.  But I'm 
pretty sure it happened the same way "back then."

FWIW, OneDrive has a very pretty UI but its usability sucks.

[toc] | [prev] | [next] | [standalone]

#37141

Happy.Hobo <Happy.Hobo@Spam.Invalid> wrote:

> On 10-19-2016 05:02, David Empson wrote:
> > Happy.Hobo <Happy.Hobo@Spam.Invalid> wrote:
> >
> >> On 10-18-2016 15:15, David Empson wrote:
> >>> Believe it. The Icon\r file has existed for a long time - I'm aware it
> >>> from Mac OS 9 or earlier, and it is still being used in El Capitan (I
> >>> haven't tried in Sierra).
> >>
> >> I am on Sierra now.  I do most of my work in that directory in Terminal,
> >> and I saw the file for the first time today.  Coincidentally after using
> >> Windows on that directory for the first time in a week.
> >>
> >> And if adding a custom icon is supposed to cause it, well, I haven't
> >> done that in years on Mac and never on Windows.  And never on the
> >> directory that gained one of those files today.
> >
> > I can't think of any reason for Windows to create one and I've never
> > seen Windows do that, nor had unexpected Icon\r files appear when
> > copying folders without custom icons between HFS+ and FAT volumes.
> >
> > If you aren't adding your own custom icon to the folder, an obvious
> > candidate would be cloud sync software like Google Drive which uses
> > custom icons to indicate sync status, and actually modifies the icon on
> > the file/folder in the process.
> 
> Hmmm.  I've never used Google Drive.   I have used Dropbox, but not with
> Windows.

Windows itself has nothing to do with it, because "Icon\r" is not a file
that Windows creates to store a custom icon on anything. Nor would most
applications on Windows be likely to do that (including Dropbox or
similar, which won't be doing Mac-specific stuff on Windows).

The only potential involvement of Windows I can think of would be if you
were running some specifically Mac-friendly third party software on
Windows which creates Mac custom icons. For example, if you were using
an HFS+ drive rather than FAT, and the HFS+ driver you are running on
Windows tries to be helpful.


Windows custom icons are implemented in a completely different way: for
an arbitrary image, a hidden desktop.ini text file in the folder
contains an IconResource key with the full path to a .ico file (this
mechanism is broken even if you put the .ico file on the removable
drive, because it assumes the drive letter is consistent between
computers).

Having just gone to the trouble of creating one of them on a Windows PC
and putting my FAT drive back in the Mac, no sign of an Icon\r file, and
the Mac does not show the Windows custom icon (even if it understood the
mechanism, where is F: on a Mac?).


Setting aside the possibility of Windows third party software, the most
likely explanation is that something on your Mac is setting a custom
icon for that folder, and it was a coincidence that you only noticed it
after the drive was connected to Windows.

If you didn't set that icon yourself in Finder, or sync the folder with
one which already had a Mac custom icon, then some other software
running on your Mac deliberately created a custom icon for that folder.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#37142

On 10-19-2016 20:06, David Empson wrote:
> Setting aside the possibility of Windows third party software, the most
> likely explanation is that something on your Mac is setting a custom
> icon for that folder, and it was a coincidence that you only noticed it
> after the drive was connected to Windows.

Possible that it happened on the Mac.  Unlikely that anything created a 
custom icon for the folder because

(1) only things that touch that folder are rsync, LibreOffice, TextEdit,
     OneDrive, Finder, and various shell commands

(2) the folder doesn't have a custom icon

If it _had_ a custom icon, I'd blame OneDrive.

[toc] | [prev] | [next] | [standalone]

#37145

Happy.Hobo <Happy.Hobo@Spam.Invalid> wrote:

> On 10-19-2016 20:06, David Empson wrote:
> > Setting aside the possibility of Windows third party software, the most
> > likely explanation is that something on your Mac is setting a custom
> > icon for that folder, and it was a coincidence that you only noticed it
> > after the drive was connected to Windows.
> 
> Possible that it happened on the Mac.  Unlikely that anything created a
> custom icon for the folder because
> 
> (1) only things that touch that folder are rsync, LibreOffice, TextEdit,
>      OneDrive, Finder, and various shell commands
> 
> (2) the folder doesn't have a custom icon

It may not look like it has a custom icon, but it may have a custom icon
which is the same image as the standard one.

You can check by doing a Get Info in Finder, clicking on the icon in the
top left corner, clicking on the Edit menu and seeing whether the Cut
command is enabled. If so, it has a custom icon. Using Cut (or pressing
the delete key) to get rid of the custom icon should also delete the
Icon\r file which you can confirm using Terminal.

> If it _had_ a custom icon, I'd blame OneDrive.

That's the most likely source out of the applications you mentioned.
Same problem as Google Drive - OneDrive may be setting custom icons to
indicate sync status (I've never used it so don't know if it does that
or how it is implemented).

The other possibility is rsync with another copy of the folder which
already had a custom icon.

-- 
David Empson
dempson@actrix.gen.nz

[toc] | [prev] | [next] | [standalone]

#37151

On 2016-10-20, David Empson <dempson@actrix.gen.nz> wrote:
> Happy.Hobo <Happy.Hobo@Spam.Invalid> wrote:
>
>> On 10-19-2016 20:06, David Empson wrote:
>> > Setting aside the possibility of Windows third party software, the most
>> > likely explanation is that something on your Mac is setting a custom
>> > icon for that folder, and it was a coincidence that you only noticed it
>> > after the drive was connected to Windows.
>> 
>> Possible that it happened on the Mac.  Unlikely that anything created a
>> custom icon for the folder because
>> 
>> (1) only things that touch that folder are rsync, LibreOffice, TextEdit,
>>      OneDrive, Finder, and various shell commands
>> 
>> (2) the folder doesn't have a custom icon
>
> It may not look like it has a custom icon, but it may have a custom icon
> which is the same image as the standard one.

Yep.

> You can check by doing a Get Info in Finder, clicking on the icon in the
> top left corner, clicking on the Edit menu and seeing whether the Cut
> command is enabled. If so, it has a custom icon. Using Cut (or pressing
> the delete key) to get rid of the custom icon should also delete the
> Icon\r file which you can confirm using Terminal.

Yep. And if you highlight the icon in the Info window and copy it,
choosing Edit > Show Clipboard from the Finder's menu bar will show you
the icon you copied. Then if you open Preview and create a new document,
the icon will be inserted into the new document automatically, and you
can save it as a regular image file to re-use again in the future.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#37106

In article <nu7065$rjd$1@gioia.aioe.org>, Happy.Hobo
<Happy.Hobo@Spam.Invalid> wrote:

> > Believe it. The Icon\r file has existed for a long time - I'm aware it
> > from Mac OS 9 or earlier, and it is still being used in El Capitan (I
> > haven't tried in Sierra).
> 
> I am on Sierra now.  I do most of my work in that directory in Terminal, 
> and I saw the file for the first time today.  Coincidentally after using 
> Windows on that directory for the first time in a week.
> 
> And if adding a custom icon is supposed to cause it, well, I haven't 
> done that in years on Mac and never on Windows.  And never on the 
> directory that gained one of those files today.
>
> So it's STILL hard to believe the Mac created it.  But if so, it's a 
> rather stupid bug for a Unix O.S. to make its own end-of-line character 
> part of a filename.

it's not a bug and a perfectly valid character in a file name.

[toc] | [prev] | [next] | [standalone]

#37113

In article <191020160838412447%nospam@nospam.invalid>,
 nospam <nospam@nospam.invalid> wrote:

> In article <nu7065$rjd$1@gioia.aioe.org>, Happy.Hobo
> <Happy.Hobo@Spam.Invalid> wrote:
> 
> > > Believe it. The Icon\r file has existed for a long time - I'm aware it
> > > from Mac OS 9 or earlier, and it is still being used in El Capitan (I
> > > haven't tried in Sierra).
> > 
> > I am on Sierra now.  I do most of my work in that directory in Terminal, 
> > and I saw the file for the first time today.  Coincidentally after using 
> > Windows on that directory for the first time in a week.
> > 
> > And if adding a custom icon is supposed to cause it, well, I haven't 
> > done that in years on Mac and never on Windows.  And never on the 
> > directory that gained one of those files today.
> >
> > So it's STILL hard to believe the Mac created it.  But if so, it's a 
> > rather stupid bug for a Unix O.S. to make its own end-of-line character 
> > part of a filename.
> 
> it's not a bug and a perfectly valid character in a file name.

It's surprising that they didn't change the name in OS X to begin with 
".", as that's the Unix convention for hidden filenames.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[toc] | [prev] | [next] | [standalone]

#37116

In article <barmar-3F965A.11311919102016@88-209-239-213.giganet.hu>,
Barry Margolin <barmar@alum.mit.edu> wrote:

> > >
> > > So it's STILL hard to believe the Mac created it.  But if so, it's a 
> > > rather stupid bug for a Unix O.S. to make its own end-of-line character 
> > > part of a filename.
> > 
> > it's not a bug and a perfectly valid character in a file name.
> 
> It's surprising that they didn't change the name in OS X to begin with 
> ".", as that's the Unix convention for hidden filenames.

it's not surprising at all because the issue is not being invisible or
hidden, but that there's no way to create a file with \r in via the
keyboard, thereby making it impossible for there to be a name conflict.

had it been changed to .icon, not only would it be incompatible with
classic mac os, but if the user happened to name something with the
same name (easily done, since . is easy to type, even by accident), all
sorts of problems would occur.

[toc] | [prev] | [next] | [standalone]

#37120

In article <191020161138480830%nospam@nospam.invalid>,
 nospam <nospam@nospam.invalid> wrote:

> In article <barmar-3F965A.11311919102016@88-209-239-213.giganet.hu>,
> Barry Margolin <barmar@alum.mit.edu> wrote:
> 
> > > >
> > > > So it's STILL hard to believe the Mac created it.  But if so, it's a 
> > > > rather stupid bug for a Unix O.S. to make its own end-of-line character 
> > > > part of a filename.
> > > 
> > > it's not a bug and a perfectly valid character in a file name.
> > 
> > It's surprising that they didn't change the name in OS X to begin with 
> > ".", as that's the Unix convention for hidden filenames.
> 
> it's not surprising at all because the issue is not being invisible or
> hidden, but that there's no way to create a file with \r in via the
> keyboard, thereby making it impossible for there to be a name conflict.
> 
> had it been changed to .icon, not only would it be incompatible with
> classic mac os, but if the user happened to name something with the
> same name (easily done, since . is easy to type, even by accident), all
> sorts of problems would occur.

I was thinking it would be .icon\r. So it would be both invisible and 
hard to create.

Note that you CAN create it via the keyboard using Terminal.

touch $'icon\r'

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[toc] | [prev] | [next] | [standalone]

#37121

In article <barmar-4511C0.11494719102016@88-209-239-213.giganet.hu>,
Barry Margolin <barmar@alum.mit.edu> wrote:

> > > It's surprising that they didn't change the name in OS X to begin with 
> > > ".", as that's the Unix convention for hidden filenames.
> > 
> > it's not surprising at all because the issue is not being invisible or
> > hidden, but that there's no way to create a file with \r in via the
> > keyboard, thereby making it impossible for there to be a name conflict.
> > 
> > had it been changed to .icon, not only would it be incompatible with
> > classic mac os, but if the user happened to name something with the
> > same name (easily done, since . is easy to type, even by accident), all
> > sorts of problems would occur.
> 
> I was thinking it would be .icon\r. So it would be both invisible and 
> hard to create.

no need for that, since hfs supports invisible files directly.

the only reason unix uses . to denote invisible is because there wasn't
any other way to do it.

it would be a huge step backwards to name it .icon\r, not to mention
breaking things.

> Note that you CAN create it via the keyboard using Terminal.
> 
> touch $'icon\r'

note that you can fuck up a lot of stuff in terminal. so what? 

the point is users can't create such a file in normal use, including in
finder or a standard save dialog. someone would have to go well out of
their way to create it and anyone who knows how would know what the
risks are.

[toc] | [prev] | [next] | [standalone]

#37122

nospam babbled:

> In article <barmar-3F965A.11311919102016@88-209-239-213.giganet.hu>,
> Barry Margolin <barmar@alum.mit.edu> wrote:
> 
>> > >
>> > > So it's STILL hard to believe the Mac created it.  But if so, it's a
>> > > rather stupid bug for a Unix O.S. to make its own end-of-line
>> > > character part of a filename.
>> > 
>> > it's not a bug and a perfectly valid character in a file name.

No, it is not "perfectly valid". It is usually strongly advised to *not* use 
control characters in file names. Even if it is possible on one system, the 
same name might be invalid on a different OS
In my own software (which is crossplatform for windows, OSX and linux) I 
even use a table of characters which comprises all invalid characters of all 
three OS to check against when creating a filename, making thus certain that 
(for example) the OSX version created file can be opened and read by the 
windows version of the software

>> It's surprising that they didn't change the name in OS X to begin with
>> ".", as that's the Unix convention for hidden filenames.
> 
> it's not surprising at all because the issue is not being invisible or
> hidden, but that there's no way to create a file with \r in via the
> keyboard, 

Sure is. It is even simple

> thereby making it impossible for there to be a name conflict.

"Impossible" is it for you to think. When it can be created 
programmatically, it is already possible. And since you can even create it 
very simple via keyboard, it is far from "impossible"

It may be for some dimbulbs (that would certainly include you) who can 
barely use a computer via GUI, but not every computer user is so severly 
limited

[toc] | [prev] | [next] | [standalone]

#37123

In article <nu86ir$mue$1@dont-email.me>, Peter Köhlmann
<peter-koehlmann@t-online.de> wrote:

> >> > > So it's STILL hard to believe the Mac created it.  But if so, it's a
> >> > > rather stupid bug for a Unix O.S. to make its own end-of-line
> >> > > character part of a filename.
> >> > 
> >> > it's not a bug and a perfectly valid character in a file name.
> 
> No, it is not "perfectly valid". 

it's perfectly valid.

the *only* character that is not allowed on hfs is a colon (:) because
hfs uses that as a path separator. everything else is valid.

the unix layer of os x translates slash (/), which is unix's path
separator, to a colon for hfs. 

apps that use unix apis can't use / in a file name (but can use : ),
while apps that use classic mac apis can't use : (but can use / ).

windows is the worst, with a whole slew of forbidden characters.

[toc] | [prev] | [next] | [standalone]

#37124

nospam wrote:

> In article <nu86ir$mue$1@dont-email.me>, Peter Köhlmann
> <peter-koehlmann@t-online.de> wrote:
> 
>> >> > > So it's STILL hard to believe the Mac created it.  But if so, it's
>> >> > > a rather stupid bug for a Unix O.S. to make its own end-of-line
>> >> > > character part of a filename.
>> >> > 
>> >> > it's not a bug and a perfectly valid character in a file name.
>> 
>> No, it is not "perfectly valid".
> 
> it's perfectly valid.
> 
> the *only* character that is not allowed on hfs is a colon (:) because
> hfs uses that as a path separator. everything else is valid.
> 
> the unix layer of os x translates slash (/), which is unix's path
> separator, to a colon for hfs.
> 
> apps that use unix apis can't use / in a file name (but can use : ),
> while apps that use classic mac apis can't use : (but can use / ).
> 
> windows is the worst, with a whole slew of forbidden characters.

Oh, just create a file foo/bar.docx and try to open it with word

Perfectly valid filename, and perfectly unuseable for some applications

There is a reason why some characters should be avoided

[toc] | [prev] | [next] | [standalone]

#37125

In article <nu87ta$rrq$1@dont-email.me>, Peter Köhlmann
<peter-koehlmann@t-online.de> wrote:

> > windows is the worst, with a whole slew of forbidden characters.
>
> Oh, just create a file foo/bar.docx and try to open it with word
>
> Perfectly valid filename, and perfectly unuseable for some applications

only because word is trying to being compatible with windows and not
using the file system apis correctly. there might even be some common
code between the two platforms.

other apps do not have a problem with / in the file name.

> There is a reason why some characters should be avoided

except that's not one of them.

[toc] | [prev] | [next] | [standalone]

#37144

In message <191020161233005977%nospam@nospam.invalid> 
  nospam <nospam@nospam.invalid> wrote:
> In article <nu86ir$mue$1@dont-email.me>, Peter Köhlmann
> <peter-koehlmann@t-online.de> wrote:

>> >> > > So it's STILL hard to believe the Mac created it.  But if so, it's a
>> >> > > rather stupid bug for a Unix O.S. to make its own end-of-line
>> >> > > character part of a filename.
>> >> > 
>> >> > it's not a bug and a perfectly valid character in a file name.
>> 
>> No, it is not "perfectly valid". 

> it's perfectly valid.

> the *only* character that is not allowed on hfs is a colon (:) because
> hfs uses that as a path separator. everything else is valid.

> the unix layer of os x translates slash (/), which is unix's path
> separator, to a colon for hfs. 

> apps that use unix apis can't use / in a file name (but can use : ),
> while apps that use classic mac apis can't use : (but can use / ).

> windows is the worst, with a whole slew of forbidden characters.

"...^h" is a fun name for a directory.

-- 
'An appointment is an engagement to see someone, while a morningstar is
a large lump of metal used for viciously crushing skulls. It is
important not to confuse the two.'

[toc] | [prev] | [next] | [standalone]

#37171

On 10-19-2016 23:25, Lewis wrote:
> "...^h" is a fun name for a directory.

What kind of smiley is C:\  ?

[toc] | [prev] | [next] | [standalone]

#37119

On 2016-10-19, Barry Margolin <barmar@alum.mit.edu> wrote:
> In article <191020160838412447%nospam@nospam.invalid>,
>  nospam <nospam@nospam.invalid> wrote:
>
>> In article <nu7065$rjd$1@gioia.aioe.org>, Happy.Hobo
>> <Happy.Hobo@Spam.Invalid> wrote:
>> 
>> > > Believe it. The Icon\r file has existed for a long time - I'm aware it
>> > > from Mac OS 9 or earlier, and it is still being used in El Capitan (I
>> > > haven't tried in Sierra).
>> > 
>> > I am on Sierra now.  I do most of my work in that directory in Terminal, 
>> > and I saw the file for the first time today.  Coincidentally after using 
>> > Windows on that directory for the first time in a week.
>> > 
>> > And if adding a custom icon is supposed to cause it, well, I haven't 
>> > done that in years on Mac and never on Windows.  And never on the 
>> > directory that gained one of those files today.
>> >
>> > So it's STILL hard to believe the Mac created it.  But if so, it's a 
>> > rather stupid bug for a Unix O.S. to make its own end-of-line character 
>> > part of a filename.
>> 
>> it's not a bug and a perfectly valid character in a file name.
>
> It's surprising that they didn't change the name in OS X to begin with 
> ".", as that's the Unix convention for hidden filenames.

Why? If it ain't broke...

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#37117

On 2016-10-19, Happy.Hobo <Happy.Hobo@Spam.Invalid> wrote:
> On 10-18-2016 15:15, David Empson wrote:
>> Believe it. The Icon\r file has existed for a long time - I'm aware it
>> from Mac OS 9 or earlier, and it is still being used in El Capitan (I
>> haven't tried in Sierra).
>
> I am on Sierra now.  I do most of my work in that directory in
> Terminal, and I saw the file for the first time today.  Coincidentally
> after using Windows on that directory for the first time in a week.

Yep, that was just a coincidence.

> And if adding a custom icon is supposed to cause it, well, I haven't
> done that in years on Mac and never on Windows.  And never on the
> directory that gained one of those files today.

Perhaps it wasn't *you* specifically who set the custom icon on that
folder. If you obtain files from someone else, custom icons can along
for the ride. ; )

> So it's STILL hard to believe the Mac created it.

That doesn't change reality. Macs have created these files for custom
folder icons since the very early days. No other operating system that I
know of creates them.

> But if so, it's a rather stupid bug for a Unix O.S. to make its own
> end-of-line character part of a filename.

Nope. It's a feature. Specifically, Apple wanted to ensure that custom
icon files were not overwritten by users by adding a character that
users could not type into file names. And since these icon files don't
cause any problems, it's hardly worthy of the "bug" label.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.sys.mac.apps

csiph-web