To me they seem to be doing some very similar things and I do not understand why there are two distinct commands.
chflags is a BSD-subsystem command that let change additional flags a file system may support natively. Historically, this is a kind of basic file mode extension support in BSD system, by using non-used bits in the metadata native filesystem. As MacOS is built on top of a BSD-flavour, chflags is supported (but a few extensions are supported). Values you can manipulate through chflags are predetermined.
xattr is a tool to manipulate user meta data associated to files. These metadata can be far more rich than simple on/off setting. Implementation of this is free, even if many filesystem have a special support for this. Historical HFS+ mac filesystem has a special support for this in the so-called named-forks. There is no limitation on kind/number of metadata that can be associated to a given file. The filesystem is unaware of these metadata content, it is just another kind of storage. That may be the OS or tools that in some context need to have access to these. For example I can add any such metadata I want to a given file :
$ ls -ail myfile
8607162443 -rw-r--r-- 1 yunes staff 0 6 jui 16:50 myfile
$ xattr -w mydata myvalue myfile %now my file is associated with some metadata
$ ls -ail myfile
8607162443 -rw-r--r--# 1 yunes staff 0 6 jui 16:50 myfile
$ xattr -l myfile %let me know which are the metadata associated to a given file
mydata : myvalue
$
So the system stored those metadata somewhere (it may use the help of some filesystem support for this or some ordinary file appropriately named, ever saw those strange ._ prefixed files?) but the data means nothing to the filesystem. Some tools may use thus to do something special...
chflags manages a small number of specific flags that are known by the operating system (such as "hidden"). These are stored in a bitmask, similar to chmod values. It is fairly old, going back to BSD 4.4 (1994).
xattr manages generic key-value metadata and comes from the HFS+ filesystem. Any application can attach arbitrary metadata and may interpret it in any way that it likes. I believe the feature was added in 10.4 (2005).
Related
I want to change crtime properties in bash.
First, I tried to check the crtime as following command.
stat test
And next, I changed the timestamp.
touch -t '200001010101.11' test
But I realized that if the crtime is already past than the date I wrote, then it can't be changed.
So I want to know how to specify the crtime even it is already past.
Edit:
According to This answer to a similar question, you may be able to use debugfs -w -R 'set_inode_field ...' to change inode fields, though this does require unmounting.
man debugfs shows us the following available commmand:
set_inode_field filespec field value
Modify the inode specified by filespec so that the inode field field has value value. The list of valid inode fields which can be set via this command can be displayed by using the command:
set_inode_field -l Also available as sif.
You can try the following to verify the inode number and name of the crtime field:
stat -c %i test
debugfs -R 'stat <your-inode-number>' /dev/sdb1
and additionally df -Th to find the /dev path of your filesystem (e.g. /dev/sdb1)
Followed by:
umount /dev/sdb1
debugfs -w -R 'set_inode_field <your-inode-number> crtime 200001010101.11' /dev/sdb1
Note: In the above commands, inode numbers must be indicated with <> brackets as shown. Additionally, as described here it may be necessary to flush the inode cache with echo 2 > /proc/sys/vm/drop_caches
Original answer:
You might try birthtime_touch:
birthtime_touch is a simple command line tool that works similar to
touch, but changes a file's creation time (its "birth time") instead
of its access and modification times.
From the birthtime_touch Github page, which also notes why this is not a trivial thing to accomplish:
birthtime_touch currently only runs on Mac OS X. The minimum required
version is Mac OS X 10.6. birthtime_touch is known to work for files
that are stored on HFS+ and MS-DOS filesystems.
The main problem why birthtime_touch does not work on all systems and
for all filesystems, is that not all filesystems store a file's
creation time, and for those that actually do store the creation time
there is no standardized API to access/change that information.
This page has more details about the reasons why we haven't yet seen support for this feature.
Beyond this tool, it might be worth looking at the source on Github to see how it's accomplished and whether or not it might be portable to Unix/Linux. And beyond that, I imagine it would be necessary to write low level code to expose those aspects of the filesystems that crtime would be stored.
I have did search and people say that I must use
sudo sh -c ’echo 1 > /proc/sys/kernel/randomize_va_space to edit this file. Can someone explain to me why?
When I use vim with root to edit this file and save it shows an error: "/proc/sys/kernel/randomize_va_space" E667: Fsync failed
The files in /proc are not regular files. They are in fact kernel variables exposed through filesystem for easier access. Because of that, they don't support all functions of "normal" files, namely, fsync.
The text editor doesn't know that it's dealing with a special file and tries to use some unsupported function. On the other hand, echo ... > file works because it does not use fsync function.
fsync is a function that tells the OS to write any pending changes from file to disk.
I am the owner, as shown by ls -alts, but for whatever reason, I can't change the permissions of the files like I want. I want to make the file read only:
chmod 400 <file-name>
however, the ls -al still shows -rwxrwxrwx.
The file is on an external drive. I know that sometimes this causes issues when users want to read and write. However, in this case, I'd like to make the access to my files more restrictive not less restrictive.
I checked out this SO question but I don't see an option to make the permissions more restrictive.
thanks.
You can't change the permissions on the file because it's on a FAT32 volume, and that volume format does not support storing file permissions (see, for example, this askubuntu question). But if all you want to to is make the file read-only, you can get that effect by locking it (and the lock attribute is supported on FAT32). You can either use the Finder's Get Info window (check the "Locked" box), or use the command chflags uchg <file-name>.
I want create a hidden ini file under macosX environment with Firemonkey (XE3).
But unfortunaly this command is not known anymore in system.utilys
Somebody tips?
On a Mac, there are two ways to make file "hidden" or "invisible".
Like Linux or Unix, you can start the filename with a dot (.).
You can also use the setfile tool that ships with Xcode to set attributes to make it invisible ([setfile a -V filename][3]).
Depending on the way, you will have to replace the Win32 specific SetFileAttr call with a Mac specific rename, or find out which API setfile uses to set the attributes.
In UNIX (and in this layer Mac OS is largely spin-off from FreeBSD) there is no "hidden" flag on file, instead special files should have their name started with dot. http://en.wikipedia.org/wiki/Dot-file
So if you want to hide a file - rename it.
That is not the question about Delphi = that is the question of operating system, Windows vs UNIX.
Open console/terminal/whatever they call command prompt in Apple, go to ur home folder and issue two commands: ls and ls -a - compare the file lists in output.
Well, for starters you can do it in Linux - http://bellard.org/jslinux/ - wait few seconds for it to boot, then issue ls, ls -l, ls -a, ls -la and see the difference.
Dot-files are treated specially and hidden by default.
There are a lot of guides out there on creating custom icons, but the challenge I have experienced is how to put .VolumeIcon.icns on some sort of mass produced volume (like a flash drive) so that all Macs after 10.4 use it.
OS X consistently creates something called a resource fork file for .VolumeIcon.icns which tells future Macs its mounted on to use it. This file, when I produced it on various Macs, has consistently been ._ follow by the special use character "uf029" in its filename - and this is where the problem lies. This file, therefore, shows up on Windows as ._? on OSX as . _ . (without the spaces, I'm guessing stackoverflow needs an escape char) and various other ways in different places. This file is required for .VolumeIcon.icns to work, it is always 4k, and seems to be composed of some proprietary encoding.
This is a vary hard file to manage, but I got around this on git by first zipping it - otherwise it isn't even recognized as a file (even though you can list it in a dir with ls -a, ls [filename] returns some variation of a file not found error, since its a resource fork file). More on that here.
I'm wondering how Ipods, for example, I've plugged in tell OS X to use the .VolumeIcon.icns file without this resource fork file (I see no ._. file when I ls -a the Ipod). How do other people distribute Volumes with a VolumeIcon to Mac users without this problematic file? Another way is to set a VolumeIcon attribute using the OS X dev tool "SetFile -a C /Volumes/name"
Any Apple developers out there know of a work around?