A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows 7 » Windows 7 Forum
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

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



 
 
Thread Tools Rate Thread Display Modes
  #136  
Old December 17th 17, 01:48 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
David Empson
external usenet poster
 
Posts: 10
Default Can a Macintosh person tell us how to change the name of a file?

nospam wrote:

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.


Which part of "Mac OS 9 and earlier" did you not read?

I know that the the RESOURCE.FRK folder on foreign file systems dates at
least as far back as System 7.5 (1994), but as I didn't use Macs
regularly prior to that I don't have direct experience of when it was
introduced.

The Apple II technical notes documenting AppleSingle and AppleDouble
(which include Macintosh details) were written in March 1989 and last
updated in 1991 and 1990 respectively. The AppleDouble one doesn't
specify where the AppleDouble Header File (the non-data file) is
supposed to go (it suggests searching for the file or asking the user)
so the RESOURCE.FRK standard certainly wasn't established by 1990.

PC Exchange is likely to be the origin of the RESOURCE.FRK folder.
Wikipedia says it was introduced as a separate product in 1992, included
in System 7 Pro in 1993 and was part of the main system from System 7.5
in 1994.

Does anyone happen to know whether Apple File Exchange used the same
convention?

(I don't have my antique Mac developer documentation handy, nor do I
care enough to waste time digging through it looking for the details.)

--
David Empson

Ads
  #137  
Old December 17th 17, 02:08 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
nospam
external usenet poster
 
Posts: 2,185
Default Can a Macintosh person tell us how to change the name of a file?

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.


You _mis_read context. Repeatedly. Hence your irrelevant comments about
MIME.


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 was addressing the topic of "Should metadata be included in a
file or stored outside it?" Some people said no, some said that depends.


both are valid, but for different types of metadata.

I said yes, and used data packets as an example of why metadata should
be included with the data.


not only a bad example, but completely irrelevant.

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. You can disagree with my stance, but misreading the purpose
of my example won't get you to a good argument (and there are some).


i didn't misread anything. the non-payload portion of a data packet is
*not* called metadata. you are wrong.

I also recall you participating in a technical argy-bargy about data
forks and resource forks, all of which added up to precisely nothing
until Dave Empson's post that gave examples-of. It is very instructive,
and I've saved it for further study.


then you didn't read what i wrote. his post is very complete, while
mine were brief descriptions and also to correct mistakes 'yourname'
made.
  #138  
Old December 17th 17, 02:41 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Char Jackson
external usenet poster
 
Posts: 9,574
Default Can a Macintosh person tell us how to change the name of a file?

On Sat, 16 Dec 2017 19:23:52 -0500, Wolf K wrote:

On 2017-12-16 17:59, Char Jackson wrote:
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.


There was a time when the "real" filename was 8.3, and the long file
name was metadata. Win 3.x? 9.x? MSDOS 6.x? Can't recall, but it could
cause messes. Seems like Lewis is harking back to those times.


I don't know because it seems like he hits his Reply button before he
finishes reading the first sentence. The biggest problem, IMHO, is that
this thread is crossposted to a couple of *.mac groups, and those guys
tend to speak their own language.

--

Char Jackson
  #139  
Old December 17th 17, 05:50 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Lewis
external usenet poster
 
Posts: 363
Default Can a Macintosh person tell us how to change the name of a file?

In message Wolf K wrote:
On 2017-12-16 19:36, nospam wrote:
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.


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.


Packet routing information is not metadata since it has nothing to do
with the data contained in the packet. I ti snot data about the data, it
is data about the packet.

Network data transmission at any level
requires data packets that carry metadata with them


No, they require data about the packet.

else they can't be assembled by the recipient computer(s)


that's still data about the packet.

into the file that's being transmitted. You can disagree with my
stance, but misreading the purpose of my example won't get you to a
good argument (and there are some).


Your example is poor since metadata doesn't apply to any part of your
example. It's a bit like using an elm tree as an example of a fruit.

until Dave Empson's post that gave examples-of. It is very instructive,
and I've saved it for further study.


Dave only had to post that because you and others kept arguing about
something you knew nothing about.

--
One of the most basic rules of survival on any planet is never to upset
someone wearing black leather. --The Last Continent
  #140  
Old December 17th 17, 12:01 PM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Paul[_32_]
external usenet poster
 
Posts: 7,567
Default Can a Macintosh person tell us how to change the name of a file?

Tim Streater wrote:
In article , Char Jackson
wrote:

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.


So you're saying that ifI get a vanilla Windows system, one that no one
has dorked with, I can use long filenames with any and all software
that the system comes with. That sum it up?


Absolutists really crack me up.

There's 20 years of code in there, backward compatibility,
and an application can do anything it wants.

If I have an application from 1990, it may be hard-wired to 8.3
and fixed in its ways. And still be able to run on a modern OS.

To create this "exceptional" condition, install a 32-bit version
of Windows, then go searching through your old PC for
some 16-bit applications to test. Then, you should be
able to find some program that absolutely refuses
to use anything other than 8.3.

This is the problem with "bar bet" computer topics. It takes
a *lot* of analysis, to say what capabilities something
actually has.

Apple used to get caught on this too. As a Mac user, on a
number of occasions, they're release a Technical Note, where
it would be stated "System 7.5.3 supports 40 quadrillion byte
disk drives", even though such things didn't exist yet and
they couldn't physically have tested and verified it. Well,
the developer who wrote that gem, would look at one layer
in the code and say "yep, look how wide that data structure
is, 40 quadrillion will just fit". Yet, ignore some other
code path that "pinched" the limit. Three months later, they
would issue a retraction, with some lower limit stated. This
isn't stuff detected by testing large drives, it's anecdotes
circulating from people who know some other layers really well,
and can spot structures that are a limiting factor.

I ran into an example today. I had the Mac G4 fired up, and
it's running 10.2.x . I was saying to myself "I'm sure I've
had absolutely huge multi-gigabyte files on this thing". I
don't doubt the file system handles huge files. But, the
machine has a Classic VM as part of the package, and both
Compact Pro and Stuffit are Classic. When I needed to compress
some files, as part of cleanup on the G4, I noticed right away
in the Compact Pro menu, that a large file had a "negative"
file size listed. And based on experience, I said to myself
"uh, oh, a 2GB limit, signed 32 bit number, yikes". And I decided
to try compressing the file anyway, and I was greeted by an
appropriate error after about 10 minutes. So when dealing
with the Classic path through my OS, there are actually
other limitations.

If there was some way that "old" piece of code could have
interfaces to the "new" details of the file system, it
might indeed have been able to handle a 10GB file. And
sometimes, it's only by testing you discover the
"smallest piece of plumbing" in some software stack.

So to answer your question, for any reasonably modern
executable, which actually uses LFN APIs and uses data structures
big enough to handle modern path limits, "yes, it supports long
file names". If I install Win10 x32, which support 16-bit
executables, I'm sure I can find a crusty 16-bit executable
somewhere which has internal data structures only suited for
8.3.

Windows has *extensive* legacy support. This is why we can
have ClassicShell in Win8 and Win10, where the authors have
to write hardly any of their own menu code. The menus for
the older OSes are *still* in the modern OS. In Windows 10,
Microsoft released the OS without migrating all the dialogs,
so some of the dialogs *still* had a WinXP appearance to them.
How could they do this ? By not ripping out the old code.

When it comes to making absolutist statements then, due
consideration must be given to that huge pile of slime
trailing behind the OS.

If you installed a x64 version of the OS, *then* a lot of
pesky test cases will no longer run on the OS. Then
Char's statement is "correct", for that limited circumstance,
because a lot of legacy programs won't run in the x64 version.
The x64 OS only supports 64 bit and 32 bit executables.
And 32 bit executables with 16 bit installers, can't be
installed (because the installer bombs, not the program itself).

There are other nuances to file naming that haven't come up yet.
I can write programs with 8 bit character usage for file names,
or I can use the API for 16 bit (wide) characters. If I choose
to use the latter, I can have ç or è or é in a file name, and
not be limited to "English" c and e. For the little programs
I write, both options are available in the C library if I
want them. So if Tim asks the question, "can I use è in Windows 7",
then the answer would be "Yes you can, but not with that
poor program Paul wrote, where he used the wrong (8bit) API".
The OS allows a lot of stuff... that poor utility writing can
defeat the best of ideas.

Can I use é in 8.3 ? Probably not :-) They "hadn't invented
foreigners yet", when they did 8.3 :-)

Paul
  #141  
Old December 17th 17, 08:50 PM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Peter Köhlmann[_3_]
external usenet poster
 
Posts: 226
Default Can a Macintosh person tell us how to change the name of a file?

Tim Streater wrote:

In article , Paul
wrote:

Tim Streater wrote:
In article , Char Jackson
wrote:


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.

So you're saying that ifI get a vanilla Windows system, one that no one
has dorked with, I can use long filenames with any and all software
that the system comes with. That sum it up?


Absolutists really crack me up.


All cracked up are you. Good, we'll get the road sweepers to come along
and take you to landfill.

There's 20 years of code in there, backward compatibility,
and an application can do anything it wants.

If I have an application from 1990, it may be hard-wired to 8.3
and fixed in its ways. And still be able to run on a modern OS.

To create this "exceptional" condition, install a 32-bit version
of Windows, then go searching through your old PC for
some 16-bit applications to test. Then, you should be
able to find some program that absolutely refuses
to use anything other than 8.3.


What part of "VANILLA Windows system that NO ONE HAS DORKED WITH, I can
use long filenames with ANY AND ALL SOFTWARE that the system COMES
WITH" was too hard for you to understand?


Well, glad to hear that Minesweeper and other assorted useless crap will be
able to use long filenames.
After all, windows comes out of the box with basically no software
  #142  
Old December 17th 17, 08:51 PM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Paul[_32_]
external usenet poster
 
Posts: 7,567
Default Can a Macintosh person tell us how to change the name of a file?

Tim Streater wrote:


What part of "VANILLA Windows system that NO ONE HAS DORKED WITH, I can
use long filenames with ANY AND ALL SOFTWARE that the system COMES
WITH" was too hard for you to understand?


The "system" supports it. Good luck with the rest.

Paul
  #143  
Old December 17th 17, 09:34 PM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Mayayana
external usenet poster
 
Posts: 4,900
Default Can a Macintosh person tell us how to change the name of a file?

"Paul" wrote

| What part of ....was too hard for you to understand?
|
| The "system" supports it. Good luck with the rest.
|

I guess that'll teach you. Like the man said:

Cast not your sense before ill-bred egoists, lest
they trample it under hysteria in logic's clothing,
THEN turn on you, unleashing all manner of derisive
blasphemy, such as "WHAT PART OF YOUR GRANDMA
WEARS ARMY BOOTS DIDN'T YOU UNDERSTAND?!"
or "NO SUH, YOU ARE!"


  #144  
Old December 17th 17, 10:40 PM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Alan Baker
external usenet poster
 
Posts: 111
Default Can a Macintosh person tell us how to change the name of a file?

On 2017-12-16 2:24 PM, David Empson wrote:
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).


They might not make it easy to find, but:

https://developer.apple.com/legacy/library/technotes/tn/tn1150.html


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;


Interesting. Thanks!


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.


Makes sense.


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


  #145  
Old December 18th 17, 10:52 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
Peter Köhlmann[_3_]
external usenet poster
 
Posts: 226
Default Can a Macintosh person tell us how to change the name of a file?

Tim Streater wrote:

In article , Peter Köhlmann
wrote:

Tim Streater wrote:

In article , Paul
wrote:

Tim Streater wrote:
In article , Char Jackson
wrote:

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.

So you're saying that ifI get a vanilla Windows system, one that no
one has dorked with, I can use long filenames with any and all
software that the system comes with. That sum it up?


Absolutists really crack me up.

All cracked up are you. Good, we'll get the road sweepers to come along
and take you to landfill.

There's 20 years of code in there, backward compatibility,
and an application can do anything it wants.

If I have an application from 1990, it may be hard-wired to 8.3
and fixed in its ways. And still be able to run on a modern OS.

To create this "exceptional" condition, install a 32-bit version
of Windows, then go searching through your old PC for
some 16-bit applications to test. Then, you should be
able to find some program that absolutely refuses
to use anything other than 8.3.

What part of "VANILLA Windows system that NO ONE HAS DORKED WITH, I can
use long filenames with ANY AND ALL SOFTWARE that the system COMES
WITH" was too hard for you to understand?


Well, glad to hear that Minesweeper and other assorted useless crap will
be able to use long filenames.
After all, windows comes out of the box with basically no software


Ah, just the bare metal you mean? No drivers, no filesystem, no kernel,
eh? No command line utilities? Etc, etc.


Idiot
  #146  
Old December 19th 17, 12:58 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
nospam
external usenet poster
 
Posts: 2,185
Default 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.

Quoting myself:


and further embarrassing yourself.

"The internet works because the necessary data for routing the data
packets are inside the data packet, not external. That principle should
apply to all forms of data. Including programs, but that's a another
issue. "

There's nothing about MIME in there. Zip. Zero.


exactly the point.

network packets have *nothing* to do with mime or metadata. zip. zero.

It was you who thought I
was talking about MIME.


nope.

i knew that you *couldn't* have been talking about mime because network
packets and mime are two totally different and unrelated things.

the fact you continue to insist they're somehow related shows just how
little you understand about the topic, something which you *continue*
to do despite several people telling you that you're completely wrong.

I guess you a) ignored "routing"; and b) didn't get the referent of
"that principle". Too bad.


of course i ignored 'routing' because network routing is not relevant
to mime or file system metadata.

I'll spell it out for you: "The principle of
including file-type (and other) metadata with the file instead of
storing it elsewhere." (The "storing it elsewhere" part led to the
argy-bargy about how Apple did/does it with "forks". Instead of with
spoons.) I'm in favour of that principle, although user convenience may
break rigid adherence, eg, by attaching file-type data to the filename.


i'll spell it out for *you* (although i'm quite sure you *still* won't
understand it):

tl;dr - there is more than one type of metadata so there's no single
answer to where it must go or should go, and in some cases, there are
multiple options with various tradeoffs.

file system metadata (e.g., access permissions) *must* be stored
*separate* from the file itself (something which should be obvious, but
likely is not), while other metadata, such as id3 tags or exif data,
are usually stored inside the file but in some cases are not.

for example, title/artist/album should be in the mp3 song itself, while
play/skip counts and song ratings has to be external to it.

album artwork is often in each song, but since multiple songs from the
same album will have the same artwork, that artwork could be shared in
a separate library file, thereby saving space, something which is very
important for portable music players that have limited storage
capacity.

for photos, the camera writes assorted metadata (camera model, camera
settings, geotag data etc.) to exif tags, while photo management apps
write *different* assorted metadata (exposure adjustments, colour
balance, sharpening level, etc.) to a database and/or individual
sidecar files.

metadata also has nothing whatsoever to do with data/resource forks (or
microsoft's alternate data streams for that matter).

old time mac app developers could (and did) store whatever they want in
either or both forks, depending on what worked best for their app. file
metadata was *separate*.

there were accepted standards, but nothing (not even apple) required
anyone to adhere to those standards. as the saying goes, rules are made
to be broken.

for example, it was possible to treat the resource fork as a second
data fork, something which could potentially cause the computer to
crash if not done carefully. there were also several apps that put
executable code in the data fork, with a shim in a code resource to
jump to it. both are considered very bad practice, but both happened.
  #147  
Old December 19th 17, 12:58 AM posted to comp.sys.mac.system,alt.windows7.general,comp.sys.mac.apps
nospam
external usenet poster
 
Posts: 2,185
Default Can a Macintosh person tell us how to change the name of a file?

In article , Wolf K
wrote:

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.


Packet routing information is not metadata since it has nothing to do
with the data contained in the packet. I ti snot data about the data, it
is data about the packet.


Well, yes, that's what I said.


no, that's not what you said.

what you said was that packet headers are a type of metadata, the
*opposite* of that.

The routing data is certainly about the
data-packet. In human terms, it says "This chunk of data goes along with
those other chunks of data to make up some file." Thus the packet ID
informs the data-handler what to do. That makes it metadata.


no, it makes it a packet header, not metadata.
  #148  
Old December 19th 17, 04:05 AM posted to comp.sys.mac.apps,alt.windows7.general,comp.sys.mac.system
Erilar[_2_]
external usenet poster
 
Posts: 23
Default Can a Macintosh person tell us how to change the name of a file?

nospam wrote:
In article , Arthur Wood
wrote:

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


troll.


Either that or a trump voter 8-)

--
biblioholic medievalist via iPad
  #149  
Old December 19th 17, 03:05 PM posted to comp.sys.mac.apps, alt.windows7.general, comp.sys.mac.system
Wolffan[_2_]
external usenet poster
 
Posts: 15
Default Can a Macintosh person tell us how to change the name of a file?

On 2017 Dec 14, Your Name wrote
(in article ):

I don't know about Windows, but Mac OS X can have at least four letter
extensions (.tiff, .jpeg, .html for example).


Windows no longer cares how long the extension is. Windows (and, I think, but
I’m not certain macOS) cares only that the entire filename and dot and
extension is 255 characters or less and that certain illegal characters,
notably slashes, are not used. There was a problem where Windows had a max
path of 255 characters, later 260 characters, but Microsoft was pulled
trickery and there’s a path length maximum of 32,767 characters which can
be extended if you really, really, REALLY want to go to a lot of trouble.

I submit that 255 character filenames, including dot and extension, is plenty
for mere mortals, as is a 32,767 character path.

I don’t know what the max path length is on macOS. It appears to exceed
32,767 characters. I haven’t attempted to test that. Have at it.

  #150  
Old December 19th 17, 03:10 PM posted to comp.sys.mac.apps, alt.windows7.general, comp.sys.mac.system
Wolffan[_2_]
external usenet poster
 
Posts: 15
Default Can a Macintosh person tell us how to change the name of a file?

On 2017 Dec 14, Tim Streater wrote
(in t):

In , Your Name
wrote:

I don't know about Windows, but Mac OS X can have at least four letter
extensions (.tiff, .jpeg, .html for example).


It can be as long as you like, I suspect. Xojo uses
.xojo_binary_project, for example.


it can be as long as you like, so long as the filename, dot, and extension
fit into 255 characters. I don’t see this as a serious limitation.

hmmm...
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMONPQRSTUVWX YZ0123456789abcdefghijklmnop
qrstuvwxyzABCDEFGHIJKLMONPQRSTUVWXYZ0123456789abcd efghijklmnopqrstuvwxyzABCDEF
GHIJKLMONPQRSTUVWXYZ0123456789abcdefghijklmnopqrst uvwxyzABCDEFGHIJKLMONPQRSTUV
WXYZ0123456789.123456 is 255 characters. That’s one hell of a filename.

 




Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off






All times are GMT +1. The time now is 06:28 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2004-2018 PCbanter.
The comments are property of their posters.