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

Mayayana wrote:
"nospam" wrote

| You're saying it's otherwise on Macs?
|
| for copies done via finder (explorer equivalent), create time is
| preserved.
|

Actually it turns out there is no creation time. Starting
from your links I found explanations of Unix/Linux "mtime"
and "ctime". C stands for change, not creation. The difference
is clearly explained he

http://www.geekride.com/inode-struct...e-mtime-atime/

M is lastMod. C is last time the file data changed in the
filesystem and is usually the same as lastMod. Apple may
call it creation time but that's not even partially accurate.
It would only be creation time when the file is first created,
before it's been changed at all in terms of content,
permissions, etc.

I find this to be rather humorous, in a geeky sort of way.
Microsoft, a company deeply concerned with copyright
income and generally making money from computers,
sees files as digital objects. The object is created and has
a life. A copy is another object. (Naturally. One makes more
money from more copies of copyrighted data.) Meanwhile
the Unix people are so geeky that they find it more relevant
to store a record of activity in terms of the file system
structure on disk than to store the data in terms of human
relevance.

It's reminiscent of the way one can make tempers flare
in Linux newsgroups by merely referring to a "folder". It's
almost guaranteed to result in several fuming geeks, "at
the ends of their ropes" over being exposed to "idiots".
They'll go into long diatribes about how there are
only directories -- listings of files in the file system -- and
that there's no such thing as a folder. Of course there's no
such thing as a file, either, from that point of view. It's
all just multiple levels of abstraction of binary patterns. But
you'll tell them that only at your peril.

Who said this wasn't an existential issue?

They changed the meaning of it. Who knew? The original definition
was more of a human thing. The focus of the change, makes it
a "machine detail". I'm pretty sure when I was using my Unix
box at work, it was creation time. And the atime has also been
watered down, for performance reasons. And since all OSes
copy one another, Microsoft has the equivalent of "noatime"
so that SSDs don't take a beating.

https://en.wikipedia.org/wiki/Stat_(system_call)

"ctime originally meant creation time, however it has
since been used almost always to refer to inode change time."

https://www.bell-labs.com/usr/dmr/www/cacm.html

"time of creation, last use, and last modification"

I didn't even know the *******s had changed it. Didn't
notice on my Linux distros.

At one point in time, GNU touch was written, and it gave
users a way to adjust all three time fields. And now it
might only be doing two fields, because of this change.
The system version of touch() wasn't as powerful. The
GNU touch was intended to cause forensic havok :-)
At the time it seemed pretty funny - like a kind
of hacking tool. I think in my group, we had all
sorts of discussions about whether you could break
into a system and leave no tracks (there would always
be that pesky logout time).

Touch used to be used during software builds, to fool
Make into doing a rebuild. A kind of timestamping,
without re-writing a file. For end users, touch() was
used to create empty files (if the file doesn't exist,
touch creates a zero byte file). And on some systems you had
mkfile() - it made real files, whereas the Windows FSUTIL
makes sparse files on NTFS instead and does no significant
writes. Mkfile was great if you needed huge dummy files
that took up physical space on the hard drive. Now, you
have to fudge it with dd.exe instead.

Paul

In article , Mayayana
wrote:

| You're saying it's otherwise on Macs?
|
| for copies done via finder (explorer equivalent), create time is
| preserved.

Actually it turns out there is no creation time.

yes there most certainly is.

why is it you think you know more about macs than those who actually
use and develop for them and have been doing so for several decades?

Starting
from your links I found explanations of Unix/Linux "mtime"
and "ctime". C stands for change, not creation. The difference
is clearly explained he

http://www.geekride.com/inode-struct...e-mtime-atime/

as usual, you don't understand what you're reading.

as i said, mac os *does* have create time and has since day one. with
mac os x, that continued, even though there's unix underneath.

you snipped my link that explained it. here it is again:
https://stackoverflow.com/questions/...le-creation-da
te-in-linux/5929466#5929466
Note that if you are on Darwin (Mac OS X), the creation time is
available.

but if that's not enough (which apparently, it was not), here's
*actual* mac os source code (much of it is open source) for the
hfs/hfs+ file system:
https://opensource.apple.com/source/xnu/xnu-344/bsd/hfs/hfs_format.h
/* HFS catalog file record - 102 bytes */
struct HFSCatalogFile {
...
u_int32_t createDate; /* date and time of creation */
u_int32_t modifyDate; /* date and time of last modification */
u_int32_t backupDate; /* date and time of last backup */
...

there are also unix shell commands on mac os x to get/set create date
(which is *not* ctime):
https://www.unix.com/man-page/osx/1/SetFile/
-d date Sets the creation date, where date is a string of the
form: "mm/dd/[yy]yy
https://www.unix.com/man-page/osx/1/GetFileInfo/
-d Gets the creation date, a string of the form "mm/dd/yyyy
hh:mm:ss" in 24-hour clock format.

In article , Mayayana
wrote:

"Mayayana" wrote
| Actually it turns out there is no creation time.

The plot thickens.

the only plot is that you're wrong (again).

-----------------------

https://unix.stackexchange.com/quest...ion-date-of-fi
le

The POSIX standard only defines three distinct timestamps to be stored for
each file: the time of last data access, the time of last data modification,
and the time the file status last changed.

That said, modern Linux filesystems, such as ext4, Btrfs and JFS, do store
the file creation time (aka birth time), but use different names for the
field in question (crtime in ext4, otime in Btrfs and JFS). However,
currently Linux does not provide a kernel API for accessing the file
creation times, even on filesystems supporting them.
--------------------------

yep, but not relevant to macs, which don't use ext4, btrfs or jfs.

So there's more recently been created a creation time,
or birth time (crtime), which is apparently not standardized
at this point in the sense that there's no API access.

it can be accessed, but again, linux != mac os x.

But it is stored, and Macs apparently deal with it, so that
any notably enthusiastic software on a Mac might dig it
up.

that part is completely wrong.

"Paul" wrote

| They changed the meaning of it. Who knew?
.....
| "ctime originally meant creation time, however it has
| since been used almost always to refer to inode change time."
|
| https://www.bell-labs.com/usr/dmr/www/cacm.html
|
| "time of creation, last use, and last modification"
|
| I didn't even know the *******s had changed it. Didn't
| notice on my Linux distros.
|

Complicated, isn't it? When I looked into this I
found that most links were pointing to someone
saying, "Ctime is changed time. There is no
creation time". When I searched for crtime on
duckduckgo it tried to tell me that I really wanted
ctime.
If ctime was once creation time that must have
been a long time ago.

Then it turns out that some systems now have
crtime as a 4th property, which seems to be a mimic
of Windows creation time, yet they never bothered
to update the API to access it. So why have it?

It seems part of the confusion was because
both *Nix and Win traditionally had 3 properties,
so a lot of energy was expended either 1) mistakenly
equating ctime with creation time (especially since
change time is so pointless) or 2) clarifying the
misconception.

But that seems to explain the anomalous behavior
on Macs: Some software takes the trouble to dig
into the file system for actual creation time. Some
just reports change time. That would also explain
how a copy of a file -- which itself would be a
separate object with its own file system listings
and thus its own "birth" -- might possibly start life
with the same ctime.

And to think all of this started with someone
who just wanted to open a file.

In article , Mayayana
wrote:


Complicated, isn't it?

not really.

In message Char Jackson wrote:
On Fri, 15 Dec 2017 08:47:47 -0000 (UTC), Lewis
wrote:

In message Char Jackson wrote:
On Thu, 14 Dec 2017 17:24:34 -0000 (UTC), Lewis
wrote:

In message Paul wrote:
Wolf K wrote:
On 2017-12-14 00:24, Your Name wrote:
On 2017-12-14 03:16:11 +0000, Wolf K said:

On 2017-12-13 19:37, Your Name wrote:
[...]
... you can't rely on the OS to do that since a JPEG image file can
actually be opened in a text editor as the file's data, even if it's
rarely useful to do so.

That's what Open With is for.

Open With is near useless if you don't know what the file actually is.
You'd have to Open With with every app you have until you found one
that could open it properly.

If we're talking about user convenience, I agree, showing a file's type
as part of the filename is very useful. (But IMO a three-letter
extension is too limited). There are many other useful conventions, eg,
in icon design. These are converging on a common standard.

If we're talking about choosing a program to open a file, extenions
aren't needed. It would be easy to ensure that Open With offers only
programs that can open a given file without reference to an extension.
Just standardise metadata (eg, as a series of slots, some which must be
filled, others for dev or user options). Easy peasy.

Have a good day,


Windows is not limited to 8.3.

Might not be in Windows 10 (though I think it is)

Nope. I can't remember what happened before XP, but at least with XP
through 10 you can create a filename with 200+ characters in the
extension, as long as you don't exceed the total number of characters
allowed.

Please reread what I said, that file will have an 8.3 representation in
the filesystem. This was true in XP and in Windows 7 and in Windows 8
(Hmm. now I'm not positive about Windows 8).

Let's try again. Windows filenames are not limited to 8.3.

Not in Win 10, not in 8.x, not in 7, not in Vista, not in XP. I'll stop
there because I don't personally remember when Long Filename (LFN)
support was introduced, but it was somewhere before that, possibly in
Win 95.

You are absolutely wrong.

If you think that Windows filenames *are* limited to 8.3, then you're
probably confusing 'long' filenames with 'short' filenames.

Windows supporst long filenames, but those files are still represented
in parts of the OS by an 8.3 name. You can see this by launching and
older DOS shell and looking at the directories. Windows also supports
mnay characters in file names that are not supported by MS-DOS or SMB,
but suing those characters causes all sorts of problems since they havew
never updated their APIs to intelligently handle these characters and
have never updated SMB because of their requirement to remain compatible
with Windows 3.

Also, of course, Windows long filenames are extremely limited, because
the overall length of the path is restricted. So it is quite possible to
be unable to copy a file from c:\ to
c:\long\path\name\12345678\12345678\12345678\12345 678\12345678\ because
the maximum path length is exceeded.

I'm not confusing them at all, I am pointing out taht both still exist,
and that the 8.3 name is required.

No. See above.

What is above is simply you spouting misinformation.

--
I leave symbols to the symbol-minded - George Carlin

In message Tim Streater wrote:
In article , Mayayana
wrote:

"Lewis" wrote

| And there are many ways (countless ways) to send attachments. Many of
| them are entirely transparent to the user, so without digging they may
| have no idea how they are sent or what metadata is preserved.

You seem to just make things up on the spot. There
are not "many" ways to send attachments in email.
There's a format. All attachments are base64 encoded.

No they aren't. Plain ASCII text and quoted-printable are also
possible, and the sender has to declare which it is using the
content-transfer-encoding: header, so that the receiver knows how to
decode it.

We used to use binhex, AScii85, Base16, Base32, boo, and yEnc is quite
popular on USENET now, just as some examples of other possibilities for
attachment encoding.

Why don't you look up the relevant RFCs which describe all this? Such
as:

a) RFC 5034 POP3
b) RFC 2821 SMTP
c) RFC 5322 Internet Message Format
d) RFC 2045, 2046, 2047, 2048, 2049 and 2557 (MIME), 2183, and 2231

Because s/he doesn't care about knowing anything, just wants to spout
ignorant bull****.

--
How soon after the USPS issues the Calvin stamp will you send a letter with one
on the envelope? Watterson: Immediately. I'm going to get in my horse and
buggy and snail-mail a check for my newspaper subscription.

In message Mayayana wrote:

"Tim Streater" wrote

| You seem to just make things up on the spot. There
| are not "many" ways to send attachments in email.
| There's a format. All attachments are base64 encoded.
|
| No they aren't. Plain ASCII text and quoted-printable are also
| possible, and the sender has to declare which it is using the
| content-transfer-encoding: header, so that the receiver knows how to
| decode it.
|
I'm not sure all this nitpicking is getting
anywhere. There seems to be a lot of difference
in how terms are used. You call metadata any
info about a file. That's not technically wrong,

OK up to here.

but usually when people are talking about
metadata they're talking about data embedded
in the file header, such a author of a JPG or artist
for a music file.

No. Totally wrong. Entirely wrong. Wrongity wrong wrong.

--
The Drum jealously guarded its reputation as the most stylishly
disreputable tavern in Ankh-Morpork and the big troll that now guarded
the door carefully vetted customers for suitability in the way of black
cloaks, glowing eyes, magic swords and so forth. Rincewind never found
out what he did to the failures. Perhaps he ate them. --Sourcery

In message J. P. Gilliver (John) wrote:
In message , Char Jackson
writes:
On Thu, 14 Dec 2017 17:24:34 -0000 (UTC), Lewis
wrote:

In message Paul wrote:
[]
Windows is not limited to 8.3.

Might not be in Windows 10 (though I think it is)

Nope. I can't remember what happened before XP, but at least with XP
through 10 you can create a filename with 200+ characters in the
extension, as long as you don't exceed the total number of characters
allowed.

Long filenames came in with '95, I think.

C:\ONGRATLS.W95

And for the computer. Yes, the 8.3 name _is_ used internally for some
functions. But for the part of the computer that uses the extension to
decide what sort of file it is (e. g. what to open it with), it looks up
the long name. (Strictly it isn't just "long" versus "short"; odd
characters that aren't allowed in 8.3, or a long extension even if the
total is less than 11 - such as a.bcde - is a "long" or at least encoded
name.)

Yes.

--
Psychic convention cancelled due to unforeseen problems.

In message Mayayana wrote:
"nospam" wrote

| You're saying it's otherwise on Macs?
|
| for copies done via finder (explorer equivalent), create time is
| preserved.

Actually it turns out there is no creation time.

You are, as always, wrong. Also, your reading comprehension sucks (as
in, is non-existent).

--
Everybody hates a tourist, especially one who thinks it's all such
laugh. Yeah, and the chip stains and grease will come out in the bath.
You will never understand how it feels to live your life with no meaning
or control, and with nowhere left to go. You are amazed that the exist,
and they burn so bright whilst you can only wonder why.

In article , Wolf K
wrote:

the only plot is that you're wrong (again).
[...]

You jut love saying that, doncha.

when someone is wrong, yes.

as usual, you snipped the entire context and have nothing better to do
than attack.

Alan Baker wrote:

On 2017-12-14 4:31 PM, Your Name wrote:
Many people confuse the Finder's information as being part of the
resource fork, but they are different. The Finder's information is not
stored inside the file at all.

Would you care to explain, then, how the Finder knows what information
to apply to which file?

The Finder Information (including type and creator) is part of the
file's directory entry in the Catalog Tree on HFS/HFS+ volumes,
alongside other fields like the pointers to the data and resource forks,
creation date, modification date, etc.

Here is an example from the HFS+ technical note (have a hunt around the
net for "Technical Note TN1150 HFS Plus Volume Format" as Apple removed
it from publication a while ago - I kept a copy).

For a normal file:

struct HFSPlusCatalogFile {
SInt16 recordType;
UInt16 flags;
UInt32 reserved1;
HFSCatalogNodeID fileID;
UInt32 createDate;
UInt32 contentModDate;
UInt32 attributeModDate;
UInt32 accessDate;
UInt32 backupDate;
HFSPlusBSDInfo permissions;
FileInfo userInfo;
ExtendedFileInfo finderInfo;
UInt32 textEncoding;
UInt32 reserved2;
HFSPlusForkData dataFork;
HFSPlusForkData resourceFork;
};

(The filename is stored elsewhere.)

The "Finder Information" traditionally (e.g. HFS) is actually two 16
byte records. HFS+ calls them "File Information" and "Extended File
Information":

struct FileInfo {
OSType fileType; /* The type of the file */
OSType fileCreator; /* The file's creator */
UInt16 finderFlags;
Point location; /* File's location in the folder. */
UInt16 reservedField;
};

struct ExtendedFileInfo {
SInt16 reserved1[4];
UInt16 extendedFinderFlags;
SInt16 reserved2;
SInt32 putAwayFolderID;
};

As can be seen from the HFSPlusCatalogFile structure, the Finder
information, data fork and resource fork are three separate structures
associated with a file: the Finder Information is fixed size while the
data and resource fork are structurally identcal at the file system
level.

For reference, here is the HFSPlusForkData for HFS+ (which is
significantly changed from HFS - see below):

struct HFSPlusForkData {
UInt64 logicalSize;
UInt32 clumpSize;
UInt32 totalBlocks;
HFSPlusExtentRecord extents;
};

typedef HFSPlusExtentDescriptor HFSPlusExtentRecord[8];

struct HFSPlusExtentDescriptor {
UInt32 startBlock;
UInt32 blockCount;
};



For comparison, here is the corresponding structure for a file in HFS
(from Inside Macintosh, extracted from a Pascal record definition):

cdrFilRec: {file record}
filFlags: SignedByte; {file flags}
filTyp: SignedByte; {file type}
filUsrWds: FInfo; {Finder information}
filFlNum: LongInt; {file ID}
filStBlk: Integer; {first alloc. blk. of data fork}
filLgLen: LongInt; {logical EOF of data fork}
filPyLen: LongInt; {physical EOF of data fork}
filRStBlk: Integer; {first alloc. blk. of resource fork}
filRLgLen: LongInt; {logical EOF of resource fork}
filRPyLen: LongInt; {physical EOF of resource fork}
filCrDat: LongInt; {date and time of creation}
filMdDat: LongInt; {date and time of last modification}
filBkDat: LongInt; {date and time of last backup}
filFndrInfo: FXInfo; {additional Finder information}
filClpSize: Integer; {file clump size}
filExtRec: ExtDataRec; {first data fork extent record}
filRExtRec: ExtDataRec; {first resource fork extent record}
filResrv: LongInt); {reserved}

The Finder and Extended Finder Information records:

TYPE FInfo =
RECORD
fdType: OSType; {file type}
fdCreator: OSType; {file creator}
fdFlags: Integer; {Finder flags}
fdLocation: Point; {file's location in window}
fdFldr: Integer; {directory that contains file}
END;

TYPE FXInfo =
RECORD
fdIconID: Integer; {icon ID}
fdUnused: ARRAY[1..3] OF Integer;
{unused but reserved 6 bytes}
fdScript: SignedByte; {script flag and code}
fdXFlags: SignedByte; {reserved}
fdComment: Integer; {comment ID}
fdPutAway: LongInt; {home directory ID}
END;


I'd have to dig into even older references to find the MFS equivalent,
but I expect it had the first 16-byte Finder Information record without
the second 16-byte Extended Finder Information, given how HFS broke them
up into two records, and different APIs were used to access them.


When Mac files are stored on foreign file systems, the Mac-specific
infomration needs to be retained. Mac OS X does this by storing the data
fork as the "normally named" file, and everything else goes into an
auxiliary file named with a period and underscore as a prefix, e.g.

example.jpg
.._example.jpg

This is an implementation of the AppleDouble standard. The second file
is structured to contain multiple records. It includes whichever
additional structures from the file need to be stored: exactly which
ones are present depends on their state in the orignal file.

If all the additional structures are empty or have default values, then
the "period underscore" file does not need to be created.

The presence of the "period underscore" file does NOT necessarily mean
the file has a resource fork - that is just one of the structures which
might be in the file. It could have non-default Finder Information (such
as a file type and creator) and nothing else.

Other data which goes in the "period underscore" file include additional
named forks beyond the data and resource forks (only a concept on HFS+),
such as extended attributes.


For further completeness:

Mac OS 9 and earlier used a similar AppleDouble structure to store Mac
files on foreign file systems, but they are arranged differently. Apple
chose to create a hidden directory called (misleadingly) RESOURCE.FRK
alongside the data fork file, and put the auxiliary file in there, with
the same name as the data fork file. As with Mac OS X, the file in the
RESOURCE.FRK directory _may_ include a resource fork, but it also
includes the Finder Informaiton.

This is probably where the false impression arose that the Finder
information was in the resource fork. It is actually separate, but
stored in the same file as the resource fork on a non-Mac file system.

For even further completeness:

The name "AppleDouble" refers to the fact that the Apple file has been
split into two files for storage on a non-native file system (or for
transmission via a file transfer protocol). There is also an
"AppleSingle" format which combines the data fork and the other parts
into a single file, which can then be transferred via a foreign file
system or file transfer protocol and preserve all the Apple-native
content. I recall using AppleSingle format back when I was using the
Apple IIgs.

Other Mac-specific file encoding techniques were similar in concept to
AppleSingle, e.g. BinHex (which also did binary-to-ASCII encoding) and
MacBinary.

For even further further completeness:

Apple has two standards for the format of the data inside the resource
fork. The Macintosh and Apple IIgs have considerable differences in how
the data is structured, even in how individual resources are identified
(Mac: 4-char type stored as a 32-bit integer, 16-bit signed identifier;
IIgs: 16-bit unsigned type, 32-bit unsigned identifier).

--
David Empson

In article , David
Empson wrote:

For further completeness:

Mac OS 9 and earlier used a similar AppleDouble structure to store Mac
files on foreign file systems, but they are arranged differently. Apple
chose to create a hidden directory called (misleadingly) RESOURCE.FRK
alongside the data fork file, and put the auxiliary file in there, with
the same name as the data fork file. As with Mac OS X, the file in the
RESOURCE.FRK directory _may_ include a resource fork, but it also
includes the Finder Informaiton.

This is probably where the false impression arose that the Finder
information was in the resource fork. It is actually separate, but
stored in the same file as the resource fork on a non-Mac file system.

the false impression of finder info being part of the resource fork
goes back to well before mac os 9.

On Sat, 16 Dec 2017 19:49:16 -0000 (UTC), Lewis
wrote:

In message Char Jackson wrote:
On Fri, 15 Dec 2017 08:47:47 -0000 (UTC), Lewis
wrote:

In message Char Jackson wrote:
On Thu, 14 Dec 2017 17:24:34 -0000 (UTC), Lewis
wrote:

In message Paul wrote:
Wolf K wrote:
On 2017-12-14 00:24, Your Name wrote:
On 2017-12-14 03:16:11 +0000, Wolf K said:

On 2017-12-13 19:37, Your Name wrote:
[...]
... you can't rely on the OS to do that since a JPEG image file can
actually be opened in a text editor as the file's data, even if it's
rarely useful to do so.

That's what Open With is for.

Open With is near useless if you don't know what the file actually is.
You'd have to Open With with every app you have until you found one
that could open it properly.

If we're talking about user convenience, I agree, showing a file's type
as part of the filename is very useful. (But IMO a three-letter
extension is too limited). There are many other useful conventions, eg,
in icon design. These are converging on a common standard.

If we're talking about choosing a program to open a file, extenions
aren't needed. It would be easy to ensure that Open With offers only
programs that can open a given file without reference to an extension.
Just standardise metadata (eg, as a series of slots, some which must be
filled, others for dev or user options). Easy peasy.

Have a good day,


Windows is not limited to 8.3.

Might not be in Windows 10 (though I think it is)

Nope. I can't remember what happened before XP, but at least with XP
through 10 you can create a filename with 200+ characters in the
extension, as long as you don't exceed the total number of characters
allowed.

Please reread what I said, that file will have an 8.3 representation in
the filesystem. This was true in XP and in Windows 7 and in Windows 8
(Hmm. now I'm not positive about Windows 8).

Let's try again. Windows filenames are not limited to 8.3.

Not in Win 10, not in 8.x, not in 7, not in Vista, not in XP. I'll stop
there because I don't personally remember when Long Filename (LFN)
support was introduced, but it was somewhere before that, possibly in
Win 95.

You are absolutely wrong.

OK, let's try a third time. It's clear that you're responding without
reading, or at least without understanding, so I'll keep it simple.

Windows filenames are not limited to 8.3.


--

Char Jackson

In article , Wolf K
wrote:

the only plot is that you're wrong (again).
[...]

You jut love saying that, doncha.

when someone is wrong, yes.

as usual, you snipped the entire context and have nothing better to do
than attack.

You don't read context,

yes i do, and unlike you, i stay on topic.

so what's your point?

that you can't refute anything i said, which is why you resort to ad
hominem attacks.