This subcommand returns or sets platform specific values associated with a file. The first form returns a list of the platform specific flags and their values. The second form returns the value for the specific option. The third form sets one or more of the values. The values are as follows:
On Unix, -group gets or sets the group name for the file. A group id can be given to the command, but it returns a group name. -owner gets or sets the user name of the owner of the file. The command returns the owner name, but the numerical id can be passed when setting the owner. -permissions sets or retrieves the octal code that chmod(1) uses. For files, its value is a standard 4-byte octal number. For directories, it is a five-byte octal number, and the value of the fifth byte is 4. This command does also has limited support for setting using the symbolic attributes for chmod(1), of the form [ugo]?[[+-=][rwxst],[...]]], where multiple symbolic attributes can be separated by commas (example: u+s,go-rw add sticky bit for user, remove read and write permissions for group and other). A simplified ls style string, of the form rwxrwxrwx (must be 9 characters), is also supported (example: rwxr-xr-t is equivalent to 01755).
On Windows, -archive gives the value or sets or clears the archive attribute of the file. -hidden gives the value or sets or clears the hidden attribute of the file. -longname will expand each path element to its long version. This attribute cannot be set. -readonly gives the value or sets or clears the readonly attribute of the file. -shortname gives a string where every path element is replaced with its short (8.3) version of the name. This attribute cannot be set. -system gives or sets or clears the value of the system attribute of the file.
On Macintosh, -creator gives or sets the Finder creator type of the file. -hidden gives or sets or clears the hidden attribute of the file. -readonly gives or sets or clears the readonly attribute of the file. Note that directories can only be locked if File Sharing is turned on. -type gives or sets the Finder file type for the file.
Each platform (win,mac,unix) has its own set of attributes attached to native files. With the VFS support in Tcl 8.4, any filesystem can create its own set of attributes (either read-only or read-write) with arbitrary names and states. These attributes are defined by the filesystem (it might be nice in the future to be able to extend these, dynamically on the fly so, say, we could add a '-versioncontrolstate' attribute to all native files).
What about BSD flags? schg, sappnd, etc.
DKF: Nobody's wanted them enough to supply the code to implement them. :-) However, the main tricky bit would be the autoconf hackery to detect that we can use chflags (and ensuring that struct stat had an st_flags member). I'd prefer to stick with the UF_* flags though...
Does anyone already have some code that given the numeric value returned by file attributes -permissions, converts the number into a symbolic form that would be accepted by file attributes -permission as an argument?
Yes, one might just be able to pass the number back to file attributes -permission, but displaying the symbolic format to the user would, at times, be more useful.
Symbolic links: file attributes returns the attributs of the target of a given link. This causes it to fail if the symlink is dangling (i.e. the target does not exist). It would be nice to have a 'file lattributes' command or a -link switch to file attributes, to avoid this, and give back the attributes of the link itself. -- LEG
LV Has anyone an example of what one has to do so that, from Windows, one can set the permissions of a file being hosted on Unix?
According to the info about (and on the file man page), that functionality doesn't appear to be present in Tcl by default. Even the tclx extension says that its chmod doesn't exist on Windows.
So what does one have to do so that this information is set? A co-worker is attempting to copy a file that is being served from Unix, and after the file copy, all of its permissions are lost.
Lars H: This would depend very much on how the file is accessed/made accessible.
I suspect (from lack of indication to the contrary) that your situation is that the file resides in a part of the Unix machine's file system that the Windows machine in turn has mounted, and that Tcl gets to access it as part of the Windows filesystem? In this case, there's probably not much to do: Tcl does all access via Windows syscalls, Windows (or some driver) translates these to whatever protocol the Unix file server daemon speaks, and that in turn translates this to Unixy syscalls. Only concepts they all agree upon are likely to make it through, and if Windows doesn't have Unixy permissions (is it the executable status that worries you?) then I can understand it if the driver doesn't attempt to mirror it.
What needs to be done is to establish a connection to the Unix machine that gives you more native access to its filesystem. Classically, one would probably just start a remote shell on the server, and send it the right commands; fish formalises this somewhat. Perhaps An SSH virtual filesystem will do what you want out of the box? But if your co-worker doesn't have a shell account on the Unix machine, then you may be out of luck.