tar: Pathname too long

[Robert Peirce]

Okay. I've been here before but the problem still exists and I don't
know why. Doe anybody have a suggestion to get around this problem?


Here is one of the output lines:

tar: ./Podcasts/Reason Podcast/Richard Epstein_ Why Obamacare Is
Collapsing and He's Not Voting for Trump, Hillary, _or_ Johnson.mp3:
Pathname too long

Last time everybody agreed that there is no such thing as a too long
pathname in tar itself so I thought maybe there is something in the
command line doing it. Tar is a symbolic link to bsdtar, and bsdtar is
timestamped 03/12/16.

In this line TS is a timestamp file updated after each backup. If the
problem is not in tar (bsdtar), find or exec could be causing it.

find . -type f -mnewer ../TS -exec tar -rf ~/media.t {} \;






To confirm what was expressed the last time, the following command line
works fine:

tar -rf ./junk "./Podcasts/Reason Podcast/Richard Epstein_ Why Obamacare
Is Collapsing and He's Not Voting for Trump, Hillary, _or_ Johnson.mp3"

The quotes protect the file name from the shell and are not necessary in
the script I am using. Numerous files in media.t have spaces and other
special characters.

[Robert Peirce]

On 10/5/16 10:46 AM, Robert Peirce wrote:
> Okay. I've been here before but the problem still exists and I don't
> know why. Doe anybody have a suggestion to get around this problem?
>
>
> Here is one of the output lines:
>
> tar: ./Podcasts/Reason Podcast/Richard Epstein_ Why Obamacare Is
> Collapsing and He's Not Voting for Trump, Hillary, _or_ Johnson.mp3:
> Pathname too long
>
> Last time everybody agreed that there is no such thing as a too long
> pathname in tar itself so I thought maybe there is something in the
> command line doing it. Tar is a symbolic link to bsdtar, and bsdtar is
> timestamped 03/12/16.
>
> In this line TS is a timestamp file updated after each backup. If the
> problem is not in tar (bsdtar), find or exec could be causing it.
>
> find . -type f -mnewer ../TS -exec tar -rf ~/media.t {} \;
>
>

This also works, but I have no idea why it works in this case but not in
the broader context..

find "./Podcasts/Reason Podcast/Richard Epstein_ Why Obamacare Is

Collapsing and He's Not Voting for Trump, Hillary, _or_ Johnson.mp3"

-exec tar -rf test.t {} \;

[Jolly Roger]

On 2016-10-05, Robert Peirce <b...@peirce-family.com> wrote:
> Okay. I've been here before but the problem still exists and I don't
> know why. Doe anybody have a suggestion to get around this problem?

I'm pretty sure if you rewrite your script in something other than
shell, this problem will magically vanish.

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

[Robert Peirce]

On 10/5/16 10:46 AM, Robert Peirce wrote:

> Okay. I've been here before but the problem still exists and I don't
> know why. Doe anybody have a suggestion to get around this problem?
>
>
> Here is one of the output lines:
>
> tar: ./Podcasts/Reason Podcast/Richard Epstein_ Why Obamacare Is
> Collapsing and He's Not Voting for Trump, Hillary, _or_ Johnson.mp3:
> Pathname too long
>
> Last time everybody agreed that there is no such thing as a too long
> pathname in tar itself so I thought maybe there is something in the
> command line doing it. Tar is a symbolic link to bsdtar, and bsdtar is
> timestamped 03/12/16.
>
> In this line TS is a timestamp file updated after each backup. If the
> problem is not in tar (bsdtar), find or exec could be causing it.
>
> find . -type f -mnewer ../TS -exec tar -rf ~/media.t {} \;

The problem seems to be the "-type f" argument. Without that it works.
With it it fails. Why?

With files you get the whole tree and the directories and
sub-directories get created as needed. Without -f you get a lot of
garbage I don't need. It greatly reduces available disk space, maybe
too much.

I would still like to know why this doesn't work as expected and any way
to work around it.

[Jolly Roger]

On 2016-10-05, Robert Peirce <b...@peirce-family.com> wrote:

> On 10/5/16 10:46 AM, Robert Peirce wrote:
>> Okay. I've been here before but the problem still exists and I don't
>> know why. Doe anybody have a suggestion to get around this problem?
>>
>>
>> Here is one of the output lines:
>>
>> tar: ./Podcasts/Reason Podcast/Richard Epstein_ Why Obamacare Is
>> Collapsing and He's Not Voting for Trump, Hillary, _or_ Johnson.mp3:
>> Pathname too long
>>
>> Last time everybody agreed that there is no such thing as a too long
>> pathname in tar itself so I thought maybe there is something in the
>> command line doing it. Tar is a symbolic link to bsdtar, and bsdtar is
>> timestamped 03/12/16.
>>
>> In this line TS is a timestamp file updated after each backup. If the
>> problem is not in tar (bsdtar), find or exec could be causing it.
>>
>> find . -type f -mnewer ../TS -exec tar -rf ~/media.t {} \;
>
> The problem seems to be the "-type f" argument. Without that it works.
> With it it fails. Why?

These file names are extremely long, right? Maybe the entire command
line, including that argument, is too long. What happens if you remove
the "-type f" argument, but add another of similar length, like
"-print0"? If that also fails, then you're probably dealing with a shell
command line length issue. If so, you may want to try using xargs rather
than the -exec switch.

> I would still like to know why this doesn't work as expected and any way
> to work around it.

Welcome to shell hell. Rewrite the script in something higher level like
PHP, Ruby, etc, and my bet is this issue will simply vanish into thin
air.

[Lewis]

In message <nt33o8$174k$1...@gioia.aioe.org>

Robert Peirce <b...@peirce-family.com> wrote:
> Okay. I've been here before but the problem still exists and I don't
> know why. Doe anybody have a suggestion to get around this problem?


> Here is one of the output lines:

> tar: ./Podcasts/Reason Podcast/Richard Epstein_ Why Obamacare Is
> Collapsing and He's Not Voting for Trump, Hillary, _or_ Johnson.mp3:
> Pathname too long

Try it without the ' or with it properly escaped.

--
No sense being pessimistic. It wouldn't work anyway.

[Robert Peirce]

On 10/5/16 10:46 AM, Robert Peirce wrote:

> Okay. I've been here before but the problem still exists and I don't
> know why. Doe anybody have a suggestion to get around this problem?
>
>
> Here is one of the output lines:
>
> tar: ./Podcasts/Reason Podcast/Richard Epstein_ Why Obamacare Is
> Collapsing and He's Not Voting for Trump, Hillary, _or_ Johnson.mp3:
> Pathname too long
>
> Last time everybody agreed that there is no such thing as a too long
> pathname in tar itself so I thought maybe there is something in the
> command line doing it. Tar is a symbolic link to bsdtar, and bsdtar is
> timestamped 03/12/16.
>
> In this line TS is a timestamp file updated after each backup. If the
> problem is not in tar (bsdtar), find or exec could be causing it.
>
> find . -type f -mnewer ../TS -exec tar -rf ~/media.t {} \;

Got this from Google.

This construct produces the usual error:

find ./$i -newer TS -type f -print0 | tar --null -n -rf ~/pictures.t -T -

This one doesn't except after building the correct file it ends by
deleting it contents:

find ./$i -newer TS -type f -print0 | tar --null -n -cf ~/pictures.t -T -

The only difference is the first uses -r and the second uses -c. The
second is sooooo close!

[Robert Peirce]

On 10/5/16 7:35 PM, Robert Peirce wrote:
> Got this from Google.
>
> This construct produces the usual error:
>
> find ./$i -newer TS -type f -print0 | tar --null -n -rf ~/pictures.t -T -
>
> This one doesn't except after building the correct file it ends by
> deleting it contents:
>
> find ./$i -newer TS -type f -print0 | tar --null -n -cf ~/pictures.t -T -

I was hoping somebody might be able to explain what is going on here.
The -r flag produces the file name too long error. The -c flag does not
but it deletes the file on completion.

As near as I could tell before deletion, the two files were the same.
So, is there a way to prevent -c from deleting the file?

[Jolly Roger]

On 2016-10-11, Robert Peirce <b...@peirce-family.com> wrote:
> On 10/5/16 7:35 PM, Robert Peirce wrote:
>> Got this from Google.
>>
>> This construct produces the usual error:
>>
>> find ./$i -newer TS -type f -print0 | tar --null -n -rf ~/pictures.t -T -
>>
>> This one doesn't except after building the correct file it ends by
>> deleting it contents:
>>
>> find ./$i -newer TS -type f -print0 | tar --null -n -cf ~/pictures.t -T -
>
>
> I was hoping somebody might be able to explain what is going on here.

I gave some suggestions, but you never even responded. Oh well.

[Robert Peirce]

On 10/11/16 1:15 PM, Jolly Roger wrote:
> I gave some suggestions, but you never even responded. Oh well.
>

You suggested I re-write the script in a higher level language, but I
decided I couldn't do that without recreating tar somehow and I didn't
think I could do that. So I looked for other ways of doing the job in
shell and discovered the -r and -c flags behaved other than expected. I
decided if I could figure out why that was or, better yet, how to keep
-c from deleting the file, it might solve my problem.

The weird thing is everybody says the length of the name shouldn't
matter to tar but that seems to be true in most cases but not all.

[Robert Peirce]

On 10/11/16 1:15 PM, Jolly Roger wrote:

> I gave some suggestions, but you never even responded. Oh well.
>

You also suggested using print0 and that rally did seem to get me a step
closer.

[Jolly Roger]

On 2016-10-11, Robert Peirce <b...@peirce-family.com> wrote:

> On 10/11/16 1:15 PM, Jolly Roger wrote:
>> I gave some suggestions, but you never even responded. Oh well.
>>
>
> You suggested I re-write the script in a higher level language, but I
> decided I couldn't do that without recreating tar somehow and I didn't
> think I could do that.

There's no reason you can't still use tar in a PHP/Perl/whatever script.

[Jolly Roger]

On 2016-10-11, Robert Peirce <b...@peirce-family.com> wrote:

You missed what I wrote about using xargs rather than the -exec switch.

[Robert Peirce]

On 10/11/16 3:22 PM, Jolly Roger wrote:
> You missed what I wrote about using xargs rather than the -exec switch.
>

I didn't miss it. I just recalled I had read there was some sort of
problem with xargs so I chose not to pursue it. However, I will give it
a look.

[Jolly Roger]

On 2016-10-13, Robert Peirce <b...@peirce-family.com> wrote:
> On 10/11/16 3:22 PM, Jolly Roger wrote:
>> You missed what I wrote about using xargs rather than the -exec switch.
>
> I didn't miss it. I just recalled I had read there was some sort of
> problem with xargs so I chose not to pursue it.

No idea what you are talking about, but that's no reason to avoid it.
People everywhere on many platforms use xargs all the time without
issue.

> However, I will give it a look.

You really should, since it has a decent chance of resolving your issue
for good.

[Robert Peirce]

On 10/13/16 10:13 AM, Robert Peirce wrote:
> I didn't miss it. I just recalled I had read there was some sort of
> problem with xargs so I chose not to pursue it. However, I will give it
> a look.

I know almost noting about xargs, but I tried this:

find ./iTunes -newer TS -type f -print0 |
xargs -O tar -cf ~/iTunes.t

and got the following error:

xargs: insufficient space for argument

I'm assuming the argument is the file name I am trying to tar, but maybe
not.

I also got the error with 'tar -rf.

I searched google and found this alternate approach:

xargs -O -Ifoo tar cf ~/iTunes.t foo

I also tried '{}' instead of 'foo'. Both produced the insufficient
space error.

Using -L 1 doesn't eliminate the error either.

I am stymied.

[Barry Margolin]

In article <nto8hk$151g$1...@gioia.aioe.org>,

What does

find ./iTunes -type f | awk '{print length($0), $0}' | sort -nr | head -1

print? This will find the longest filename in the folder.

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

[Robert Peirce]

On 10/13/16 11:43 AM, Barry Margolin wrote:
> find ./iTunes -type f | awk '{print length($0), $0}' | sort -nr | head -1
>
> print? This will find the longest filename in the folder.
>

I already know that. it is 161 characters. That's not the problem. It
really should work. I am going to look for a typo. I've been known to
miss-type commands in the past.

[Robert Peirce]

On 10/13/16 11:17 AM, Robert Peirce wrote:
> On 10/13/16 10:13 AM, Robert Peirce wrote:
>> I didn't miss it. I just recalled I had read there was some sort of
>> problem with xargs so I chose not to pursue it. However, I will give it
>> a look.
>
> I know almost noting about xargs, but I tried this:
>
> find ./iTunes -newer TS -type f -print0 |
> xargs -O tar -cf ~/iTunes.t

I found a typo in the script. It now works. Thanks JR.

I created two tar files using the old and new method and compared the
output. It looked good and there was no problem with file name length.

[Jolly Roger]

On 2016-10-13, Robert Peirce <b...@peirce-family.com> wrote:

Yey! Finally!

[Robert Peirce]

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.

[Barry Margolin]

In article <ntql6d$se2$1...@gioia.aioe.org>,

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.

[Robert Peirce]

Being unable to let sleeping dogs lie, I changed LIST to have iTunes
first instead of half-way down the list. Would you believe the damn
thing worked! This is way beyond my understanding.

This failed:

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

This worked:

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

[Robert Peirce]

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.

[Jolly Roger]

On 2016-10-14, Robert Peirce <b...@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...)

[Jolly Roger]

On 2016-10-14, Robert Peirce <b...@peirce-family.com> wrote:

What exactly are you trying to accomplish with this script? What's its
purpose?

[Robert Peirce]

On 10/14/16 10:55 AM, Barry Margolin wrote:

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

Interesting idea. I tested it by just running iTunes but appending to
the existing file. It worked.

[Barry Margolin]

In article <ntqsq3$19rt$1...@gioia.aioe.org>,

Robert Peirce <b...@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.

[Robert Peirce]

On 10/14/16 11:53 AM, Jolly Roger wrote:
> What exactly are you trying to accomplish with this script? What's its
> purpose?
>

I have two Drobo file systems, one in PA and one in VA. They are not
connected to one another in any way. The only common factor is the MBP
I put a tar file on to take to VA. I add to the PA system, mostly new
tunes in iTunes, when I am in PA and I build a tar file of changes,
newer than TS, to take to VA to keep the two systems synched.

The approach I am using works fine except, in the previous version, I
would occasionally get a "tar: Pathname too long" error and in the new
version, using xargs, "xargs: Pathname too long." You suggested using
xargs and that is probably why I was finally able to solve this.

The script processes a LIST of directories on my "Pictures" disk. After
much testing I finally discovered that if LIST began with iTunes the
script worked, but if iTunes was in the middle of the list it would fail
on a couple of really long file names; one was 161 characters.

It was suggested that the iTunes directory might have a problem
appending to an existing tar file, so I tested that to be sure it wasn't
the problem.

This may be a shell problem or a system problem. I don't know. I have
tried #!/bin/sh, #!/bin/ksh and #!/bin/bash and they all do it, so it
isn't one particular shell.

Putting iTunes first in the LIST solves the problem but I don't know why.

At the risk of adding a lot of extraneous junk, here is the working
script I am currently using. I have no idea why putting iTunes first in
the LIST makes it work correctly.

# pictures
# build and extract photographs, iPhone and movies

if [ ! "`ls /volumes/Pictures`" ]
then
print Pictures not mounted
exit
fi

if [ $# -ne 1 ]
then
echo "useage: pictures -b|-x|-t"
echo " -b = build"
echo " -x = extract"
echo " -t = test"
exit
fi

if [ "$1" != "-b" -a "$1" != "-x" -a "$1" != "-t" ]
then
echo "useage: pictures -b|-x|-t"
echo " -b = build"
echo " -x = extract"
echo " -t = test"
exit
fi

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

cd /Volumes/Pictures/iTunes/Mobile\ Applications
ls>AppList

cd /Volumes/Pictures/
if [ "$1" != "-x" ]
then
ls -l /volumes/Pictures/TS
printf "Is the date on /volumes/Pictures/TS set the way you want it? "
read ans
if [[ "$ans" != "Y" && "$ans" != "y" ]]
then
print Set TS and run again.
exit
fi
rm -f ~/pictures.t

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

elif [ "$1" == "-x" ]
then
if [ -f ~/pictures.t ]
then
tar xf ~/pictures.t
print pictures.t was not removed
print remove manually
else
print There is no pictures.t file
exit
fi
else
echo "useage: pictures -b|-x|-t"
echo " -b = build"
echo " -x = extract"
echo " -t = test"
exit
fi

if [ "$1" == "-b" ]
then
rm TS
I=`date -v-3m "+%y%m%d"`
touch -t ${I}2359 TS
fi

[Robert Peirce]

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.

[Robert Peirce]

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.

[Robert Peirce]

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.

[Happy.Hobo]

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.

[Happy.Hobo]

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.

[Robert Peirce]

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.

[Robert Peirce]

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.

[Richard L. Hamilton]

In article <ntrho8$c3p$1...@gioia.aioe.org>,

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)

[Happy.Hobo]

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>

[Richard L. Hamilton]

In article <nu0sa5$1kif$1...@gioia.aioe.org>,

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

[Paul Sture]

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.

[David Empson]

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
dem...@actrix.gen.nz

[Happy.Hobo]

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.

[David Empson]

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

> On 10-18-2016 02:39, David Empson wrote:
> > Paul Sture <nos...@sture.ch> wrote:
> >
> >> On 2016-10-16, Happy.Hobo <Happy...@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
dem...@actrix.gen.nz

[nospam]

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

<dem...@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.

[Happy.Hobo]

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.

[David Empson]

Happy.Hobo <Happy...@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
dem...@actrix.gen.nz

[nospam]

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

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

[Barry Margolin]

In article <191020160838412447%nos...@nospam.invalid>,

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.

[nospam]

In article <barmar-3F965A....@88-209-239-213.giganet.hu>,

Barry Margolin <bar...@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.

[Jolly Roger]

On 2016-10-19, Happy.Hobo <Happy...@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.

[Jolly Roger]

Why? If it ain't broke...

[Barry Margolin]

In article <191020161138480830%nos...@nospam.invalid>,

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'

[nospam]

In article <barmar-4511C0....@88-209-239-213.giganet.hu>,

Barry Margolin <bar...@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.

[Peter Köhlmann]

nospam babbled:

> In article <barmar-3F965A....@88-209-239-213.giganet.hu>,
> Barry Margolin <bar...@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

[nospam]

In article <nu86ir$mue$1...@dont-email.me>, Peter Köhlmann

<peter-k...@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.

[Peter Köhlmann]

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

[nospam]

In article <nu87ta$rrq$1...@dont-email.me>, Peter Köhlmann

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.

[Happy.Hobo]

On 10-19-2016 05:02, David Empson wrote:
> Happy.Hobo <Happy...@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.

[Happy.Hobo]

On 10-19-2016 10:40, Jolly Roger wrote:
> 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. ; )

_I_ created the folder on my Mac, along with several others. No one
else has been on my Mac.

[Jolly Roger]

Maybe you just forgot that you set a custom icon on the folder at some
point in the past. Or perhaps a piece of software you had installed did it.
One thing is certain: the icon file didn't create itself.

[David Empson]

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

> On 10-19-2016 05:02, David Empson wrote:
> > Happy.Hobo <Happy...@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
dem...@actrix.gen.nz

[Happy.Hobo]

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.

[Happy.Hobo]

On 10-19-2016 19:15, Jolly Roger wrote:
> Maybe you just forgot that you set a custom icon on the folder at some
> point in the past. Or perhaps a piece of software you had installed did it.
> One thing is certain: the icon file didn't create itself.

The folder doesn't have a custom icon, and it has only existed for a
couple of weeks.

[Lewis]

In message <191020161233005977%nos...@nospam.invalid>

"...^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.'

[David Empson]

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
dem...@actrix.gen.nz

[nospam]

In article <nu9fco$o0n$2...@gioia.aioe.org>, Happy.Hobo

it does if there's an icon\r file in it.

[Jolly Roger]

What does the 'ls-l' command show for the icon file itself?

[Jolly Roger]

On 2016-10-20, David Empson <dem...@actrix.gen.nz> wrote:
> Happy.Hobo <Happy...@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.

[Happy.Hobo]

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

What kind of smiley is C:\ ?

[Happy.Hobo]

On 10-20-2016 09:21, Jolly Roger wrote:
> Happy.Hobo <Happy...@Spam.Invalid> wrote:
>> On 10-19-2016 19:15, Jolly Roger wrote:
>>> Maybe you just forgot that you set a custom icon on the folder at some
>>> point in the past. Or perhaps a piece of software you had installed did it.
>>> One thing is certain: the icon file didn't create itself.
>>
>> The folder doesn't have a custom icon, and it has only existed for a
>> couple of weeks.
>
> What does the 'ls-l' command show for the icon file itself?

There are a lot of them, and most of them were given to me by a Windows
user. (At least I think I remember her using Windows.) And the one I
checked does _not_ enable the "Cut" command. But it does have a
resource fork. I picked that one because I knew I hadn't even been in
that directory yet.

Hmmm.

[Jolly Roger]

You didn't answer the question.

[Happy.Hobo]

On 10-21-2016 23:26, Jolly Roger wrote:
> Happy.Hobo <Happy...@Spam.Invalid> wrote:
>> On 10-20-2016 09:21, Jolly Roger wrote:
>>> What does the 'ls-l' command show for the icon file itself?
>>
>> There are a lot of them, and most of them were given to me by a Windows
>> user. (At least I think I remember her using Windows.) And the one I
>> checked does _not_ enable the "Cut" command. But it does have a
>> resource fork. I picked that one because I knew I hadn't even been in
>> that directory yet.
>>
>> Hmmm.
>
> You didn't answer the question.
>

I certainly did. It shows me the file does have a resource fork.

[Jolly Roger]

No, you didn't. I asked what the command shows, and you told me a small
tidbit of barely related information. What I expected was the actual
information given by the ls -l command. Anyhow, forget it. It's obvious
you don't want help with this self-made "problem", and I've got better
things to do.