Re: isofs unhide option: troubles with Wine

Re: isofs unhide option: troubles with Wine

[Andries.Brouwer]

>> Further, I would argue that if you accept that unhide is a
>> reasonable default for me to force into the fstab, then
>> it is a reasonable default for the kernel to have.

> I'd tend to agree, simply because the defaults ought to make things
> possible rather than impossible. Question is - why was hide the default
> and what was that decision based upon ?

Inspection of the patch history shows:

1.1.63:
+                 /* Do not report hidden or associated files */

1.1.94:
+                       if (inode->i_sb->u.isofs_sb.s_unhide=='n') {
				/* Do not report hidden or associated files */
+       popt->unhide = 'n';

I do not think my linux-kernel archives contain any discussion.

As far as I can see there is no objection at all to make unhide
the default.

But note:
The test &5 tests two bits.
bit 0 is the hidden bit - see ECMA 119 - 9.1.6
bit 2 is the test for associated files.

http://developer.apple.com/technotes/fl/fl_36.html explains:

-----------------------------------------------------------------
Associated files are exactly analogous to resource forks.

An associated file is defined as having the associated bit set in
the file flags byte of the directory record. It has exactly the same
file identifier as its counterpart, and resides immediately before
its counterpart in the directory. The associated file is treated as the
resource fork, its counterpart is treated as the data fork of the file.

For example, if a file "FOO.;1" has an associated file, there will be
two adjacent directory records named "FOO.;1"; the first one (the
resource fork) will have the associated bit set, the second one
(the data fork) will have the associated bit clear.
-----------------------------------------------------------------

I think that the right default would be to show hidden files,
but not to show associated files.


Andries

Re: isofs unhide option: troubles with Wine

[Jeremy White]

[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]

Sorry for the long delay; had to take the kids to Disney World <grin>.

I'm attaching two patches, both against 2.5.20.  Please be gentle,
I'm a kernel newbie.

Patch #1:  bugfix.patch
    Fixes a bug in the parsing of options for the isofs driver.
    Behavior was on an unrecognized option to simply return success.
     A mount -o blatnik,<useful-option>,<useful-option>  
          would silently lose all the useful options.

    This should be applied, imho, regardless.



Patch #2:  reversehide.patch
    I've eliminated the 'unhide' option and made that behavior
        the default (show files with the hidden bit on).
    I've added a 'hide' option which hides files marked with the hidden bit.
    I've also preserved the behavior which hid 'associated' files by 
default,
        and added a 'showassoc' mount option, which will cause the
        driver to show files marked with the associated bit.
        (The prior behavior was that unhide would show both
          hidden and associated files)

    Issues:
        1.  I have no CDs with associated files on them, and thus
             this change is completely untested.  Looks good to me <g>.
        2. Arguably, this same change should be made to the udf
            driver, but I do not have a DVD writer, nor a DVD with
            either hidden or associated files, so I would be unable
            to test any such patch made.  I'm willing to submit a
            patch that compiles, if that would be of value.

Thanks,

Jeremy

Alan Cox wrote:

>On Mon, 2002-06-03 at 18:05, Jeremy White wrote:
>  
>
>>>possible rather than impossible. Question is - why was hide the default
>>>and what was that decision based upon ?
>>>      
>>>
>>I agree with Alan - this is the key question.  
>>
>>I would further argue that silence in response to this question
>>suggests that there was no carefully considered reason;
>>presumably a good hacker just followed the spec, without considering how
>>these CDs are actually used.
>>
>>It further suggests to me that I should prep a patch.
>>    
>>
>
>Go for it. I'll give it a test in the -ac tree happily. If nobody
>screams it can then go upstream.
>  
>



[-- Attachment #2: bugfix.patch --]
[-- Type: text/plain, Size: 211 bytes --]

--- orig/fs/isofs/inode.c	Sun Jun  2 20:44:53 2002
+++ linux-2.5.20/fs/isofs/inode.c	Tue Jun 18 21:12:29 2002
@@ -460,7 +460,7 @@
 		    break;
 		  }
 		}
-		else return 1;
+		else return 0;
 	}
 	return 1;
 }

[-- Attachment #3: reversehide.patch --]
[-- Type: text/plain, Size: 4433 bytes --]

diff -ur orig/Documentation/filesystems/isofs.txt linux-2.5.20/Documentation/filesystems/isofs.txt
--- orig/Documentation/filesystems/isofs.txt	Sun Jun  2 20:44:42 2002
+++ linux-2.5.20/Documentation/filesystems/isofs.txt	Mon Jun 17 20:58:06 2002
@@ -26,6 +26,7 @@
   mode=xxx      Sets the permissions on files to xxx
   nojoliet      Ignore Joliet extensions if they are present.
   norock        Ignore Rock Ridge extensions if they are present.
-  unhide        Show hidden files.
+  hide          Completely strip hidden files from the file system.
+  showassoc     Show files marked with the 'associated' bit
   session=x     Select number of session on multisession CD
   sbsector=xxx  Session begins from sector xxx
diff -ur orig/fs/isofs/dir.c linux-2.5.20/fs/isofs/dir.c
--- orig/fs/isofs/dir.c	Sun Jun  2 20:44:45 2002
+++ linux-2.5.20/fs/isofs/dir.c	Mon Jun 17 21:35:53 2002
@@ -194,12 +194,12 @@
 
 		/* Handle everything else.  Do name translation if there
 		   is no Rock Ridge NM field. */
-		if (sbi->s_unhide == 'n') {
-			/* Do not report hidden or associated files */
-			if (de->flags[-sbi->s_high_sierra] & 5) {
-				filp->f_pos += de_len;
-				continue;
-			}
+
+		/* Do not report hidden files if so instructed, or associated files unless instructed to do so */
+                if (  ( sbi->s_hide =='y' && (de->flags[-sbi->s_high_sierra] & 1) ) ||
+                      ( sbi->s_showassoc =='n' && (de->flags[-sbi->s_high_sierra] & 4) ) ) {
+                        filp->f_pos += de_len;
+                        continue;
 		}
 
 		map = 1;
diff -ur orig/fs/isofs/inode.c linux-2.5.20/fs/isofs/inode.c
--- orig/fs/isofs/inode.c	Sun Jun  2 20:44:53 2002
+++ linux-2.5.20/fs/isofs/inode.c	Tue Jun 18 21:14:08 2002
@@ -172,7 +172,8 @@
 	char rock;
 	char joliet;
 	char cruft;
-	char unhide;
+	char hide;
+	char showassoc;
 	char nocompress;
 	unsigned char check;
 	unsigned int blocksize;
@@ -341,7 +342,8 @@
 	popt->rock = 'y';
 	popt->joliet = 'y';
 	popt->cruft = 'n';
-	popt->unhide = 'n';
+	popt->hide = 'n';
+	popt->showassoc = 'n';
 	popt->check = 'u';		/* unset */
 	popt->nocompress = 0;
 	popt->blocksize = 1024;
@@ -367,8 +369,12 @@
 		  popt->joliet = 'n';
 		  continue;
 		}
-	        if (strncmp(this_char,"unhide",6) == 0) {
-		  popt->unhide = 'y';
+	        if (strncmp(this_char,"hide",4) == 0) {
+		  popt->hide = 'y';
+		  continue;
+		}
+	        if (strncmp(this_char,"showassoc",9) == 0) {
+		  popt->showassoc= 'y';
 		  continue;
 		}
 	        if (strncmp(this_char,"cruft",5) == 0) {
@@ -562,7 +568,8 @@
 	printk("joliet = %c\n", opt.joliet);
 	printk("check = %c\n", opt.check);
 	printk("cruft = %c\n", opt.cruft);
-	printk("unhide = %c\n", opt.unhide);
+	printk("hide = %c\n", opt.hide);
+	printk("showassoc= %c\n", opt.showassoc);
 	printk("blocksize = %d\n", opt.blocksize);
 	printk("gid = %d\n", opt.gid);
 	printk("uid = %d\n", opt.uid);
@@ -806,7 +813,8 @@
 	sbi->s_rock = (opt.rock == 'y' ? 2 : 0);
 	sbi->s_rock_offset = -1; /* initial offset, will guess until SP is found*/
 	sbi->s_cruft = opt.cruft;
-	sbi->s_unhide = opt.unhide;
+	sbi->s_hide = opt.hide;
+	sbi->s_showassoc = opt.showassoc;
 	sbi->s_uid = opt.uid;
 	sbi->s_gid = opt.gid;
 	sbi->s_utf8 = opt.utf8;
diff -ur orig/fs/isofs/namei.c linux-2.5.20/fs/isofs/namei.c
--- orig/fs/isofs/namei.c	Sun Jun  2 20:44:52 2002
+++ linux-2.5.20/fs/isofs/namei.c	Mon Jun 17 21:16:08 2002
@@ -140,12 +140,12 @@
 		}
 
 		/*
-		 * Skip hidden or associated files unless unhide is set 
+		 * Skip hidden or associated files unless hide or showassoc, respectively, is set 
 		 */
 		match = 0;
 		if (dlen > 0 &&
-		    (!(de->flags[-sbi->s_high_sierra] & 5)
-		     || sbi->s_unhide == 'y'))
+                    ( sbi->s_hide =='n' || (!(de->flags[-sbi->s_high_sierra] & 1)) ) &&
+                    ( sbi->s_showassoc =='y' || (!(de->flags[-sbi->s_high_sierra] & 4)) ) )
 		{
 			match = (isofs_cmp(dentry,dpnt,dlen) == 0);
 		}
diff -ur orig/include/linux/iso_fs_sb.h linux-2.5.20/include/linux/iso_fs_sb.h
--- orig/include/linux/iso_fs_sb.h	Sun Jun  2 20:44:50 2002
+++ linux-2.5.20/include/linux/iso_fs_sb.h	Mon Jun 17 20:57:47 2002
@@ -20,7 +20,8 @@
 	unsigned char s_cruft; /* Broken disks with high
 				  byte of length containing
 				  junk */
-	unsigned char s_unhide;
+	unsigned char s_hide;
+	unsigned char s_showassoc;
 	unsigned char s_nosuid;
 	unsigned char s_nodev;
 	unsigned char s_nocompress;

Re: isofs unhide option: troubles with Wine

[Guest section DW]

On Mon, Jun 10, 2002 at 05:52:53AM -0600, Thunder from the hill wrote:

> On Sun, 9 Jun 2002, Francois Gouget wrote:
> > 2. or should it completely ignore the 'hidden' bit?
> 
> I already _had_ a patch which did exactly this.
> 
> Regards,
> Thunder

But your patch is too primitive, it affects both hidden and
associated files, while you only wanted to affect hidden files.

Re: isofs unhide option: troubles with Wine

[Thunder from the hill]

Hi,

On Sun, 9 Jun 2002, Francois Gouget wrote:
> 2. or should it completely ignore the 'hidden' bit?

I already _had_ a patch which did exactly this.

Regards,
Thunder

--- linux-2.5.20/fs/isofs/namei.c	Sun Jun  2 19:44:52 2002
+++ thunder-2.5.20/fs/isofs/namei.c	Mon Jun  3 17:27:38 2002
@@ -139,20 +139,8 @@
 			dpnt = tmpname;
 		}
 
-		/*
-		 * Skip hidden or associated files unless unhide is set 
-		 */
-		match = 0;
-		if (dlen > 0 &&
-		    (!(de->flags[-sbi->s_high_sierra] & 5)
-		     || sbi->s_unhide == 'y'))
-		{
-			match = (isofs_cmp(dentry,dpnt,dlen) == 0);
-		}
-		if (match) {
-			if (bh) brelse(bh);
-			return inode_number;
-		}
+		if (bh) brelse(bh);
+		return inode_number;
 	}
 	if (bh) brelse(bh);
 	return 0;
--- linux-2.5.20/fs/isofs/dir.c	Sun Jun  2 19:44:45 2002
+++ thunder-2.5.20/fs/isofs/dir.c	Mon Jun  3 17:32:30 2002
@@ -192,16 +192,6 @@
 			continue;
 		}
 
-		/* Handle everything else.  Do name translation if there
-		   is no Rock Ridge NM field. */
-		if (sbi->s_unhide == 'n') {
-			/* Do not report hidden or associated files */
-			if (de->flags[-sbi->s_high_sierra] & 5) {
-				filp->f_pos += de_len;
-				continue;
-			}
-		}
-
 		map = 1;
 		if (sbi->s_rock) {
 			len = get_rock_ridge_filename(de, tmpname, inode);

-- 
German attitude becoming        |	Thunder from the hill at ngforever
rightaway popular:		|
       "Get outa my way,  	|	free inhabitant not directly
    for I got a mobile phone!"	|	belonging anywhere

Re: isofs unhide option: troubles with Wine

[Francois Gouget]

Replying a bit late 'cause I was on vacation at the time (and because I
have stronger feelings about this issue than Jeremy :-)


On Sat, 25 May 2002, Joseph Mathewson wrote:
[...]
> > Further, I would argue that if you accept that unhide is a
> > reasonable default for me to force into the fstab, then
> > it is a reasonable default for the kernel to have.
>
> Is this not an issue that could be put to RedHat/Mandrake/SuSE/Turbo/etc to
> include the above fstab in their standard install.  If the user is going to have
> to upgrade their kernel to get this default, they will understand fstab.  If
> they do not understand fstab, they are going to upgrade their kernel by
> upgrading their distro anyway.  So why not push for this option in the default
> fstab of popular distros?

The goal is not to tell users to upgrade their kernels. The goal is to
make the problem gradually disappear by fixing the kernel now. (when
distributions start shipping with the fixed kernel we'll have much fewer
complaints already)


Now I will argue that making 'hidden' files inaccessible is a kernel
bug.

On Windows if you use FindFirstFile + FindNextFile (equivalent to
opendir/readdir), you get all files, including hidden files. Similarly,
you can use CreateFile to open a hidden file. In other words there is no
difference between hidden and regular files a the API level.

Now, switch to Linux and try opendir+readdir. Unless you specified the
'unhide' option, hidden files are not returned. Similarly you cannot use
open on a hidden file. For all purposes and intent 'hidden' files are
inaccessible on Linux.

Now, hidden files are not something new, FAT had that since the
beginning. Yet, the FAT driver as never made hidden files inaccessible.
I'm sure there would have been riots if it had (and I missed on all the
fun). Imagine being unable to tweak bootsect.dos or boot.ini?

I also believe that ECMA 119 section 9.1.6 intends the 'Existence' bit
to be the same as the 'hidden' flag of FAT. Certainly MS uses it the
same way. ECMA says:

    If set to ZERO, shall mean that the existence of the file shall be
    made known to the user upon an inquiry by the user.
    If set to ONE, shall mean that the existence of the file need not be
    made known to the user.

Now, the way I read it, the user is the guy sitting in front of the
computer, not the 'userland' program making the API call. Thus what ECMA
says is that this bit can be used by applications like 'dir' or 'Windows
Explorer' to filter out some file entries. In any case, it is not
even mandatory to do so.
(note I agree with Andries wrt. Associated files)

So, we will certainly send a patch for this, but:
1. should it make 'unhide' the default and add a 'hide' option?
2. or should it completely ignore the 'hidden' bit?

I am very much in favor of option 2. But does anyone know of a case
where making hidden files inaccessible is desired?

(adding an ioctl to get that bit would be nice if there is none
currently but we may not go that far :-)


--
Francois Gouget         fgouget@free.fr        http://fgouget.free.fr/
                      Computers are like airconditioners
                They stop working properly if you open WINDOWS

Re: isofs unhide option: troubles with Wine

[Alan Cox]

On Mon, 2002-06-03 at 18:05, Jeremy White wrote:
> > possible rather than impossible. Question is - why was hide the default
> > and what was that decision based upon ?
> 
> I agree with Alan - this is the key question.  
> 
> I would further argue that silence in response to this question
> suggests that there was no carefully considered reason;
> presumably a good hacker just followed the spec, without considering how
> these CDs are actually used.
> 
> It further suggests to me that I should prep a patch.

Go for it. I'll give it a test in the -ac tree happily. If nobody
screams it can then go upstream.

Re: isofs unhide option: troubles with Wine

[H. Peter Anvin]

Thunder from the hill wrote:
> Hi,
> 
> On 3 Jun 2002, H. Peter Anvin wrote:
> 
>>No, I think that's a bad idea.  Make them listed, but make it possible
>>to query the attribute flags.
> 
> 
> So you suggest letting ls do the hide? Or if not, what do we call them 
> "hidden" for?
> 

I don't think it makes any sense for anything in Unix to hide them at all.

The "hidden" flag, however, matters to programs like Wine.

	-hpa

Re: isofs unhide option: troubles with Wine

[Thunder from the hill]

Hi,

On 3 Jun 2002, H. Peter Anvin wrote:
> No, I think that's a bad idea.  Make them listed, but make it possible
> to query the attribute flags.

So you suggest letting ls do the hide? Or if not, what do we call them 
"hidden" for?

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: isofs unhide option: troubles with Wine

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.44.0206031204540.3833-100000@hawkeye.luckynet.adm>
By author:    Thunder from the hill <thunder@ngforever.de>
In newsgroup: linux.dev.kernel
>
> Hi,
> 
> On 3 Jun 2002, Jeremy White wrote:
> > possible rather than impossible. Question is - why was hide the default
> > and what was that decision based upon ?
> 
> Supposedly, someone wanted it _really_ hidden. I can't currently think of 
> another sane reason, I don't know if you can and it's just these 
> headaches. However, what's the advantage in disappearing files?
> 
> I suggest making them readable, but not listed.
> 

No, I think that's a bad idea.  Make them listed, but make it possible
to query the attribute flags.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: isofs unhide option: troubles with Wine

[Thunder from the hill]

Hi,

On 3 Jun 2002, Jeremy White wrote:
> possible rather than impossible. Question is - why was hide the default
> and what was that decision based upon ?

Supposedly, someone wanted it _really_ hidden. I can't currently think of 
another sane reason, I don't know if you can and it's just these 
headaches. However, what's the advantage in disappearing files?

I suggest making them readable, but not listed.

Regards,
Thunder
-- 
ship is leaving right on time	|	Thunder from the hill at ngforever
empty harbour, wave goodbye	|
evacuation of the isle		|	free inhabitant not directly
caveman's paintings drowning	|	belonging anywhere

Re: isofs unhide option: troubles with Wine

[Jeremy White]

> possible rather than impossible. Question is - why was hide the default
> and what was that decision based upon ?

I agree with Alan - this is the key question.  

I would further argue that silence in response to this question
suggests that there was no carefully considered reason;
presumably a good hacker just followed the spec, without considering how
these CDs are actually used.

It further suggests to me that I should prep a patch.

Thoughts?  Screams of protest?  Helpful tips on to whom I
should send the patch?

Thanks,

Jer

Re: isofs unhide option: troubles with Wine

[H. Peter Anvin]

Lionel Bouton wrote:
> On Sat, May 25, 2002 at 01:31:46PM -0700, H. Peter Anvin wrote:
> 
>>[...]
>>I think we should just dump the hidden bit; if someone wants it they
>>can ioctl() for it.
>>
> 
> 
> I didn't know we could and couldn't find how from a quick look-through in
> fs/. Is the ioctl really implemented ? If so where should I look ?
> That would be good news for Wine as they would have a way to populate the
> flags member of the struct.
> 

I don't think it's there now.  We should add it, though.

	-hpa

Re: isofs unhide option: troubles with Wine

[Lionel Bouton]

On Sat, May 25, 2002 at 01:31:46PM -0700, H. Peter Anvin wrote:
> [...]
> I think we should just dump the hidden bit; if someone wants it they
> can ioctl() for it.
> 

I didn't know we could and couldn't find how from a quick look-through in
fs/. Is the ioctl really implemented ? If so where should I look ?
That would be good news for Wine as they would have a way to populate the
flags member of the struct.

LB.

Re: isofs unhide option: troubles with Wine

[Lionel Bouton]

On Fri, May 24, 2002 at 11:30:29PM -0500, Jeremy White wrote:
> Greetings,
> 
> When installing Microsoft Office with Wine, we find that some
> MS CDs have certain files marked as hidden on the CD.
> [...]
> 
> Unfortunately, I don't have a strong feeling for what the
> 'right' solution is.  I see several options:
> 
>     1.  Invert the logic of the option, make it 'hide' instead
>         of unhide, and so unhide is the default.
> 
>     2.  Make it possible to set this mount option from user
>         space (I don't like this, but it would get me around
>         the problem).
> 
>     3.  Make it so that isofs/dir.c still strips out hidden
>         files, but enable isofs/namei.c to return a hidden file that
>         is opened directly by name.
> 
> I am willing to submit a patch to implement the appropriate solution.
> 
> Comments and opinions are greatly appreciated; please copy me directly
> though, as I am not subscribed.
> 
> Thanks,
> 
> Jeremy
> 

With 3. Wine's FindFirstFile and FindNextFile wont't be able to report
hidden files and Win32 programs could rely on that instead of using
hard-coded filenames.
If I'm not mistaken these functions return all files and put file flags
in a struct. User apps are responsible of the hiding.
One could argue that Win32 programs could rely on the file flags being
reported correctly, but I find this far less probable.

If one goal is to allow Wine to implement the Win32 syscalls as correctly as
possible 3. is not an option IMHO.

Moreover I don't like the idea of files readable but not findable by common
tools, seems broken to me.

2. will lead to entries in FAQ:

Q: What does the "unhide" option mean in my /etc/fstab ?
A: Lengthy explanation on ISO9660, Windows FS versus Unix FS and so on...

1. will do what Linux already does for other FAT/NTFS contents, simply show
the info to the users even if Windows' tools hide it by default.

Personnaly I would choose 1. (I prefer short FAQs).

LB.

Re: isofs unhide option: troubles with Wine

[H. Peter Anvin]

Followup to:  <acopak$1th$1@penguin.transmeta.com>
By author:    torvalds@transmeta.com (Linus Torvalds)
In newsgroup: linux.dev.kernel
>
> In article <1022301029.2443.28.camel@jwhiteh>,
> Jeremy White  <jwhite@codeweavers.com> wrote:
> >
> >    3.  Make it so that isofs/dir.c still strips out hidden
> >        files, but enable isofs/namei.c to return a hidden file that
> >        is opened directly by name.
> 
> I think this is the right solution.
> 

I think we should just dump the hidden bit; if someone wants it they
can ioctl() for it.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: isofs unhide option: troubles with Wine

[Linus Torvalds]

In article <1022301029.2443.28.camel@jwhiteh>,
Jeremy White  <jwhite@codeweavers.com> wrote:
>
>    3.  Make it so that isofs/dir.c still strips out hidden
>        files, but enable isofs/namei.c to return a hidden file that
>        is opened directly by name.

I think this is the right solution.

		Linus

Re: isofs unhide option: troubles with Wine

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.44.0205251513280.10327-100000@sharra.ivimey.org>
By author:    Ruth Ivimey-Cook <Ruth.Ivimey-Cook@ivimey.org>
In newsgroup: linux.dev.kernel
> 
> AFAIK, Windows "hidden" files are supposed to behave much like Unix 'dot' 
> files (.login, etc), so IMO the kernel should not use the hidden bit at all. 
> Instead, it should be 'ls' et al that do this. Now, I guess this isn't 
> particularly practical without changing fileutils and many other things, so I 
> would suggest that the kernel is changed to pass on, if possible, but 
> basically ignore the 'hidden' bit.
> 

There really should be some kind of ioctl() or other syscall to
get/set the filesystem-specific attributes in cases like FAT (hidden,
system, archive) and ISO9660.  Trying to graft their meaning onto the
Unix system just doesn't make sense.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: isofs unhide option: troubles with Wine

[Alan Cox]

On Sat, 2002-05-25 at 14:49, Jeremy White wrote:
> Yes, that is what we have to do now.  So, when our product is
> installed, a user is presented with a confusing, and highly technical
> question, the gist of which is:  please give us your root password
> so we can do something you don't understand.  It's okay, trust us,
> really...<grin>

Sounds like a job for rpm triggers and install scripts.

> Further, I would argue that if you accept that unhide is a
> reasonable default for me to force into the fstab, then
> it is a reasonable default for the kernel to have.

I'd tend to agree, simply because the defaults ought to make things
possible rather than impossible. Question is - why was hide the default
and what was that decision based upon ?

Re: isofs unhide option: troubles with Wine

[Jeremy White]

> AFAIK, Windows "hidden" files are supposed to behave much like Unix 'dot' 
> files (.login, etc), so IMO the kernel should not use the hidden bit at all. 
> Instead, it should be 'ls' et al that do this. Now, I guess this isn't 
> particularly practical without changing fileutils and many other things, so I 
> would suggest that the kernel is changed to pass on, if possible, but 
> basically ignore the 'hidden' bit.

To me, this seems like the best approach.  My solution offends my
sensibilities in that we essentially 'throw away' the hidden
bit information.  However, I am sufficiently ignorant of the
filesystem such that I don't really know if this is feasible,
or if there is even a reasonable place to park the hidden bit
information.

Cheers,

Jer

Re: isofs unhide option: troubles with Wine

[Jeremy White]

> Is this not an issue that could be put to RedHat/Mandrake/SuSE/Turbo/etc to
> include the above fstab in their standard install.  If the user is going to have
> to upgrade their kernel to get this default, they will understand fstab.  If
> they do not understand fstab, they are going to upgrade their kernel by
> upgrading their distro anyway.  So why not push for this option in the default
> fstab of popular distros?

Again, if it's reasonable to persuade all the distros to change the
default settings used to mount a CDROM, then imho, it's more reasonable
to just change the kernel default.

Jer

Re: isofs unhide option: troubles with Wine

[Ruth Ivimey-Cook]

On 24 May 2002, Jeremy White wrote:

>Greetings,
>
>When installing Microsoft Office with Wine, we find that some
>MS CDs have certain files marked as hidden on the CD.

>Unfortunately, I don't have a strong feeling for what the
>'right' solution is.  I see several options:
>
>    1.  Invert the logic of the option, make it 'hide' instead
>        of unhide, and so unhide is the default.

I don't see the point of this...

>    2.  Make it possible to set this mount option from user
>        space (I don't like this, but it would get me around
>        the problem).

?? do you mean use of -oremount ?  possible, I suppose. Doesn't seem much 
better than (1) to me though.

>    3.  Make it so that isofs/dir.c still strips out hidden
>        files, but enable isofs/namei.c to return a hidden file that
>        is opened directly by name.

Yes. Do this, or something like it.

AFAIK, Windows "hidden" files are supposed to behave much like Unix 'dot' 
files (.login, etc), so IMO the kernel should not use the hidden bit at all. 
Instead, it should be 'ls' et al that do this. Now, I guess this isn't 
particularly practical without changing fileutils and many other things, so I 
would suggest that the kernel is changed to pass on, if possible, but 
basically ignore the 'hidden' bit.

Regards,

Ruth

-- 
Ruth Ivimey-Cook
Software engineer and technical writer.

Re: isofs unhide option: troubles with Wine

[Joseph Mathewson]

In message "Re: isofs unhide option:  troubles with Wine", <Jeremy White>
wrote:

> > >     1.  Invert the logic of the option, make it 'hide' instead
> > >         of unhide, and so unhide is the default.
> >
> > how about:
> >
> > /dev/hdb /cdrom iso9660 defaults,ro,unhide,user 0 2
> >
> > in your /etc/fstab. This would allow users to mount and unmount CDs.
> > It also changes the default to unhide.
>
> Yes, that is what we have to do now.  So, when our product is
> installed, a user is presented with a confusing, and highly technical
> question, the gist of which is:  please give us your root password
> so we can do something you don't understand.  It's okay, trust us,
> really...<grin>
>
> Further, I would argue that if you accept that unhide is a
> reasonable default for me to force into the fstab, then
> it is a reasonable default for the kernel to have.

Is this not an issue that could be put to RedHat/Mandrake/SuSE/Turbo/etc to
include the above fstab in their standard install.  If the user is going to have
to upgrade their kernel to get this default, they will understand fstab.  If
they do not understand fstab, they are going to upgrade their kernel by
upgrading their distro anyway.  So why not push for this option in the default
fstab of popular distros?

Joe.

Re: isofs unhide option: troubles with Wine

[Jeremy White]

> >     1.  Invert the logic of the option, make it 'hide' instead
> >         of unhide, and so unhide is the default.
> 
> how about:
> 
> /dev/hdb /cdrom iso9660 defaults,ro,unhide,user 0 2
> 
> in your /etc/fstab. This would allow users to mount and unmount CDs.
> It also changes the default to unhide.

Yes, that is what we have to do now.  So, when our product is
installed, a user is presented with a confusing, and highly technical
question, the gist of which is:  please give us your root password
so we can do something you don't understand.  It's okay, trust us,
really...<grin>

Further, I would argue that if you accept that unhide is a
reasonable default for me to force into the fstab, then
it is a reasonable default for the kernel to have.

Cheers,

Jeremy

Re: isofs unhide option: troubles with Wine

[Olaf Dietsche]

Hi Jeremy,

Jeremy White <jwhite@codeweavers.com> writes:

> Unfortunately, I don't have a strong feeling for what the
> 'right' solution is.  I see several options:
>
>     1.  Invert the logic of the option, make it 'hide' instead
>         of unhide, and so unhide is the default.

how about:

/dev/hdb /cdrom iso9660 defaults,ro,unhide,user 0 2

in your /etc/fstab. This would allow users to mount and unmount CDs.
It also changes the default to unhide.

Regards, Olaf.

isofs unhide option: troubles with Wine

[Jeremy White]

Greetings,

When installing Microsoft Office with Wine, we find that some
MS CDs have certain files marked as hidden on the CD.

With the default isofs mount options, these files are
completely inaccessible.  (Relevant code is in 
fs/isofs/namei.c, and dir.c; search for unhide).

You're forced to remount the CD with the -unhide option
to make these files visible.

Now, forgive me if I've overlooked TFM, but I did not
find any discussion of the unhide option in the archives
I could search.

Further, imho, the unhide code is incorrectly implemented
in Linux.

The use of the 'hide' bit in Windows has no good parallel in
Linux.  The current implementation treats a hidden file
as if it didn't exist at all, there is no possible way 
a user space program can see that file.  In Windows, the
file just is hidden from 'normal' programs, you can still
get to the file if you work hard enough.

Further, I hypothesize (perhaps wrongly) that the only use
of this hidden bit is on Windows CDs, and largely on MS
Office CDs, and so I think it is reasonable for me to
call for a change.  (Understand, I'm trying to help
very basic users to use MS Office; for them to have to
su to root, umount, and then mount -o unhide, is a pretty tough thing
to ask.  See the following article to see why I'm so upset about this:
    http://biz.yahoo.com/fo/020523/linux_gets_friendlier_1.html)

Unfortunately, I don't have a strong feeling for what the
'right' solution is.  I see several options:

    1.  Invert the logic of the option, make it 'hide' instead
        of unhide, and so unhide is the default.

    2.  Make it possible to set this mount option from user
        space (I don't like this, but it would get me around
        the problem).

    3.  Make it so that isofs/dir.c still strips out hidden
        files, but enable isofs/namei.c to return a hidden file that
        is opened directly by name.

I am willing to submit a patch to implement the appropriate solution.

Comments and opinions are greatly appreciated; please copy me directly
though, as I am not subscribed.

Thanks,

Jeremy