Can a Macintosh person tell us how to change the name of a file?

In article , Wolf K
wrote:

it was*you* who made irrelevant comments about mime, specifically
network packet headers, which has absolutely nothing whatsoever to do
with file system metadata. zero.

I pointed out that data packets have metadata included as an example of
the principle of including metadata with the data file. The context was
"Should metadata be included with the file, or should it be external,
e.g., in the file system or elsewhere?"

network packets do not have metadata. period. full stop.

you've been told this by myself and several others.

Yes, I've been told that by people who for some reason don't see that
routing data functions to indicate what to do with the data packet.

then you should consider that what you've been saying is *wrong*.

Looks like for you ""metadata" is merely a label. One that's correct
only when used with some reference to "files."

wrong on that too but that's ok.

OK, just to make sure I
don't get confused in future, I'll call it "green fuzz". But then I'll
have to call some other metadata "purple spots", or "stinky cheese", (I
can't use "quark", physicists snaffled that one), depending on what
aspect or feature of a "file" it's about.

why wait for the future? you already are very confused.

Which reminds me: how do you know a file is a file? Why, because there's
metadata that tells you what kind of file it is!

no, it's because the file system has an entry in its directory tree and
therefore shows up in a file listing.

Wow! Whoda thunk it! It's metadata because it's somehow attached to a
file! And it's a file because it has metadata somehow attached to it!

That kind of circular definition is pathetic. You can do better than that.

i've already done much better than that.

Watching you squabble about metadata is mildly amusing, for a while
anyhow.

i'm not the one who is squabbling.
i'm not the one who is making ludicrous comparisons to network
protocols and claiming it's metadata.

You argued about whether it should be included in the file as in
a file header; or included with the file, as in MIME-encoded messages;
or parked somewhere in the filesystem, as in extensions; or formatted as
a database used by the file manager as in forks; or whatever. All that
argy-bargy was and is pointless without discussion of the functions of
metadata, since it's just guys whingeing about how some other ecosystem
is not like the one they're used to. Not one of you that I recall ever
gave any sign of awareness that the function of metadata is what makes
it metadata, not its structure, nor the type of data that it's about.

then you didn't read what i wrote, as expected.

as i said in another post, some metadata must be outside the file and
others within it, while some can go in either place, depending on a
number of factors.

I repeat: The function of metadata, even in the limited sense in which
you guys insist on employing the term, is to indicate what to do with
the data (file) it's linked to (in whatever way it happens to be linked,
and whatever that data happens to be).

repeating it doesn't make it correct.

That function also characterises things you refuse to call metadata
because they're "off topic". Such as the rest of the world. instead of
being gobsmacked that a concept invented to make computers function
turns out a apply to things that aren't computers. Which it does. And
which should gobsmack you because it's very rare for a specialist
concept to apply outside the specialty.

network packet headers are not metadata no matter how much you insist
that they are.

you are simply wrong.

OK, so refuse to class routing data as metadata. But to be consistent,
you'll have to find a new term for
that-which-identifies-what-operation(s)-can-be-performed-on-a
given-piece-of-data.

and that term is called a packet header, something that was established
many decades ago.

Have fun.

i always do.

In article , Wolf K
wrote:

You _mis_read context. Repeatedly. Hence your irrelevant comments
about MIME. I was addressing the topic of "Should metadata be
included in a file or stored outside it?" Some people said no, some
said that depends. I said yes, and used data packets as an example
of why metadata should be included with the data. Network data
transmission at any level requires data packets that carry metadata
with them, else they can't be assembled by the recipient computer(s)
into the file that's being transmitted.

That's transmission level stuff and has nothing to do with file
metadata. Do try to stay on-topic.


Oh, pish tosh. "Metadata" is just data that tells whoever or whatever
deals with the data what to do with it. That's all. To limit
"metadata" to one level only of its possible function violates the
logic of it meaning.

The topic is metadata to do with files. If you can't stay on topic,
then sod off.

Oh, but I do stay on topic.

no, you don't.

"Metadata to do with files" is precisely
what I've said it is: data outside of or linked to the data that
provides information relevant to deciding what to do with the data.

for *files*, not network packets.

As to what a file is, that's not as simple as it sounds.

actually, it is very simple.

For most
people, a document or an image is a file, but a program isn't. This is
of course nonsense.

true. it is nonsense.

only in the simplest case is there a 1:1 correlation.

A file is a file is a file. It's what you do with a
file that makes a program different from a document.

nope.

For that matter, I
can envision a scenario or two wherein a program is treated as a
document, ie, it won't be executed, it will be read. By a human. In
order to prove some point in litigation, for example.

no need for litigation.

any time you download an app or zip/unzip it, it's treated as a file
(or set of files for a bundle).

To put not too fine a point on it, "It's all data". Data isn't a file
until you do something with it. Which means even a network data packet
is a file, because you do something with it. If you can't do anything
with it, it's merely noise.

nonsense.

data doesn't depend on it being used, a network data packet is not a
file and noise is very different than an unused packet.

So the topic "metadata to do with files" isn't as simple as your
invitation to stay on topic implies.

actually, it is.

Therefore, I submit that referring
to data packet ID (or routing data) as metadata is on topic.

submit it all you want. it's still wrong.

If you
don't see it that way, OK, then you'll need different names for
different types of metadata, depending on what aspects or features of
the data it refers to.

the names already exist. specifically, packet *header*.

But no matter what you call it, it will be used
to decide what to do with the data.

that doesn't make something metadata.

In message Wolf K wrote:
On 2017-12-21 15:21, Lewis wrote:
In message Wolf K wrote:
On 2017-12-21 11:02, nospam wrote:
In article , Lewis
wrote:

[....]
You are, of course as everyone who has ever used a Mac know, entirely
100% wrong.

yep.

Seems to me there's some ambiguity (polite phrase) about "filename".

This is not relevant to the path separator which has always been : on
the Mac and has never ever been / as the ignoramus keeps insisting.

Interesting comment, since it includes the hidden assumption that the
pathname is not part of the identification-label of the file.

Aren't those goalposts a bit heavy?

The path is not the same as the filname. the path separator is not part
of the filename.


--
Rule #5: Get Kirsten Dunst Wet

In message Wolf K wrote:
On 2017-12-21 23:31, Lewis wrote:
In message Wolf K wrote:
On 2017-12-21 15:21, Lewis wrote:
In message Wolf K wrote:
On 2017-12-21 11:02, nospam wrote:
In article , Lewis
wrote:

[....]
You are, of course as everyone who has ever used a Mac know, entirely
100% wrong.

yep.

Seems to me there's some ambiguity (polite phrase) about "filename".

This is not relevant to the path separator which has always been : on
the Mac and has never ever been / as the ignoramus keeps insisting.

Interesting comment, since it includes the hidden assumption that the
pathname is not part of the identification-label of the file.

Aren't those goalposts a bit heavy?

Nope, ain't moving any goalposts. "Filename" refers to two things, that
which the user sees, and that which the OS sees.

It does not ever refer to the path of the file.

They are are usually
the same, but apparently on the MAC, they aren't always the same,

You have zero clue and are operating out of willful ignorance at this
point.

and / has to be "translated" to : or vice versa,

Only for the Unix layer. MacOS and HFS, as has been pointed out to you
*many* times, use ':' as the path separator. And the path separator has
*nothing* to do with the filename.

The path is not the same as the filename. the path separator is not part
of the filename.

True, I never said otherwise.

Yes, you have repeatedly said otherwise.

That's why I wrote "identification-label"
deliberately, precisely because it's not the filename. The filename is
one thing. That which enables you to find it is another,

Your lathering ignorance.

and it includes the pathname, which may have several parts. So the
separator is part of the whole thing. Has to be, or it wouldn't work.
The whole thing is the files "identification-label" (or whatever you
want to call it).

No. This is entirely wrong.

--
Lithium will no longer be available on credit

https://www.top4download.com/softwar...+converter+2.5

Just use these. You can just send the link above,
there is one on there for mac
I don't know anything about changing names of files on Macintosh!

Today I asked an emergency question on the rec.autos.tech newsgroup (the
question is below) which has an MP4 uploaded to a web style forum which
only accepts small PDFs (less than 12MB).

I easily used Windows Shotcut freeware to convert the ~50 MB MP4 video to
just ~5MB (simply by changing the pixels to 640x480) and then uploaded the
much smaller files "as a fake PDF" by changing the name from file.mp4 to
file.mp4.pdf instead.

The Windows users had no problem changing the name but all the Macintosh
users complained they can't change the name and I can't tell them HOW to
change the name. It's really important that I get these Macintosh users to
hear the file!

Can a Macintosh person tell us how to change the name of a file?
Whatever you write, I will cut and paste into the web forum thread.!

Thanks!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

================================================== ===============
Here is the original post to the rec.autos.tech newsgroup
https://groups.google.com/forum/#!forum/rec.autos.tech
================================================== ===============
https://groups.google.com/d/msg/rec.autos.tech/uicX1l6oO_U/zzAfaVfSBQAJ
Subject: Have you ever heard THIS SOUND inside your engine?
URL:http://www.bimmerfest.com/forums/showthread.php?t=1181089

Nobody on Bimmerfest knows what is causing this noise and I can't use the
car until I figure out how to figure out what the noise is.

This only started after I did some work this weekend on the valve cover but
it sounds like someone left a socket inside the engine and it's bouncing
around somewhere.

I'm pretty sure I didn't leave anything inside where this sounds like it's
in the intake manifold but it's hard to figure out where it's coming from
as it's intermittent.

It sounds like it's coming from the top of the engine somehow but it's hard
to place where.

You should not need a login to read that thread and download the videos.
http://www.bimmerfest.com/forums/attachment.php?attachmentid=730369&d=1513035084

Here's just an audio file:
http://www.bimmerfest.com/forums/attachment.php?attachmentid=730353&d=1513034666

When you download them, remove the *pdf which I added so that the MP4 would
look like a PDF to the forum upload GUI.

I can't imagine what is making that noise which is why I'm asking you for
how to debug that noise. Thanks!

In message Wolf K wrote:
So there could be two versions of the filename, same as two filenames,
one for the user, and one for the OS.

Nope. You've said this over and over and it's never been true.

If that inference is incorrect, then the talk about forbidden characters
etc is,er, ah, um, I can't think of a polite term for what to call it.

and / has to be "translated" to : or vice versa,

Only for the Unix layer.

Precisely. So my inference is correct: the OS sees something different
than the user.

No, You continue to repeat the same error. The OS is Mac OS. It sees the
file name properly. The disk MacOS is on is HFS (or APFS). It sees the
filename properly.

There is a translation, *for the Unix layer* from ':' to '/' for the
path separator to make interacting with the Unix layer simpler. The Unix
layer is *not" "The OS". The translation also includes telling the Unix
layer than any / character in a file name is a : so that the Unix layer
doesn't get confused.

Unix is not, and never has been, "the OS".

No, I haven't. I took what you guys said, and noted there was an
ambiguity in the use of "filename".

There is not. There is ambiguity only in your lack of understanding.

There was even at some a point a reference to "real filename". Are you
surprised that I inferred that there could be two filenames per file
in play?

I am not surprised that you continue to make wrong arguments about a
topic you know nothing about.

So I am to infer that, given a file-list structure that uses folders and
sub-folders, a pathname is not needed to specify a file.

A pathname is not needed to specify a file, that is correct.

What if there are two copies of a file?

What if?

And just to forestall quibbling: I know there are ways of structuring
file lists that don't involve pathnames.

Shocking! Then why do you claim a pathname is required?

--
"He has never been known to use a word that might send a reader to the
dictionary." - William Faulkner (about Ernest Hemingway).

In article , Wolf K
wrote:


You are, of course as everyone who has ever used a Mac know, entirely
100% wrong.

yep.

Seems to me there's some ambiguity (polite phrase) about "filename".

This is not relevant to the path separator which has always been : on
the Mac and has never ever been / as the ignoramus keeps insisting.

Interesting comment, since it includes the hidden assumption that the
pathname is not part of the identification-label of the file.

it isn't.

the pathname is a path to the directory in which the file is stored,
one of several ways to identify it.

If by "it" you mean the file, then you are agreeing with what I said.
Maybe "identification label" caused confusion. If so, I apologise. i
couldn't think of a more transparent phrase.

stop making up names for things that already have well established
terms and there won't be any confusion (other than your own lack of
understanding).

But it can
be, eg, when (as complained of in another NG) a picture-viewer steps
through the files in a "library" by alpha-sorted pointers, so that the
"next image" wasn't the one the user wanted. He wanted the next image in
the source folder, but its filename allowed a gap in the alpha-sorting.
It seems that the picture-viewer in question ignores the pathname, and
sorts on the filename alone. Why? I infer that the designers didn't
think of pathname as part of the file's ID.

that's because it isn't.

i don't know what the issue was in that particular thread

The picture viewer used by the OP moves to the next image in the
"library". The library consists of pointers to all the images on the
disk. The pointers are in alpha-order by filename. When two files in a
source folder are far enough apart alphabetically, then the picture
viewer may offer up an image whose filename drops between the other two.

there must be more to the story than that.

no app is going to arbitrarily decide that two files are too far apart
in whatever sort it does and then randomly choose something else to
fill in the gap.

the user did something to cause that to happen, perhaps not realizing
it, and is blaming everyone other than himself for his own ****up.

The OP wanted to see the files in particular folders. That's because the
viewer was designed to ignore the path. OP also was unaware that he
could customise the library to ensure he got what he wanted.

what he needs is a good photo asset manager so he can arrange and
organize his photos any way he wants, in whatever order or grouping he
wants, and in ways not possible with files and folders.

using the file system to organize photos, music, movies and other
assets is horribly limiting. fortunately, it's very easy to go beyond
those limitations.

typically, apps sort files by ascii order, which would put 10 before 2,
while users want it sorted in numeric order [etc]

That being said, I have no skin in this game, it's been almost a decade
since I last owned a Mac.

then you're not in a position to argue how it works and i doubt you
understood things at the lowest levels that others here do.

I didn't and don't argue how it works. I've claimed nothing about / and :.

yes you have, to both.

I merely note that there are at least two meanings of "filename" in play
here, and that identifying a file (for whatever purposes} is a
complicated business.

there aren't two meanings.

you're confused.

In article , Wolf K
wrote:

You are, of course as everyone who has ever used a Mac know, entirely
100% wrong.

yep.

Seems to me there's some ambiguity (polite phrase) about "filename".

This is not relevant to the path separator which has always been : on
the Mac and has never ever been / as the ignoramus keeps insisting.

Interesting comment, since it includes the hidden assumption that the
pathname is not part of the identification-label of the file.

Aren't those goalposts a bit heavy?

Nope, ain't moving any goalposts. "Filename" refers to two things, that
which the user sees, and that which the OS sees. They are are usually
the same, but apparently on the MAC, they aren't always the same, and /
has to be "translated" to : or vice versa,

nope. there is only one file name.

I don't really care which.

true, you don't, nor do you understand it.

Also, in ancient Windows, the filename that the OS saw was always 8:3
format, while the extended (long) filename was metadata attached to the
file somehow (I forget the details). Or maybe I'm thinking of OS/2, it's
been a long time.

also true, and irrelevant to the path separator on the mac.

But to find a file, you need more than a filename.

that was never in dispute.

The path is not the same as the filename. the path separator is not part
of the filename.

True, I never said otherwise.

actually, you did.

That's why I wrote "identification-label"
deliberately, precisely because it's not the filename.

more accurately, because you don't understand the details and are
making up terms as you go along.

The filename is
one thing. That which enables you to find it is another, and it includes
the pathname, which may have several parts. So the separator is part of
the whole thing. Has to be, or it wouldn't work. The whole thing is the
files "identification-label" (or whatever you want to call it).

path name is *one* way to access a file, but not the only way.

in fact, it's even possible to rename a file that is currently open
and/or move it (thereby changing its path), all without causing any
problem to the app that has it open.

In article , Wolf K
wrote:

and it includes the pathname, which may have several parts. So the
separator is part of the whole thing. Has to be, or it wouldn't work.
The whole thing is the files "identification-label" (or whatever you
want to call it).

No. This is entirely wrong.

So I am to infer that, given a file-list structure that uses folders and
sub-folders, a pathname is not needed to specify a file. What if there
are two copies of a file?

then there are two copies.

And just to forestall quibbling: I know there are ways of structuring
file lists that don't involve pathnames.

if that statement is to be believed, then you already know the answer.

since you asked, it must not be true.

In article , Wolf K
wrote:

A file is a file is a file. It's what you do with a
file that makes a program different from a document.
nope.

If you read a text file, it's a document. If you execute it, it's a
program. It's still all text.

nonsense.

apps are not text.
music, video and photos are not text.
lots of files are not text.

So whether a text file is a program or a document depends on what you do
with it.

wrong. very wrong.

One of the endearing quirks of Mint is that it ask you what to
do when you double click on text file.

text files are normally associated with a text editor or word processor
rather than mint, so double-clicking it would launch *that* app, not
mint.

For that matter, I
can envision a scenario or two wherein a program is treated as a
document, ie, it won't be executed, it will be read. By a human. In
order to prove some point in litigation, for example.
no need for litigation.
[...]

I didn't say "need". I said "ie", unpunctuated "i.e.", abbreviation of
"idem est", Latin for "that is". I was explaining how a program could be
treated as a document. Shoulda said "program file", I guess. Sorry about
that. And of course it would be the printout of the file. Offered in
evidence in case about, say, for example, intellectual property. In
which case it would be a document in at least two senses of the word.

Every comment you make rests on the limited, narrow meaning of
"metadata" that you insist is the only correct one. OK,in certain
context it is. Technical terminology has its necessary uses. But even
technical terminology isn't fuzz-free. "Metadata" as shown in your
examples is a Fuzzy concept, even if limited to your examples.

i've said several times that there are many types of metadata, which
makes it a wide definition, not narrow.

in other words, it's only fuzzy to those who don't understand the
concepts or the terminology.

In article , Wolf K
wrote:

Your discussion from here
on in is nicely done, and helped me clarify "included in" and "included
with". You don't state it explicitly, but metadata for system use is
rarely the same as metadata for human use.

so what? there's all sorts of metadata for all sorts of purposes, and
where it's best stored can (and does) vary, even for the same metadata,
depending on the particular task.

Seems to me that it's where
these uses intersect that there is the most uncertainty, and hence
argument about where the data should go.

the argument stems from lumping everything into one pile.

It's not a pile. It's a structure.

more semantic nonsense.

Well, in my mind it is, I don't know
about yours. It's incomplete, too, because I haven't made any attempt to
find out exactly how far the concept of metadata reaches.

you haven't made any attempt to understand much of anything.

earlier, you said metadata should be *in* the file, but there are
numerous cases where it *can't* be and others where it depends on the
goal of the software.

I've changed my mind, as noted above.

ok.

Reading it, I note that "metadata" is a much richer concept than a
cursory glance would suggest. It even includes data that you explicitly
exclude from the concept. Why, I don't see, since what you exclude
affects how the data is handled.

what exactly have i explicitly excluded?

Metadata of all types that you gave as examples is covered by "data used
to affect or determine how another chunk of data is handled by the
system, or used by a human."

That concept includes data-packet ID, since it's the ID that determines
the disposition of the data-packet (retain or discard). It's of course
possible to examine the contents of the data packet, etc, but that seems
to me irrelevant to the concept of "metadata".

One could of course dump the word, and invent several terms to refer to
the distinct functions of metadata. But it seems we're stuck with it, so
we had better be clearer about the complexity of the concept.

there's no need to invent new terms, as the existing terminology works
exceptionally well and has for a very long time.

i don't know why you continue to make up your own names for stuff, but
you do and that makes it impossible to communicate.

data packets have headers.
files have metadata.
they are not the same.

I think the concept has grown away from the techs who invented it.

you think a lot of things, few of which have any basis in reality.

Well, one of the realities is that you can't control the development of
a term's meaning(s). To you, that's a abomination: any extension or
development of term's meaning is "wrong." To me, it's an opportunity for
analysis and understanding.

nobody is trying to control the meaning of anything.

if you use the terminology as is used in the industry and has been for
many decades, then there won't be any misunderstandings.

you're certainly welcome to use terms incorrectly or make up your own
terms, but don't be surprised when communication fails.

On 2017 Dec 22, John McWilliams wrote
(in article ):

On 12/22/17 PDT 9:09 AM, Tim Streater wrote:
In , Wolf K
wrote:

nospam wrote:

the fact remains that / is valid character in a file/folder name on a
macintosh and always has been. period. anyone who claims otherwise is
simply wrong.

I wrote:
Quite so.

nospam wrote:
in other words, you agree, yet you argue.

About what? I've claimed nothing about / and : in Mac filenames.

Don't talk cock. This thread contains nothing but claims by you about /
and :

X:alt.windows7.general

Why do you keep posting into troll groups?

which troll groups would those be?

In message Wolf K wrote:
On 2017-12-23 07:01, Lewis wrote:
In message Wolf K wrote:
So there could be two versions of the filename, same as two filenames,
one for the user, and one for the OS.

Nope. You've said this over and over and it's never been true.

It was true for a while about Windows or OS/2, I forget which, but the
command line DIR gave me 8.3 filenames, while the file manager displayed
long filenames.

We are not talking about Windows. Nor are we talking about OS/2.

If that inference is incorrect, then the talk about forbidden characters
etc is,er, ah, um, I can't think of a polite term for what to call it.

and / has to be "translated" to : or vice versa,

Only for the Unix layer.

Precisely. So my inference is correct: the OS sees something different
than the user.

No, You continue to repeat the same error. The OS is Mac OS. It sees the
file name properly. The disk MacOS is on is HFS (or APFS). It sees the
filename properly.

Ah, I see, you don't include "the Unix layer" in the OS. I do.

No, you don't because you do not get to decide what macOS is.

Sorry
about that, I thought that anything other than a data file, program
file, metadata, or firmware is part of the OS.

No, that's never been true. You are showing your ignorance once again.

I'm sorry that you inferred that the I thought the Unix layer was "the
OS". It apparently didn't occur to you that I knew the the Unix layer
wasn't "the OS",

All evidence points to you not knowing this, including your statement
right above that directly contradicts this statement.

but your conviction that I am a stupid ignoramus

You have demonstrated your ignorance repeatedly. If you'd like to claim
stupidity as well, that is certainly your right and I won't argue with
you.

prevented you from reading correctly. Besides, even if you exclude the
Unix layer from the OS, the OS has to translate for the Unix layer, and
it can't do that without "seeing" both versions of
whatever-you-want-to-call-it.

No, the OS doesn't have to translate from the Unix layer because the
path delimiter and the filenames ON THE DISK are properly formatted for
macOS.

I am no longer surprised that you claim I know nothing about the topic.
You confuse labels with things.

You misuse terms and make up terms and display a fundamental lack of
knowledge. That is on you. You still fail to understand even the most
basic fact that macOS allows '/' in a filename and that macOS is not
"translating" a "real" filename to "fake" a / in a filename. You also do
not understand that there are not multiple filenames for a single file,
nor do you understand that the Unix layer is not the OS.

So I am to infer that, given a file-list structure that uses folders and
sub-folders, a pathname is not needed to specify a file.

A pathname is not needed to specify a file, that is correct.

Clearly, whatever you are labelling "specify X" is not the same as what
I'm labelling "specify X". You seem to equate it with labelling. I
equate it listing sufficient data to differentiate from any other Xs in
the current context. Why would you want to do that? So you can find it.

You do not need a pathname to find a file. There are plenty of OSes that
do not use file/folder hierarchies.

But if you have some way of finding X simply from its label, tell us. It
would be a boon in almost every endeavour. E.g., the police would love
to know how to go directly from a name to a suspect.

"label" is a meaningless word here. However, I will point out that macOS
aliases do not rely on paths at all, and you can generally move the
alias target wherever you want (that is, change its path arbitrarily)
without affecting the alias at all.

And just to forestall quibbling: I know there are ways of structuring
file lists that don't involve pathnames.

Shocking! Then why do you claim a pathname is required?

Because I thought we were talking about file lists that utilise folders.

So you are saying that a path is required to locate a file when you use
a file system that relies on paths? Well, that is somewhat right, but
only somewhat. Paths are an abstraction to make finding files easier
*for the human*, but they are not required even on a system that relies
on paths.

Or, to be more technical, that a classification system with class names.

That's not more technical, that's gibberish.

Oh, i see, you vague about who/what sues the. Sure, there are lots of
utilities that avoid the need for a human to use a pathname. But oddly
enough, when I Search for NAME on this box, it tosses up all instances
of NAME, and very helpfully includes the path as well. Why? Because it
hasn't a clue which NAME I want.

There are many ways to search, but that is no relevant at all. The path
given is to help YOU. It is more meaningful to a human than, for
example, returning the inode number.

To give you a better sense of context: From my POV, a concept that
excludes purpose or function is pointless. The purpose of a filename is
differentiate one file from another.

Not really. the purpose of a filename is to allow a human to easily
differentiate between two files. You could easily have a filesystem that
used no paths, not folders, and no filenames. In fact, such filesystems
have existed and probably exist right now.

But to specify a file, you usually need a whole lot more than just a
filename. Pathnames are usually part of the whole lot more, in which
cases, pathnames are part of specifying a file.

Circular arguments *are* circular, you are right. But your basic
assumption is entirely wrong.

--
Mickey and Mallory know the difference between right and wrong; the just
don't give a damn.

In message Wolf K wrote:
On 2017-12-23 09:10, nospam wrote:
In article , Wolf K
wrote:
[...]
Nope, ain't moving any goalposts. "Filename" refers to two things, that
which the user sees, and that which the OS sees. They are are usually
the same, but apparently on the MAC, they aren't always the same, and /
has to be "translated" to : or vice versa,

nope. there is only one file name.

Like I said, the referent of "filename" was unclear in several of the
posts.

No it was not. YOUR UNDERSTANDING was, and is, unclear. Not the same
thing at all.

You don't understand that I wasn't talking about filenames etc, I was
talking about "filename" etc.

That's an meaningless statement and you are making up "filename" as a
distinction from filename, and your made up distinction is meaningless
to anyone but you. It is exactly the same as if you decided that 'fudge'
meant 'whipped cream'.

For the last time: Way back when, there was a claim that Mac filenames
could or could not use : or / in a filename. I don't care which it was,
I was noting that the people who argued about it didn't have the same
concept for "filename". Hence my comment that there's an ambiguity about
the use of "filename".

There is no ambiguity. You keep repeating this, but it's still not
true.

You disagreed, because you're apparently one of those people who believe
that "words have meanings", which means that using a word for a
different meaning is "wrong."

Using a word for a made-up meaning that applies only to your useage is
as wrong as it is possible to be in terms of language. The purpose of
language is communication, and that requires that words mean as nearly
the same to everyone as is possible.

It's not, it's just different. Especially if the two meanings overlap.
IOW, words have uses. I was trying to clarify the uses.

No, you were trying to pervert precise technical language into some
bull**** that fit your ignorant argument so that you could claim to have
been right about the ignorantly misguided and totally wrong things you
said and continue to say.

But you weren't trying to clarify concepts, you were trying to "win" an
argument.

Hah. That is rich!

In terms of argument: Your claim that I'm confused merely supports my
claim that there's ambiguities. Because if there weren't I wouldn't have
noted that "filename" was being used for two different things.

Only by YOU.

But to find a file, you need more than a filename.

that was never in dispute.

Oh yes it was/is. Lewis claims you don't need those additional data. He
says a filename is enough to "specify" a file. The context of that claim
is "finding/locating a file."

I never said anything even slightly like that, you lying sack of ****.
You can go **** off now, ****bag.


--
"Yessir, Captain Tight Pants."

In article , Wolf K
wrote:

Nope, ain't moving any goalposts. "Filename" refers to two things, that
which the user sees, and that which the OS sees. They are are usually
the same, but apparently on the MAC, they aren't always the same, and /
has to be "translated" to : or vice versa,

nope. there is only one file name.

Like I said, the referent of "filename" was unclear in several of the
posts. It's that lack of clarity I was commenting on, not whether : and
/ were or were not path separators. Somebody here claimed that / could
be used in a Mac filename, then there was some argy-bargy about that, in
the course of which I noticed that the referent of "filename" wasn't
clear. I now know that nospam thinks it's a string of bytes (that's the
filename) attached to another string of bytes That's the file) so that
neither the OS nor the user will be confused about which string of bytes
(I mean files) is which. And fergawdssake don't start quibbling about
what "attached" means. If you want to use a different word for the
relationship between filename and file, go ahead.

stop making up terms.

Frankly, I don't care about which labels you use, as long as you are
able to understand what's intended when the label is used for a
different referent than the one you claim is the right one. What matters
first and foremost isn't the label, but the entity it refers to. People
often use different labels for the same thing, and the same label for
different things. That's why ambiguities arise, and arsing on about
whether the label is correct or not is pointless.

if you use the correct terms, then everyone will understand.

if you make up terms as you go along, which is what you've been doing,
then what you call ambiguities will arise.

more accurately, people will assume you haven't any idea what you're
talking about and are trying to fool people.

I don't really care which.

true, you don't, nor do you understand it.

You don't understand that I wasn't talking about filenames etc, I was
talking about "filename" etc.

i understand that you're incredibly confused.

Also, in ancient Windows, the filename that the OS saw was always 8:3
format, while the extended (long) filename was metadata attached to the
file somehow (I forget the details). Or maybe I'm thinking of OS/2, it's
been a long time.

also true, and irrelevant to the path separator on the mac.

For the last time: Way back when, there was a claim that Mac filenames
could or could not use : or / in a filename. I don't care which it was,
I was noting that the people who argued about it didn't have the same
concept for "filename". Hence my comment that there's an ambiguity about
the use of "filename".

there is no ambiguity about the use of filename, except to those who
don't understand the concepts.

You disagreed, because you're apparently one of those people who believe
that "words have meanings", which means that using a word for a
different meaning is "wrong." It's not, it's just different. Especially
if the two meanings overlap. IOW, words have uses. I was trying to
clarify the uses.

words have meanings, otherwise it would be impossible to communicate.

But you weren't trying to clarify concepts, you were trying to "win" an
argument.

nope. i'm correcting your endless number of errors, as have several
other people.

In terms of argument: Your claim that I'm confused merely supports my
claim that there's ambiguities. Because if there weren't I wouldn't have
noted that "filename" was being used for two different things.

there are no ambiguities to those who understand the details.

for those who don't understand, then it's quite possible that
everything is a mystery and as a result, they'll make many mistakes
trying to explain it to those who do understand, embarrassing
themselves in the process.

But to find a file, you need more than a filename.

that was never in dispute.

Oh yes it was/is. Lewis claims you don't need those additional data. He
says a filename is enough to "specify" a file. The context of that claim
is "finding/locating a file."

he said a *pathname* is not needed, and it isn't.

there are other ways to find a file, ones you appear to be entirely
unaware of.

The path is not the same as the filename. the path separator is not part
of the filename.

True, I never said otherwise.

actually, you did.

No I didn't. Someone else did. Which is why I noted that "filename" was
ambiguous.

'filename' is *not* ambiguous.

That's why I wrote "identification-label"
deliberately, precisely because it's not the filename.

more accurately, because you don't understand the details and are
making up terms as you go along.

I know perfectly well that there's a term (more than one, actually,
depending on abstraction level). I wanted a term that would a) describe
the concept instead of merely labelling it; and b) cover all abstraction
levels. You want a term that's limited to one abstraction level.

nope. i want to use well established industry standard terms.

you want to make up terms as you go along because you don't understand
what you're talking about, thinking you can fool those who do.

The filename is
one thing. That which enables you to find it is another, and it includes
the pathname, which may have several parts. So the separator is part of
the whole thing. Has to be, or it wouldn't work. The whole thing is the
files "identification-label" (or whatever you want to call it).

path name is *one* way to access a file, but not the only way.

Butteecher, I thunk we wuz talking about pathnames and filenames.

You really have a terrible habit of assuming universals where a specific
or a generalisation is intended.

in fact, it's even possible to rename a file that is currently open
and/or move it (thereby changing its path), all without causing any
problem to the app that has it open.

Nope.

nope what?

what i describe is not only possible, but standard on a mac.