I have been using Fantom now for about 2 months, and I am very impressed by the design and the ease of use. It seems there are some people out there thinking...
Anyway, I have a problem with the File class. I am running on WinXP, 32bit Ubuntu, 32bit Slackware, numerous other 32bit linux systems, Cygwin as well as Ubuntu 64bit.
When I copy a file using File.copyTo, there is no problem on any of the systems except for Ubuntu 64 bit. The file is always copied using file permissions 644. The original file being copied is an executable file, and I have all access rights required for the operation. Obviously it fails with permission denied error when I try to execute it.
I can not find anything in the source code or the documentation about file permissions or how to change it. Please can this be added to the api?
Promoted to ticket #1139 and assigned to brian
Hi Coderz, welcome to Fantom!
I didn't think that Java exposed APIs for security settings, but I just looked and it looks like they added some APIs in 1.6 for it. So I will expose that in Fantom, although if you are running on 1.5 or older it will fail.
Given the all the different types of permissions (and potentially full access to permissions in the new 1.7 file APIs), I'm thinking the most flexible design would be to expose this as a permissions String field. For now just "rwx", with potential future support for owner, group levels, etc.
Also as part of this feature, I will ensure that copyTo maintains the same permissions as the source file.
Does everybody like that design?
If i understand that right, the issue is with Java.
Java being cross platform and all does not handle File permissions at all (in the API's), so usually you have to deal with that separately (chmod) which can be quite annoying.
Actually since Java 1.6 it can handle file permissions (partially) http://java.sun.com/javase/6/docs/api/java/io/File.html
See some infos here: http://stackoverflow.com/questions/664432/java-how-do-i-programmatically-change-file-permissions
But Fantom is built to be runnable on Java 1.5, so it probably can't take advantage of that right now.
Thanks for the Welcome!
I like the idea rian, although I would have implimented another slot in the File class with an Enum for permission values. The Enum can also have methods for modifying the permissions. That way you reduce the possibility of screwing up the access string. Or alternatively make it a Str since it is a collection of attributes and lends itself towards being extended to groups, etc. in the future.
Ticket resolved in 1.0.58
Well this original ticket is from July of last year. I really was sort of waiting for 1.7 to come out so we could design a really nice API for permissions, attributes, and file watchers. But with 1.7 still not out, we are still talking years before it is widely deployed. In the meantime, what I have done is tried to use the 1.6 File APIs to copy the permissions on file copies. The code should gracefully degrade on 1.5 APIs (like the Uuid class).
Renamed from File permissions to File.copy: maintain permissions
Login or Signup to reply.