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. |
|
|
Thread Tools | Rate Thread | Display Modes |
#121
|
|||
|
|||
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 |
Ads |
#122
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
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. |
#123
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
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. |
#124
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
"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. |
#125
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
In article , Mayayana
wrote: Complicated, isn't it? not really. |
#126
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
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 |
#127
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
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. |
#128
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
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 |
#129
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
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. |
#130
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
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. |
#131
|
|||
|
|||
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. |
#132
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
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 |
#133
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
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. |
#134
|
|||
|
|||
Can a Macintosh person tell us how to change the name of a file?
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 |
#135
|
|||
|
|||
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. so what's your point? that you can't refute anything i said, which is why you resort to ad hominem attacks. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|