From: thilo <th...@th...> - 2012-10-21 20:38:55
|
Hello everyone, I just encountered the following problem: after copying several images (each named ".DirIcon") into different directories on a NFS mount, my ROX-Filer (2.11) Window does, as expected, show some of them instead of the default folder icon, but not all. I discovered that for ROX-Filer to show the new icons, both the directory (on the NFS mount) AND the corresponding .DirIcon must be owned by myself. This is a bit surprising, since both directories and .DirIcons are world readable. This can be reproduced: as soon as the directory or the .DirIcon are not owned by myself, the Filer displays the default folder icon. I copied the directories onto a local ext4 filesystem and played with the ownerships. Everything's allright, ROX Filer always shows the .DirIcon images. I am not at all sure that this would be a ROX Filer problem, may also be related to NFS or something completely different. However, as both the directory and the .DirIcon are readable, the filer should IMO display the new icon. Any hints? Regards, Thilo |
From: Laverne S. <lve...@gm...> - 2012-10-22 01:59:13
|
On Sun, Oct 21, 2012 at 3:12 PM, thilo <th...@th...> wrote: > Hello everyone, > > I just encountered the following problem: after copying several > images (each named ".DirIcon") into different directories on a > NFS mount, my ROX-Filer (2.11) Window does, as expected, show > some of them instead of the default folder icon, but not all. > > I discovered that for ROX-Filer to show the new icons, both the > directory (on the NFS mount) AND the corresponding .DirIcon > must be owned by myself. This is a bit surprising, since both > directories and .DirIcons are world readable. > This can be reproduced: as soon as the directory or the > .DirIcon are not owned by myself, the Filer displays the > default folder icon. > > I copied the directories onto a local ext4 filesystem and > played with the ownerships. Everything's allright, ROX Filer > always shows the .DirIcon images. > > I am not at all sure that this would be a ROX Filer problem, > may also be related to NFS or something completely different. > However, as both the directory and the .DirIcon are readable, > the filer should IMO display the new icon. > > Any hints? > > Regards, > Thilo > > I think that you're not quite correct. I've been doing some playing around on my TinyCore Linux box and it doesn't seem to be an issue with readability, but rather an issue of writebility. If the directory is world-writable then the .DirIcon isn't used, but the world-write privilege on the .DirIcon doesn't matter. On my machine, if I'm a non-privileged user and the Directory and .DirIcon are both owned by root and universally readable; then everything is fine. As soon as the directory is world-writable then the default icon is displayed instead of the custom one. It doesn't matter if the .DirIcon file is world-writable as long as the directory isn't. Is this info helpful? It seems to be some sort of security feature. The side effect is that you can't have AppDir or use .DirIcon on a drive that has a format that doesn't support file permissions. (e.g. NTFS ) Here is a link to the section in the ROX-Filer manual that contains information for a possible workaround: http://rox.sourceforge.net/Manual/Manual/Manual.html#id2507256 Cheers, Lvern |
From: thilo <th...@th...> - 2012-10-22 05:25:12
|
Thanks for the reply. Unfortunately, my situation is different, since neither directory nor .DirIcon are world writeable (but user- and group-writeable). The problem persists (on the NFS share): as soon as I change the ownership of directory or .DirIcon to another user (privileged or not), ROX stops displaying the .DirIcon as the folder icon. Setting the folder icons in another way is not an option, as i would like them to be available to any client mounting the NFS share. Also, the icons in question are album covers for my music collection, which I would like the upnp server to deliver on a per directory basis. Thus, I thought both ROX and the upnp server could both use the .DirIcons. Regards, Thilo Ernst On Sun, Oct 21, 2012 at 08:58:46PM -0500, Laverne Schrock wrote: > I think that you're not quite correct. I've been doing some playing around > on my TinyCore Linux box and it doesn't seem to be an issue > with readability, but rather an issue of writebility. > If the directory is world-writable then the .DirIcon isn't used, but the > world-write privilege on the .DirIcon doesn't matter. > On my machine, if I'm a non-privileged user and the Directory and .DirIcon > are both owned by root and universally readable; then everything is fine. > As soon as the directory is world-writable then the default icon is > displayed instead of the custom one. It doesn't matter if the .DirIcon > file is world-writable as long as the directory isn't. > Is this info helpful? > It seems to be some sort of security feature. The side effect is that you > can't have AppDir or use .DirIcon on a drive that has a format that > doesn't support file permissions. (e.g. NTFS ) > Here is a link to the section in the ROX-Filer manual that contains > information for a possible > workaround: http://rox.sourceforge.net/Manual/Manual/Manual.html#id2507256 > Cheers, > Lvern |
From: Musus U. <mu...@ve...> - 2012-10-22 11:55:46
|
On 22/10/12 06:25, thilo wrote: > Thanks for the reply. Unfortunately, my situation is different, > since neither directory nor .DirIcon are world writeable (but > user- and group-writeable). The problem persists (on the NFS > share): as soon as I change the ownership of directory or > .DirIcon to another user (privileged or not), ROX stops > displaying the .DirIcon as the folder icon. I've been bitten by this .DirIcon issue before; in my case the problem shows up whenever the directory and .DirIcon are owned by different users. Whether the user that owns the things is me or not doesn't matter, as long as I can read them. FWIW, my setup now has both the directory and .DirIcon owned by the same (non-)user, "mp3" in my case, and the directory is writable by a group to which all users I want to allow to write to the thing belong. -- Erst wenn die Wolken schlafengehn | Personal: ad...@ve... kann man uns am Himmel sehn | Techie: mu...@ve... wir haben Angst und sind allein... | WWW: verelanthe.co.uk/musus/ Gott weiss ich will kein Engel sein! -- Rammstein / Engel |
From: thilo <th...@th...> - 2012-10-22 12:21:55
|
On Mon, Oct 22, 2012 at 12:32:02PM +0100, Musus Umbra wrote: > I've been bitten by this .DirIcon issue before; in my case the problem > shows up whenever the directory and .DirIcon are owned by different > users. Whether the user that owns the things is me or not doesn't > matter, as long as I can read them. > > FWIW, my setup now has both the directory and .DirIcon owned by the same > (non-)user, "mp3" in my case, and the directory is writable by a group > to which all users I want to allow to write to the thing belong. Thanks a lot, your description matches exactly what i just found in the source code, on lines 291-292 of diritem.c: * .DirIcon and AppRun must have the same owner as the * directory itself, to prevent abuse of /tmp, etc. Both together make me all the more more eager to go home and verify. Unfortunately, that will have to wait -- got work to do. Usually, my music collection is, concerning ownerships, organized just as yours. Only just now I'm reorganizing everything and intended to fix ownerships and permissions afterwards -- perhaps it is just the current mess causing my problems. I also thought to have tested the case in question (directory and .DirIcon owned by same user, but not me), but maybe I had already been too confused to do so. Will report back later, regards, Thilo |
From: thilo <th...@th...> - 2012-10-22 16:03:56
|
On Mon, Oct 22, 2012 at 02:21:42PM +0200, thilo wrote: > On Mon, Oct 22, 2012 at 12:32:02PM +0100, Musus Umbra wrote: > > I've been bitten by this .DirIcon issue before; in my case the problem > > shows up whenever the directory and .DirIcon are owned by different > > users. Whether the user that owns the things is me or not doesn't > > matter, as long as I can read them. This is just the case, so I consider this solved. Stupid that I didn't stumble over it when fiddling around with the ownerships. This mechanisms complicates the contribution of .DirIcons to a directory tree shared between multiple users (which isn't the case here, anymore) -- something like a .DirIcon-ownership- adjustment-script would then be in order. Thanks again, Thilo |