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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#36899

Ah, the peculiarities of shell scripts.  Can anybody explain this?

When I ran this simple test it failed with the Pathname too long error:

LIST="35mmNegativeScans Ada AdaAndDeclan APOD Declan 
iPhone.photoslibrary iTunes Miscellaneous Movies ScannedImages Tests 
ThingsThatGo Weddings Wintergreen"

rm -f ~/pictures.t
cd /Volumes/Pictures/
for i in $LIST
do
	find ./$i -type f  -newer TS -print0 |
	xargs -0 tar -rf ~/pictures.t
done

However, if I did this it worked:

LIST=iTunes

rm -f ~/pictures.t
cd /Volumes/Pictures/
for i in $LIST
do
	find ./$i -type f  -newer TS -print0 |
	xargs -0 tar -rf ~/pictures.t
done

I changed my original script to remove iTunes from LIST and ran the 
command on iTunes by itself and then in a loop for LIST.  That worked, 
but I have no idea why.

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

#36900

In article <ntql6d$se2$1@gioia.aioe.org>,
 Robert Peirce <bob@peirce-family.com> wrote:

> Ah, the peculiarities of shell scripts.  Can anybody explain this?
> 
> When I ran this simple test it failed with the Pathname too long error:
> 
> LIST="35mmNegativeScans Ada AdaAndDeclan APOD Declan 
> iPhone.photoslibrary iTunes Miscellaneous Movies ScannedImages Tests 
> ThingsThatGo Weddings Wintergreen"
> 
> rm -f ~/pictures.t
> cd /Volumes/Pictures/
> for i in $LIST
> do
> 	find ./$i -type f  -newer TS -print0 |
> 	xargs -0 tar -rf ~/pictures.t
> done
> 
> However, if I did this it worked:
> 
> LIST=iTunes
> 
> rm -f ~/pictures.t
> cd /Volumes/Pictures/
> for i in $LIST
> do
> 	find ./$i -type f  -newer TS -print0 |
> 	xargs -0 tar -rf ~/pictures.t
> done
> 
> I changed my original script to remove iTunes from LIST and ran the 
> command on iTunes by itself and then in a loop for LIST.  That worked, 
> but I have no idea why.

I'm getting lost in the thread. Was your error from tar or xargs?

If it's from xargs, this is incredibly confusing -- I can't think of any 
way that xargs could be influenced by the list you're looping over.

If it's from tar, it could be related to the fact that the first script 
was adding the iTunes files to an existing archive, while the second one 
is starting from empty. I'm not sure why that would make a difference, 
but at least it's something not totally non-sensical.

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

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

#36902

On 10/14/16 10:55 AM, Barry Margolin wrote:
> I'm getting lost in the thread. Was your error from tar or xargs?
>
> If it's from xargs, this is incredibly confusing -- I can't think of any
> way that xargs could be influenced by the list you're looping over.
>
> If it's from tar, it could be related to the fact that the first script
> was adding the iTunes files to an existing archive, while the second one
> is starting from empty. I'm not sure why that would make a difference,
> but at least it's something not totally non-sensical.
>

Understandable.  The error is "xargs: Pathname is too long."  The paths 
in question are Podcasts within the iTunes directory.  The other 
directories have never caused me any problems but iTunes is a recurring 
problem because Podcasts come and go as do occasional really long 
classical music titles.

In my next post I note that putting iTunes first in LIST solves the 
problem but I have absolutely no idea why.

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

#36903

On 2016-10-14, Robert Peirce <bob@peirce-family.com> wrote:
>
> Understandable.  The error is "xargs: Pathname is too long."  The paths 
> in question are Podcasts within the iTunes directory.

Please paste the actual verbatim error message in the future. 

(I swear I've asked you to do this before...)

-- 
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]

#36906

In article <ntqsq3$19rt$1@gioia.aioe.org>,
 Robert Peirce <bob@peirce-family.com> wrote:

> On 10/14/16 10:55 AM, Barry Margolin wrote:
> > I'm getting lost in the thread. Was your error from tar or xargs?
> >
> > If it's from xargs, this is incredibly confusing -- I can't think of any
> > way that xargs could be influenced by the list you're looping over.
> >
> > If it's from tar, it could be related to the fact that the first script
> > was adding the iTunes files to an existing archive, while the second one
> > is starting from empty. I'm not sure why that would make a difference,
> > but at least it's something not totally non-sensical.
> >
> 
> Understandable.  The error is "xargs: Pathname is too long."

I can't even find that error message in the xargs source code. What OS 
release are you running?

FYI, you can find OS X open source code at opensource.apple.com. For 
xargs, start by selecting the OS release, then from the list of projects 
select shell_cmds-###, then select xargs.

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

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

#36908

On 10/14/16 12:48 PM, Barry Margolin wrote:
>> Understandable.  The error is "xargs: Pathname is too long."
>
> I can't even find that error message in the xargs source code. What OS
> release are you running?
>
> FYI, you can find OS X open source code at opensource.apple.com. For
> xargs, start by selecting the OS release, then from the list of projects
> select shell_cmds-###, then select xargs.
>
I am running 10.11.6.  The actual error is "xargs: Pathname too long." 
I inadvertently inserted an "is."  On the prevous version of this 
script, before xargs, it was "tar: Pathname too long."  I have no way of 
knowing if tar or xargs is actually producing the error message or if it 
is coming from somewhere else.

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

#36917

On 10-14-2016 12:11, Robert Peirce wrote:
> I am running 10.11.6.  The actual error is "xargs: Pathname too long." I
> inadvertently inserted an "is."  On the prevous version of this script,
> before xargs, it was "tar: Pathname too long."  I have no way of knowing
> if tar or xargs is actually producing the error message or if it is
> coming from somewhere else.

The program asked the operating system to do something with a pathname 
the OS didn't like.  The shell gives the name of the program that made 
the call, a colon, then the error that came from the O.S.

It may be that there really was a pathname too long, or it may be that 
more than one pathname was in the same set of quote marks, or a space 
between names was escaped, effectively combining the names.

There are probably the possible causes, but those are the first three 
that come to me.

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

#36927

On 10/15/16 12:06 AM, Happy.Hobo wrote:
> The program asked the operating system to do something with a pathname
> the OS didn't like.  The shell gives the name of the program that made
> the call, a colon, then the error that came from the O.S.

Makes sense.  That's the only thing I can think of.

Where would the "Pathname too long" actually come from?  Is there a file 
of error messages the kernel uses?

> It may be that there really was a pathname too long, or it may be that
> more than one pathname was in the same set of quote marks, or a space
> between names was escaped, effectively combining the names.

I wonder why it would matter whether it was passed to xargs at the 
beginning of the list rather than the middle.  The actual error line 
doesn't correspond to any file at the beginning of the directory either, 
nor is it really all that long.

You are probably right but it is still very confusing.

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

#36909

On 10/14/16 12:48 PM, Barry Margolin wrote:
> I can't even find that error message in the xargs source code. What OS
> release are you running?

I should have mentioned that this problem goes back several OS releases.

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

#36911

On 10/14/16 12:48 PM, Barry Margolin wrote:
> I can't even find that error message in the xargs source code. What OS
> release are you running?
>
Nor does it seem to be in tar.  This caused me to run strings on bash, 
csh, ksh & sh.  It isn't there and it isn't in kernel either, so I have 
no idea what is generating it.

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

#36918

On 10-14-2016 16:12, Robert Peirce wrote:
> Nor does it seem to be in tar.  This caused me to run strings on bash,
> csh, ksh & sh.  It isn't there and it isn't in kernel either, so I have
> no idea what is generating it.

Could be in UTF-8 or UTF-16, and your search may have been using ASCII.

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

#36929

On 10/15/16 12:08 AM, Happy.Hobo wrote:
> On 10-14-2016 16:12, Robert Peirce wrote:
>> Nor does it seem to be in tar.  This caused me to run strings on bash,
>> csh, ksh & sh.  It isn't there and it isn't in kernel either, so I have
>> no idea what is generating it.
>
> Could be in UTF-8 or UTF-16, and your search may have been using ASCII.

I never encountered a case where a string imbedded in a program wasn't 
ASCII, but I guess that is a possibility.

The command I used in each case was:

strings -a program-name | grep Pathname

That has always worked before.

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

#36936

In article <ntrho8$c3p$1@gioia.aioe.org>,
	Robert Peirce <bob@peirce-family.com> writes:
> On 10/14/16 12:48 PM, Barry Margolin wrote:
>> I can't even find that error message in the xargs source code. What OS
>> release are you running?
>>
> Nor does it seem to be in tar.  This caused me to run strings on bash, 
> csh, ksh & sh.  It isn't there and it isn't in kernel either, so I have 
> no idea what is generating it.


You also have to check dynamically linked libraries:

sh-3.2$ otool -L /usr/bin/tar
/usr/bin/tar:
	/usr/lib/libarchive.2.dylib (compatibility version 9.0.0, current version 9.2.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

sh-3.2$ strings /usr/lib/libarchive.2.dylib|grep -i 'pathname too long'
Pathname too long

And now we proceed to serious advice ("Use the Source, Luke."):

The most recent version of the source file on Apple's opensource web
site is
https://opensource.apple.com/source/libarchive/libarchive-33.20.2/libarchive/libarchive/archive_write_set_format_ustar.c

It looks like there are 100 bytes set aside for a pathname; if it's
too long, it tries to split it at a slash and store the rest
separately, but if there's a single name component (between slashes)
that's too long, it can fail.

Ideally, it would handle lengths up to the limits at which open(2)
fails with ENAMETOOLONG:

sh-3.2$ getconf PATH_MAX /
1024
sh-3.2$ getconf NAME_MAX /
255

(the whole pathname and a single level of the name, respectively;
those are however filesystem-specific limits, but that's typical for
an HFS+ filesystem)

Unfortunately, it looks to me like the already existing "tar" archive
format had that 100 character limitation.  Archive formats are subject
to compatibility issues going WAY back, to when those limits were
lower.  The limits for the tar and ustar formats are mentioned in the
"pax" man page:


PAX(1)			  BSD General Commands Manual			PAX(1)
[...]

     -x format
	     Specify the output archive format, with the default format being
	     ustar.  pax currently supports the following formats:

	     bcpio    The old binary cpio format.  The default blocksize for
		      this format is 5120 bytes.  This format is not very por-
		      table and should not be used when other formats are
		      available.  Inode and device information about a file
		      (used for detecting file hard links by this format),
		      which may be truncated by this format, is detected by
		      pax and is repaired.

	     cpio     The extended cpio interchange format specified in the
		      IEEE Std 1003.2 (``POSIX.2'') standard.  The default
		      blocksize for this format is 5120 bytes.	Inode and
		      device information about a file (used for detecting file
		      hard links by this format), which may be truncated by
		      this format, is detected by pax and is repaired.

	     sv4cpio  The System V release 4 cpio.  The default blocksize for
		      this format is 5120 bytes.  Inode and device information
		      about a file (used for detecting file hard links by this
		      format), which may be truncated by this format, is
		      detected by pax and is repaired.

	     sv4crc   The System V release 4 cpio with file CRC checksums.
		      The default blocksize for this format is 5120 bytes.
		      Inode and device information about a file (used for
		      detecting file hard links by this format), which may be
		      truncated by this format, is detected by pax and is
		      repaired.

	     tar      The old BSD tar format as found in 4.3BSD.  The default
		      blocksize for this format is 10240 bytes.  Pathnames
		      stored by this format must be 100 characters or less in
		      length.  Only regular files, hard links, soft links, and
		      directories will be archived (other file system types
		      are not supported).  For backwards compatibility with
		      even older tar formats, a -o option can be used when
		      writing an archive to omit the storage of directories.
		      This option takes the form:

			    -o write_opt=nodir

	     ustar    The extended tar interchange format specified in the
		      IEEE Std 1003.2 (``POSIX.2'') standard.  The default
		      blocksize for this format is 10240 bytes.  Filenames
		      stored by this format must be 100 characters or less in
		      length; the total pathname must be 255 characters or
		      less.

	     pax will detect and report any file that it is unable to store or
	     extract as the result of any specific archive format restric-
	     tions.  The individual archive formats may impose additional
	     restrictions on use.  Typical archive format restrictions include
	     (but are not limited to): file pathname length, file size, link
	     pathname length, and the type of the file.


What would I do?  Probably use "pax" but specify the "cpio" format.
Why use pax instead of cpio?  Because cpio expects to be fed a list of
newline-separated pathnames (usually from "find") on standard input,
but there _could_ be a newline embedded in a pathname, which it
couldn't distinguish from one ending a pathname in the input.  Pax in
write mode behaves more like tar, and descends a directory argument,
so assuming the cpio format itself isn't bothered by newlines in a
pathname, and that it's limit is longer than the tar format (I haven't
actually checked those assumptions!), that's probably as good as
you're going to get with a standard and widely supported format.

-- 
ftp> get |fortune
377 I/O error: smart remark generator failed

Bogonics: the primary language inside the Beltway

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"
(read act 2, scene 6 of the play if that doesn't make sense)

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

#36940

On 10-16-2016 03:43, Richard L. Hamilton wrote:
> but there _could_ be a newline embedded in a pathname, which it

Indeed, if you share directories with Windows via media, you will likely 
frequently see files named Icon<EOL>

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

#36994

In article <nu0sa5$1kif$1@gioia.aioe.org>,
	"Happy.Hobo" <Happy.Hobo@Spam.Invalid> writes:
> On 10-16-2016 03:43, Richard L. Hamilton wrote:
>> but there _could_ be a newline embedded in a pathname, which it
> 
> Indeed, if you share directories with Windows via media, you will likely 
> frequently see files named Icon<EOL>

The EOL in those is a carriage return, not a newline aka linefeed, so
I would not have expected it to cause problems.  Testing indicates that
it does, though.

Looking around, I see that "find" on a Mac has -print0, and cpio has a -0
(zero) option, so one could do

find mydir -print0|cpio -o0 >testing.cpio

and it would handle names with newlines in them (tried, it works).

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

#37043

On 2016-10-16, Happy.Hobo <Happy.Hobo@Spam.Invalid> wrote:
> On 10-16-2016 03:43, Richard L. Hamilton wrote:
>> but there _could_ be a newline embedded in a pathname, which it
>
> Indeed, if you share directories with Windows via media, you will
> likely frequently see files named Icon<EOL>

I've seen this in icon files buried inside .app bundles from third
party suppliers.  I assume that somewhere along the line a Windows
system was used in developing or maintaining those icons.

-- 
My kettle isn't connected to the internet.

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

#37048

Paul Sture <nospam@sture.ch> wrote:

> On 2016-10-16, Happy.Hobo <Happy.Hobo@Spam.Invalid> wrote:
> > On 10-16-2016 03:43, Richard L. Hamilton wrote:
> >> but there _could_ be a newline embedded in a pathname, which it
> >
> > Indeed, if you share directories with Windows via media, you will
> > likely frequently see files named Icon<EOL>
> 
> I've seen this in icon files buried inside .app bundles from third
> party suppliers.  I assume that somewhere along the line a Windows
> system was used in developing or maintaining those icons.

That is the standard filename used by Finder when you add a custom icon
to a folder. The custom icon is in the resource fork of the "Icon\r"
file.

-- 
David Empson
dempson@actrix.gen.nz

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

#37053

On 10-18-2016 02:39, David Empson wrote:
> Paul Sture <nospam@sture.ch> wrote:
>
>> On 2016-10-16, Happy.Hobo <Happy.Hobo@Spam.Invalid> wrote:
>>> On 10-16-2016 03:43, Richard L. Hamilton wrote:
>>>> but there _could_ be a newline embedded in a pathname, which it
>>>
>>> Indeed, if you share directories with Windows via media, you will
>>> likely frequently see files named Icon<EOL>
>>
>> I've seen this in icon files buried inside .app bundles from third
>> party suppliers.  I assume that somewhere along the line a Windows
>> system was used in developing or maintaining those icons.
>
> That is the standard filename used by Finder when you add a custom icon
> to a folder. The custom icon is in the resource fork of the "Icon\r"
> file.

So Windows is adding Mac resource forks to directories?  I find that 
hard to believe.  It only happens (or so it seems) when I use a portable 
storage on Windows.

I also find it hard to believe that Finder would create a filename that 
is such a nuisance to deal with.

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

#37058

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

> On 10-18-2016 02:39, David Empson wrote:
> > Paul Sture <nospam@sture.ch> wrote:
> >
> >> On 2016-10-16, Happy.Hobo <Happy.Hobo@Spam.Invalid> wrote:
> >>> On 10-16-2016 03:43, Richard L. Hamilton wrote:
> >>>> but there _could_ be a newline embedded in a pathname, which it
> >>>
> >>> Indeed, if you share directories with Windows via media, you will
> >>> likely frequently see files named Icon<EOL>
> >>
> >> I've seen this in icon files buried inside .app bundles from third
> >> party suppliers.  I assume that somewhere along the line a Windows
> >> system was used in developing or maintaining those icons.
> >
> > That is the standard filename used by Finder when you add a custom icon
> > to a folder. The custom icon is in the resource fork of the "Icon\r"
> > file.
> 
> So Windows is adding Mac resource forks to directories?  I find that 
> hard to believe.  It only happens (or so it seems) when I use a portable
> storage on Windows.

What gives you the idea that Windows is creating them? It is just
displaying a file which the Mac already created, but is hidden by
Finder.

> I also find it hard to believe that Finder would create a filename that
> is such a nuisance to deal with.

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).

If you don't believe me, try it yourself.

On your Mac's internal drive, create a folder called "Test" on your
desktop, then use Get Info to copy an icon from some other file (not a
standard folder icon) and paste it onto the new folder icon (click on
the icon in the Get Info window to copy/paste the icon).

Finder won't show the Icon file, but Terminal will:

ls -lO ~/Desktop/Test

total 504
-rw-r--r--@ 1 dempson  staff  hidden 0 19 Oct 08:23 Icon?

Now copy the Test folder to a USB flash drive or other portable storage
volume which is formatted in FAT or ExFAT, and look at it again in
Finder and Terminal.

ls -lO /Volumes/Lexar/Test

total 0
-rwxrwxrwx@ 1 dempson  staff  - 0 19 Oct 08:23 Icon?

I see the hidden flag is missing, but Finder still hides it (probably a
built-in rule).

Now mount that drive in a Windows system and you will see a visible file
called "Icon" followed by a character that looks like a bullet in
Explorer on Windows 7.

-- 
David Empson
dempson@actrix.gen.nz

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

#37059

In article <1mvcx27.1u41d2t4l3wmN%dempson@actrix.gen.nz>, David Empson
<dempson@actrix.gen.nz> wrote:

> 
> > I also find it hard to believe that Finder would create a filename that
> > is such a nuisance to deal with.
> 
> 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).

the invisible icon\r file first appeared twenty-five years ago with
system 7 for custom finder icons.

its name was specifically chosen because it's not possible for a user
to create a file with a \r in its name from the keyboard (the only way
is for an app to do it programmatically), which means that there could
never be a name conflict with an invisible file (which would thoroughly
confuse people), no matter how crazy of a name the user came up with.

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

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

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

csiph-web