Closed Bug 70723 Opened 24 years ago Closed 16 years ago

[PATCH] nsILocalFile needs chown and chgrp

Categories

(Core :: XPCOM, enhancement, P3)

enhancement

Tracking

()

RESOLVED INCOMPLETE
mozilla1.0.3

People

(Reporter: pete, Assigned: pete)

Details

Attachments

(14 files)

2.20 KB, patch
Details | Diff | Splinter Review
2.20 KB, patch
Details | Diff | Splinter Review
1.96 KB, patch
Details | Diff | Splinter Review
2.01 KB, patch
Details | Diff | Splinter Review
1.99 KB, patch
Details | Diff | Splinter Review
2.90 KB, patch
Details | Diff | Splinter Review
382 bytes, text/plain
Details
5.28 KB, patch
Details | Diff | Splinter Review
5.41 KB, patch
Details | Diff | Splinter Review
5.26 KB, patch
Details | Diff | Splinter Review
9.83 KB, patch
Details | Diff | Splinter Review
9.80 KB, patch
Details | Diff | Splinter Review
9.77 KB, patch
Details | Diff | Splinter Review
10.05 KB, patch
Details | Diff | Splinter Review
nsILocalFile needs chown for unis and mac osX --pete
Target Milestone: --- → Future
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: other → All
Hardware: Other → All
Summary: nsILocalFile needs chown → [RFE] nsILocalFile needs chown
Target Milestone: Future → ---
Marking NEW. I dont think this will happen but what the heck :)
Why, it is pretty trivial to implement. It certainly is needed. It would be nice if nsILocalFile is general purpose. --pete
Target Milestone: --- → Future
I will implement this. interface: nsIFIle attribute: attribute string owner; implementation: ::GetOwner, ::SetOwner impl file: nsLocalFileUnix.cpp On platforms that this is not applicable, we can return null. Does this look good. --pete
CAn someone look at patch# 34787 and let me know where we stand. If that patch is good maybe someone can help me do the implementations on the other platforms. Thanks --pete
Attached patch Use this patchSplinter Review
The patch is rejecting some unnescessary stuff. here is another. It does work and compile fine though. attaching another --pete
Attached patch patch from linuxSplinter Review
Adding keywords.
Keywords: patch, review
Ok patch # 34963 has the group attribute implemented as well. I think there is another bug posted for that. I will find it and mark dependent onthis patch. --pete
updating summary --pete
Summary: [RFE] nsILocalFile needs chown → [RFE] nsILocalFile needs chown and chgrp
Here is a js session getting and setting both attributes. js> const File=new Components.Constructor("@mozilla.org/file/local;1", "nsILocalFile"); var f=new File(); js> js> js> f.initWithPath('/home/petejc/OWNER/owner.js'); js> f.owner; petejc js> f.group; petejc js> f.group='wheel'; wheel js> f.group; wheel js> f.group='root'; Invalid group name `root' uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsILocalFile.group]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: typein :: <TOP_LEVEL> :: line 9" data: no] js> f.group='petejc'; petejc js> f.group; petejc js> f.owner petejc js> f.owner='root'; root js> f.owner; root js> f.owner='petejc'; petejc js> f.owner; petejc js>
Attached file javascript test file
Here is the output of the above attached test js file #34974 $ ./run-mozilla.sh ./xpcshell /home/petejc/OWNER/owner.js MOZILLA_FIVE_HOME=. LD_LIBRARY_PATH=.:./plugins LIBRARY_PATH=.:./components SHLIB_PATH=. LIBPATH=. ADDON_PATH=. MOZ_PROGRAM=./xpcshell MOZ_TOOLKIT= moz_debug=0 moz_debugger= Type Manifest File: /usr/src/MOZILLA/mozilla/dist/bin/components/xpti.dat nsNativeComponentLoader: autoregistering begins. nsNativeComponentLoader: autoregistering succeeded nNCL: registering deferred (0) old owner =petejc old group =petejc new owner =root new group =nobody CanUnload_enumerate: skipping native
Ok, i'll take an r= and sr= for patch #34989 This should cover all the other platforms. I am just returning NS_ERROR_NOT_IMPLEMENTED for now. --pete
Summary: [RFE] nsILocalFile needs chown and chgrp → [RFE][PATCH] nsILocalFile needs chown and chgrp
Please remove the inline (not ifdef'd) printf's for errors, or ifdef them. Otherwise, for what it's worth :-), r=jesup.
Ok, patch #35011 in now at the plate. --pete
* Should the #ifdef DEBUG statements be #ifdef NS_DEBUG? * Some of the error messages are pretty obscure: "Hrrm = I failed" or something wont help someone seeing these messages inside a huge application. * Some of these can probably be NS_WARNING() In general I am skeptical of this patch. Has it been demonstrated that this facility will ever be available and suitable in this form on Windows or the Mac? Having facilities on an nsIFile that only works on one platform seems to defeat the purpose somewhat. It only helps JavaScript - C or Python implemented code could simply use these platform specific tricks directly.
> Has it been demonstrated that this facility will ever be available and > suitable in this form on Windows or the Mac? But couldn't you raise the same argument about the permissions attribute? It's not implemented on mac for example. I beleive uid, gid *and* permissions are now relevant on Mac OSX. I am submitting this patch, because i would like to see nsIFile extend and be more general purpose. I do admit javascript is a factor here. Package writers need to have more to work with when it comes to local I/O. --pete
Windows has more complex ACLs on NTFS, at least, and so do some Unix systems. Maybe that should be exposed through another interface, though. Do we care about setuid and setgid as well? Please describe, in detail, how these operations interact with symlinks, both dangling and intact.
> Do we care about setuid and setgid as well? Sure, I care about it and will gladly implement it as long as there is agreement that this is a good thing to pursue. >Please describe, in detail, how these operations interact with symlinks, both > dangling and intact. Right now if the file is a symlink, this implementation changes the owner and group of the file being pointed to not the symlink itself. I can implement that separately using lchown. If the link is dangling, use of these gettters and setters will return NS_ERROR_FAILURE because we are trying to get a uid and gid from a non existing file not the link. Perhaps, an ownerOfLink and groupOfLink attribute might be in order here? --pete
patch #35584 has attributes: ownerOfLink groupOfLink implemented and tested. As well as fix for ::IsSymlink and ::IsSpecial methods. tests handle dangling links nicely. --pete
ok, patch #35591 deals correcly w/ dangling links. Test code: js> const localFile='/tmp/foo_link'; // a dangling link js> const File=new Components.Constructor("@mozilla.org/file/local;1", "nsILocalFile"); js> var f=new File(); js> f.initWithPath(localFile); js> f.exists(); false js> f.isSymlink(); true js> f.ownerOfLink; petejc js> f.groupOfLink; petejc js> f.ownerOfLink='root'; root js> f.groupOfLink='root'; root js>
Taking bug
Assignee: dougt → petejc
Status: NEW → ASSIGNED
Patch is still good. Validation test below. js> o; [xpconnect wrapped nsIFile @ 0x8274c00] js> o.path; /tmp/foo js> o.owner; root js> o.group; wheel js> o.owner='petejc'; petejc js> o.owner; petejc js> o.group='nobody'; nobody js> o.group; nobody js> f.initPath('/tmp/foo_ln'); /tmp/foo_ln js> var s=f.nsIFile; js> s.isSymlink(); true js> s.target; foo js> s.owner; petejc js> s.group; nobody js> s.ownerOfLink; root js> s.groupOfLink; wheel js> o['delete'](false); js> s.target; foo js> o.exists(); false js> o.path; /tmp/foo js> s.path; /tmp/foo_ln js> s.ownerOfLink; root js> s.groupOfLink; wheel js> s.ownerOfLink='petejc'; petejc js> s.groupOfLink='nobody'; nobody js>
Priority: -- → P3
Target Milestone: Future → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla1.0
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Summary: [RFE][PATCH] nsILocalFile needs chown and chgrp → [PATCH] nsILocalFile needs chown and chgrp
Target Milestone: mozilla1.0.1 → mozilla1.0.3
Is the patch applied to current sources? Why is this still open? :)
Any reason we don't want to change ownership in nsILocalFile?
QA Contact: kandrot → nobody
QA Contact: nobody → xpcom
Not sure why we want this now, reopen if somebody still wants to own it.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: