From sacadmin Tue Jun 7 08:21:30 2005 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j57FLUs0008779 for ; Tue, 7 Jun 2005 08:21:30 -0700 (PDT) Received: from [129.148.226.11] (sr1-unsh01-01.East.Sun.COM [129.148.226.11]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j57FL2Ft027734; Tue, 7 Jun 2005 11:21:04 -0400 (EDT) Message-ID: <42A5BB5E.9080100@sun.com> Date: Tue, 07 Jun 2005 11:21:02 -0400 From: Brian Utterback User-Agent: Mozilla Thunderbird 1.0.4 (X11/20050603) X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com CC: frank.hofmann@sun.com Subject: 2005/360 Document and enable visibility of hidden files in pcfs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 4013 I'm sponsoring this case for Frank Hofmann. Timer expires 06/14/2005. Requested release binding is patch. Thanks. Summary: This proposal requests, for Patch binding, * to elevate the interface status of the existing pcfs mount options "hidden"/"nohidden" from "Private" to "Unstable" commitment level. I.e. document this feature. * to change the default behaviour of pcfs so that "-o hidden" (the ability to see files on a FAT filesystem that have the 'hidden' FAT attribute bit set) becomes the default. The Problem The original submission for PSARC 1996/443 contained the pcfs- specific mount options "-o hidden" and "-o nohidden" which enabled users of the pcfs filesystem to see files that have the (non-UNIX, non-POSIX) 'hidden' FAT file attribute set. While the code that was delivered for 1996/443 had support for these options in, they had been withdrawn from the approved part of PSARC 1996/443. The reasons for why "hidden" was withdrawn were: 1. No agreement could be reached regarding the name of the mount option to "make hidden files visible". 2. No agreement could be reached regarding the (impossible) mapping of FAT attributes to the 'generic' POSIX file permission bits, and the (un)necessity for Solaris utilities to switch on/off pcfs-specific file attributes. Lacking this, support for accessing hidden files on pcfs was considered "a hack". 3. No market was seen for allowing access to hidden files. Quote from the mail archive for PSARC 1996/443: Most users can't see hidden files under DOS or Windows anyway; they have to get special tools to change them, tools that are the equivalent of fsdb. This situation has significantly changed eight years later. - It is trivial today (a switch accessible in Windows' Explorer Menus) to see hidden files on a FAT filesystem under Microsoft Windows. That's far from requiring "the equivalent of fsdb". - A mapping between filesystem-specific attributes and POSIX attributes (in full consequence: An extension of the POSIX file attribute set) has not been done. Extended file attributes are still not a POSIX standard, and the generic development in other filesystems on Solaris has made such "fs-specific attributes" into mount options or ioctls (example: ufs' handling of direct I/O). The advice given in PSARC 1996/443 therefore can be considered obsolete. - there's a market: Some Digital Camera and portable music player manufacturers (noticeably Apple's Ipod device) are using FAT filesystems and turn on the 'hidden' bit for ALL files on that device's mass storage. Which means support for reading/writing the data on such devices depends on making their contents visible. See RFE 1181439. The Proposed Solution PCFS will turn on the "hidden" mount option by default, making hidden files visible to the user. This gives the most consistent user experience by not hiding information from the user by default. Disabling the feature is still an option available to the system administrator if so desired. To do that, the system will revert to the current behaviour if the "nohidden" mount option is explicitly used. MAN PAGE CHANGES The man page for mount_pcfs(1M) will be changed to include usage instructions on the "hidden"/"nohidden" mount options. It will also be changed to state that "hidden" is the new default behaviour. The man page for pcfs(7FS) describes the current behaviour (hidden files not being shown) under "BUGS". That section will be removed. An example on how to use the "nohidden" mount option will be added to the Examples section of rmmount.conf(4). Manpage diffs are available. -- blu Remember when SOX compliant meant they were both the same color? ---------------------------------------------------------------------- Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From sacadmin Tue Jun 7 17:32:54 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.68.130] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j580Wrs0024948 for ; Tue, 7 Jun 2005 17:32:54 -0700 (PDT) Received: from heckle (vpn-129-150-26-165.SFBay.Sun.COM [129.150.26.165]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j580WQod583360; Tue, 7 Jun 2005 17:32:28 -0700 (PDT) Message-Id: <200506080032.j580WQod583360@jurassic.eng.sun.com> Date: Tue, 7 Jun 2005 17:31:53 -0700 (PDT) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs To: psarc@sac.sfbay.sun.com, brian.utterback@sun.com Cc: frank.hofmann@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 1BTxBoTi3larCiJHpFbQpA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc Status: RO Content-Length: 1224 This is the *other* PCFS case. 8^) > The Proposed Solution > > PCFS will turn on the "hidden" mount option by default, making > hidden files visible to the user. This gives the most consistent > user experience by not hiding information from the user by default. > Disabling the feature is still an option available to the system > administrator if so desired. To do that, the system will revert to > the current behaviour if the "nohidden" mount option is explicitly > used. Asserting that the most consistent user experience is contrary to the default user experience on Windows is lost on me. Could you please explain the rationale here? Also, I would believe that most PCFS mounts are done by volume manager, rather than a system administrator. I'm not sure how easy it is to change mount options for volume manager (as I make a significant effort to avoid volume manager - I'm just a ludite in this respect). Finally, even if its a good idea, its not clear to me that having hidden files suddenly not become hidden (by default) is appropriate for a patch release binding. All in all, I think the existing default value (where hidden files are indeed hidden) is the preferred implementation. - jek3 From sacadmin Tue Jun 7 17:48:44 2005 Received: from phys-bos-2.sfbay.sun.com (phys-bos-2 [129.146.14.24]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j580mis0025802 for ; Tue, 7 Jun 2005 17:48:44 -0700 (PDT) Received: from [129.146.228.101] (aja.SFBay.Sun.COM [129.146.228.101]) by bos-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2 HotFix 0.05 (built Jan 10 2005)) with ESMTP id <0IHQ00G99Q8JX020@bos-mail1.sfbay.sun.com> for psarc@sac.sfbay.sun.com; Tue, 07 Jun 2005 17:48:19 -0700 (PDT) Date: Tue, 07 Jun 2005 17:49:28 -0700 From: Artem Kachitchkine Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs In-reply-to: <200506080032.j580WQod583360@jurassic.eng.sun.com> To: "Joseph E. Kowalski III" Cc: psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM, Frank.Hofmann@Sun.COM Message-id: <42A64098.5060509@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <200506080032.j580WQod583360@jurassic.eng.sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) Status: RO Content-Length: 674 > Asserting that the most consistent user experience is contrary to the default > user experience on Windows is lost on me. Could you please explain the > rationale here? Files are being hidden on very different levels in the s/w stack. Windows: hidden by the file manager (Explorer). Can be reverted by toggling a checkbox in Preferences. It's like 'ls' vs 'ls -a'. Applications can always access hidden files. Solaris: hidden by the filesystem. Applications can't access hidden files by default. Connecting an iPod on Windows brings up an application (iTunes) that looks for the hidden directory. This won't work on Solaris with default mount options. -Artem. From sacadmin Tue Jun 7 17:57:19 2005 Received: from phys-bos-2.sfbay.sun.com (phys-bos-2 [129.146.14.24]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j580vJs0027557 for ; Tue, 7 Jun 2005 17:57:19 -0700 (PDT) Received: from [129.146.228.101] (aja.SFBay.Sun.COM [129.146.228.101]) by bos-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2 HotFix 0.05 (built Jan 10 2005)) with ESMTP id <0IHQ00GE6QMTX020@bos-mail1.sfbay.sun.com> for psarc@sac.sfbay.sun.com; Tue, 07 Jun 2005 17:56:53 -0700 (PDT) Date: Tue, 07 Jun 2005 17:58:03 -0700 From: Artem Kachitchkine Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs In-reply-to: <42A5BB5E.9080100@sun.com> To: Brian Utterback Cc: psarc@sac.sfbay.sun.com, Frank.Hofmann@Sun.COM Message-id: <42A6429B.1050205@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <42A5BB5E.9080100@sun.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050323) Status: RO Content-Length: 372 > Quote from the mail archive for PSARC 1996/443: > Most users can't see hidden files under DOS or Windows > anyway; they have to get special tools to change them, > tools that are the equivalent of fsdb. Special tools? To change - yes, to list - no. 'DIR /A' has existed in MS DOS starting from early versions, way before 1996. -Artem. From sacadmin Tue Jun 7 18:33:48 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.55] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j581Xls0028166 for ; Tue, 7 Jun 2005 18:33:48 -0700 (PDT) Received: from heckle (vpn-129-150-26-165.SFBay.Sun.COM [129.150.26.165]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j581XG6f820779; Tue, 7 Jun 2005 18:33:18 -0700 (PDT) Message-Id: <200506080133.j581XG6f820779@jurassic.eng.sun.com> Date: Tue, 7 Jun 2005 18:32:44 -0700 (PDT) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs To: Joseph.Kowalski@sun.com, artem.kachitchkin@sun.com Cc: psarc@sac.sfbay.sun.com, Brian.Utterback@sun.com, Frank.Hofmann@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: FeZdvPPKwuOgaMGLuzaJfw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc Status: RO Content-Length: 1679 > From: Artem Kachitchkine ... > > Asserting that the most consistent user experience is contrary to the default > > user experience on Windows is lost on me. Could you please explain the > > rationale here? > > Files are being hidden on very different levels in the s/w stack. > > Windows: hidden by the file manager (Explorer). Can be reverted by > toggling a checkbox in Preferences. It's like 'ls' vs 'ls -a'. > Applications can always access hidden files. > > Solaris: hidden by the filesystem. Applications can't access hidden > files by default. > > Connecting an iPod on Windows brings up an application (iTunes) that > looks for the hidden directory. This won't work on Solaris with default > mount options. I see. In one sense, the stack shouldn't matter as far as the end user experience, but doing it at the mount level eliminates per-application customization. I'm guessing there is no way to access the hidden bit from stat. If there was, I'd accept the proposal with the addition that ls (and friends, like file manager) be modified to respect the hidden bit. (Can you verify that there is no way to access this bit from userland - stat or otherwise?) This seems like a choice between two evils. I'd like to sleep on it, but I suspect you have chosen the lesser evil. That said, I'm not sure this qualifies as a fast-track since this isn't "obvious" (at least to me), but I certainly won't derail it unless I can think of something truly constructive to say in an opinion. I am going to request that the existing timer run on this case. All that does is not enable approval at the Wednesday PSARC meeting. - jek3 From sacadmin Tue Jun 7 18:39:21 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.108.31] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j581dLs0028200 for ; Tue, 7 Jun 2005 18:39:21 -0700 (PDT) Received: from heckle (vpn-129-150-26-165.SFBay.Sun.COM [129.150.26.165]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j581csJF829474; Tue, 7 Jun 2005 18:38:55 -0700 (PDT) Message-Id: <200506080138.j581csJF829474@jurassic.eng.sun.com> Date: Tue, 7 Jun 2005 18:38:21 -0700 (PDT) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs To: Brian.Utterback@sun.com, artem.kachitchkin@sun.com Cc: psarc@sac.sfbay.sun.com, Frank.Hofmann@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QN63ZD9mwBcbzE3+hpUf/Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc Status: RO Content-Length: 766 > > Quote from the mail archive for PSARC 1996/443: > > Most users can't see hidden files under DOS or Windows > > anyway; they have to get special tools to change them, > > tools that are the equivalent of fsdb. > > Special tools? To change - yes, to list - no. 'DIR /A' has existed in MS > DOS starting from early versions, way before 1996. And of course, under Windows XP (and I think all NT derivatives) these are simple check boxes brought up by the Properies menu item. On my system, the Attributes are always displayed, but I can't remember if this is the default or I customized my display (which is also an easy task under the View menu). BTW: Its quite educational to see how many attributes can be displayed. - jek3 From sacadmin Tue Jun 7 18:46:31 2005 Received: from phys-mpk-1 (phys-mpk-1 [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j581kVs0028807 for ; Tue, 7 Jun 2005 18:46:31 -0700 (PDT) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IHQ00901STWFU@mpk-mail1.sfbay.sun.com> (original mail from michael.riley@sun.com) for psarc@sac.sfbay.sun.com; Tue, 07 Jun 2005 18:46:05 -0700 (PDT) Received: from [129.150.29.181] (vpn-129-150-29-181.SFBay.Sun.COM [129.150.29.181]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IHQ00JSJSWT9A@mpk-mail1.sfbay.sun.com>; Tue, 07 Jun 2005 18:46:05 -0700 (PDT) Date: Tue, 07 Jun 2005 18:46:11 -0700 From: Mike Riley Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs In-reply-to: <200506080138.j581csJF829474@jurassic.eng.sun.com> To: "Joseph E. Kowalski III" Cc: Brian.Utterback@Sun.COM, Artem.Kachitchkin@Sun.COM, psarc@sac.sfbay.sun.com, Frank.Hofmann@Sun.COM Message-id: <42A64DE3.7030503@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) References: <200506080138.j581csJF829474@jurassic.eng.sun.com> Status: RO Content-Length: 1714 Joseph E. Kowalski III wrote: >>> Quote from the mail archive for PSARC 1996/443: >>> Most users can't see hidden files under DOS or Windows >>> anyway; they have to get special tools to change them, >>> tools that are the equivalent of fsdb. >> >>Special tools? To change - yes, to list - no. 'DIR /A' has existed in MS >>DOS starting from early versions, way before 1996. > > > And of course, under Windows XP (and I think all NT derivatives) these > are simple check boxes brought up by the Properies menu item. On my > system, the Attributes are always displayed, but I can't remember if > this is the default or I customized my display (which is also an easy > task under the View menu). > > BTW: Its quite educational to see how many attributes can be displayed. > > - jek3 You had to customize it by saying all folders should look that way. You have it in the Detailed view and under the View->Details menu item you choose which details to display. I had another question. Under DOS/Windows the System attribute acted just like Hidden. What was the behavior for pcfs with that attribute being set? I did not see it mentioned. -- Mike Riley Mail: EGO-02 o Work: (310) 464-5997 Ext.: 67190 | \ \ | Page: (800) 759-8888 + PIN 8738187 |=|====================\O/==|=| Fax: (310) 464-5997 | | o \ | | E-mail: michael.riley@Sun.COM |=|==O===============/\==|=| E-mail Page: 7026910609@cingularME.com | |\o | \ \ | Work Home Page: http://lasc.west/~mikeri | / ) ( ) | From sacadmin Tue Jun 7 18:50:42 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.228.50] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j581ogs0028852 for ; Tue, 7 Jun 2005 18:50:42 -0700 (PDT) Received: from heckle (vpn-129-150-26-165.SFBay.Sun.COM [129.150.26.165]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j581oEXR870629; Tue, 7 Jun 2005 18:50:16 -0700 (PDT) Message-Id: <200506080150.j581oEXR870629@jurassic.eng.sun.com> Date: Tue, 7 Jun 2005 18:49:42 -0700 (PDT) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs To: Joseph.Kowalski@sun.com, michael.riley@sun.com Cc: Brian.Utterback@sun.com, artem.kachitchkin@sun.com, psarc@sac.sfbay.sun.com, Frank.Hofmann@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: TXrlyRElNEg3/op6vWxnkA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc Status: RO Content-Length: 574 > You had to customize it by saying all folders should look that way. You > have it in the Detailed view and under the View->Details menu item you > choose which details to display. I thought that may have been the case. Either way, its easy to make them visible. > I had another question. Under DOS/Windows the System attribute acted just > like Hidden. What was the behavior for pcfs with that attribute being set? > I did not see it mentioned. Note that the system attribute is not something easily modified (as are the read-only and hidden bits). - jek3 From sacadmin Wed Jun 8 03:56:02 2005 Received: from phys-mayi-1 (phys-mayi-1-ipmp1.Germany.Sun.COM [129.157.128.114]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58Au1s0025474 for ; Wed, 8 Jun 2005 03:56:02 -0700 (PDT) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IHR00H01IBUBT@mayi-mail1.germany.sun.com> (original mail from frankho@mayi-mail1.germany.sun.com) for psarc@sac.sfbay.sun.com; Wed, 08 Jun 2005 12:55:35 +0200 (MEST) Received: from estale (estale.UK.Sun.COM [129.156.173.199]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with SMTP id <0IHR00CA5ICNB9@mayi-mail1.germany.sun.com>; Wed, 08 Jun 2005 12:55:35 +0200 (MEST) Date: Wed, 08 Jun 2005 11:55:35 +0100 (BST) From: Frank Hofmann - Solaris Sustaining Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs To: Brian.Utterback@Sun.COM, Artem.Kachitchkin@Sun.COM Cc: psarc@sac.sfbay.sun.com, Frank.Hofmann@Sun.COM Reply-to: Frank Hofmann - Solaris Sustaining Message-id: <0IHR00CA9ICNB9@mayi-mail1.germany.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_16 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-MD5: JrWLDV9SxIdiGgBIva+yYA== Status: RO Content-Length: 1764 > > Quote from the mail archive for PSARC 1996/443: > > Most users can't see hidden files under DOS or Windows > > anyway; they have to get special tools to change them, > > tools that are the equivalent of fsdb. > > Special tools? To change - yes, to list - no. 'DIR /A' has existed in MS > DOS starting from early versions, way before 1996. > > -Artem. Which proves the point - even in 1996, the above assertion then brought up by the committee regarding why PSARC 1996/443 was NOT to be approved wrt. to hidden files handling was not completely correct (no "special" need to see them - only to change, which never was the objective). Note "see" vs. "change" in the above. In 1996, there was the perception that "want to see" implies "want to change". Which I don't agree with. I'm not proposing to introduce interfaces to allow modifying or even detecting the non-POSIX file attributes (hidden/system) of PCFS. Whether users see those files is under the control of the system administrator (denying it by specifing "-o nohidden" explicitly in the vold/rmmount config files). Which is not the same as on Microsoft Windows, where it's under explicit control by the user, as shown, but the admin/role-controlled model is more in line with UNIX semantics (if the admin decides to hide this, it's hidden and will stay hidden - otherwise you may as well see it). I mean: There's no point in having a "hidden" file if it's trivial anyway to see it ("dir /ah" on dos/windows, resp. that little checkbox in "order options" on windows explorer). The right to hide is a privilege - therefore, show by default, and let the role that determines what is to be mounted where decide on what of that will be shown and what not. FrankH. From sacadmin Wed Jun 8 04:37:51 2005 Received: from phys-mayi-1 (phys-mayi-1-ipmp1.Germany.Sun.COM [129.157.128.114]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58Bbos0025783 for ; Wed, 8 Jun 2005 04:37:51 -0700 (PDT) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IHR00F01KACLH@mayi-mail1.germany.sun.com> (original mail from frankho@mayi-mail1.germany.sun.com) for psarc@sac.sfbay.sun.com; Wed, 08 Jun 2005 13:37:25 +0200 (MEST) Received: from estale (estale.UK.Sun.COM [129.156.173.199]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with SMTP id <0IHR00CQ2KACB9@mayi-mail1.germany.sun.com>; Wed, 08 Jun 2005 13:37:25 +0200 (MEST) Date: Wed, 08 Jun 2005 12:37:24 +0100 (BST) From: Frank Hofmann - Solaris Sustaining Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs To: Brian.Utterback@Sun.COM, Artem.Kachitchkin@Sun.COM, Frank.Hofmann@Sun.COM Cc: psarc@sac.sfbay.sun.com, Frank.Hofmann@Sun.COM Reply-to: Frank Hofmann - Solaris Sustaining Message-id: <0IHR00CQ8KACB9@mayi-mail1.germany.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_16 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-MD5: dQIR04VYXhvKWeEYGV1mhw== Status: RO Content-Length: 845 > > > Quote from the mail archive for PSARC 1996/443: > > > Most users can't see hidden files under DOS or Windows > > > anyway; they have to get special tools to change them, > > > tools that are the equivalent of fsdb. > > > > Special tools? To change - yes, to list - no. 'DIR /A' has existed in MS > > DOS starting from early versions, way before 1996. Sorry to follow up myself on this. I've digged in my rusty Windows/DOS knowledge and now have to say that the both assertions (users not able to see hidden files or access/modify the hidden attribute bit) have ALWAYS been WRONG on DOS/Windows: - "dir /ah" shows hidden files - "attrib -/+h" allows to remove/add the hidden file attribute So, no special tools for either. Which is true for MSDOS at least as far back as MSDOS 5.0 (1990 ?). FrankH. From sacadmin Wed Jun 8 04:46:23 2005 Received: from phys-mayi-1 (phys-mayi-1-ipmp1.Germany.Sun.COM [129.157.128.114]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58BkMs0026516 for ; Wed, 8 Jun 2005 04:46:23 -0700 (PDT) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IHR00I01KIU2D@mayi-mail1.germany.sun.com> (original mail from frankho@mayi-mail1.germany.sun.com) for psarc@sac.sfbay.sun.com; Wed, 08 Jun 2005 13:45:57 +0200 (MEST) Received: from estale (estale.UK.Sun.COM [129.156.173.199]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with SMTP id <0IHR00CF7KOKB9@mayi-mail1.germany.sun.com>; Wed, 08 Jun 2005 13:45:57 +0200 (MEST) Date: Wed, 08 Jun 2005 12:45:56 +0100 (BST) From: Frank Hofmann - Solaris Sustaining Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs To: Joseph.Kowalski@Sun.COM, Artem.Kachitchkin@Sun.COM, Joseph.Kowalski@eng.sun.com Cc: psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM, Frank.Hofmann@Sun.COM Reply-to: Frank Hofmann - Solaris Sustaining Message-id: <0IHR00CFAKOKB9@mayi-mail1.germany.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_16 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-MD5: WR6hZktddCc4PAMoTCQchQ== Status: RO Content-Length: 5218 From: "Joseph E. Kowalski III" > > > From: Artem Kachitchkine > ... > > > Asserting that the most consistent user experience is contrary to the > default > > > user experience on Windows is lost on me. Could you please explain the > > > rationale here? As I said in my other email, it's about "the right to hide". On Windows, where everybody can request seeing "hidden" files, they aren't really hidden - access to them is just obfuscated. There's no way on Windows for the admin to state "you may not see these files under any circumstances". Which IMHO isn't how UNIX is supposed to work, we don't need to copy bad things from Windows just because Windows does bad things. If the Solaris admin says "I don't want you to see these files" then you're not going to see them - point. If the admin doesn't care, then why should we introduce an obfuscated way of accessing these ? > > > > Files are being hidden on very different levels in the s/w stack. > > > > Windows: hidden by the file manager (Explorer). Can be reverted by > > toggling a checkbox in Preferences. It's like 'ls' vs 'ls -a'. > > Applications can always access hidden files. yes, they're no different from ".xxxxx" files on UNIX - you need to ask politely to see them, but once you do they're just files. The FAT filesystem doesn't allow for filenames to start with ".", and has traditionally had the hidden attribute instead of this. Btw, conceptually I think that the "explorer checkbox" is more like the proposed Solaris mount option. The equivalent of "ls -a" on DOS would be the "dir /ah". A proposal "ls -a check for filesystem-specific hidden attributes instead of looking for .xxx filenames" is surely possible but this transcends the scope of this case. > > > > Solaris: hidden by the filesystem. Applications can't access hidden > > files by default. Yes. Given that on PCFS, "visibility" means "accessibility" (there are no ownership attributes on PCFS), hidden files on PCFS kind of fill the "space reserved for root" need. DOS/Windows don't enforce such roles (and therefore the "experienced user", i.e. who knows the file manager checkbox, "qualifies" for access), but UNIX does - which is, in my eyes, the reason why the control about who sees what should be a mount option. > > > > Connecting an iPod on Windows brings up an application (iTunes) that > > looks for the hidden directory. This won't work on Solaris with default > > mount options. > > I see. In one sense, the stack shouldn't matter as far as the > end user experience, but doing it at the mount level eliminates > per-application customization. Yes. But the only thing per-application customization does there is to complicate the application. On Windows, everybody who asks for it may see hidden files. I.e. "hidden" there really means "to be accessed in an obfuscated way". I don't want to copy these semantics. Why deliberately obfuscate ? Besides, the UNIX handling of ".xxx" isn't completely consistent either. File "open/save" dialogues usually show such files/directories, while "ls" only does via "-a" and the graphical file managers (may) want a switch ticked off somewhere. readdir(3C) syscalls surely show them all. > > I'm guessing there is no way to access the hidden bit from stat. If there > was, I'd accept the proposal with the addition that ls (and friends, like > file manager) be modified to respect the hidden bit. (Can you verify that > there is no way to access this bit from userland - stat or otherwise?) There is none. stat() doesn't report non-POSIX attributes, and PCFS doesn't implement other interfaces like ACL or ioctl that one may think of as being the way to access such filesystem-specific metadata. See above. This is essentially the same reason why PSARC 1996/443 was rejected wrt. to hidden file handling - because it was perceived then that "want to see" implies "want to change", AND it was perceived that the nonexisting interface to non-POSIX attributes would eventually be created (as a POSIX extension). That hasn't happened. I hope I made it clear enough that "want to see" does NOT imply "want to change". There are good reasons today why "want to see" is justified. "Want to change" is not something I propose introducing by this case. The hidden/system attributes will not be modifyable via PCFS. > > This seems like a choice between two evils. I'd like to sleep on it, but > I suspect you have chosen the lesser evil. Yes, that's the intention. Although I argue that "evil" is in this case in the eye of the beholder, which is why I say that the decision about it will be given to whoever has the priviledge to make a PCFS filesystem accessible in the first place - i.e. to the one who controls "mount". > > That said, I'm not sure this qualifies as a fast-track since this isn't > "obvious" (at least to me), but I certainly won't derail it unless I can > think of something truly constructive to say in an opinion. > > I am going to request that the existing timer run on this case. All that > does is not enable approval at the Wednesday PSARC meeting. Thanks, I'm perfectly ok with that. > > - jek3 > FrankH. From sacadmin Wed Jun 8 05:02:06 2005 Received: from sunnl.Holland.Sun.COM (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58C25s0028206 for ; Wed, 8 Jun 2005 05:02:06 -0700 (PDT) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.Holland.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id j58C1YGg003961; Wed, 8 Jun 2005 14:01:34 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id j58C1XDk023811; Wed, 8 Jun 2005 14:01:33 +0200 (MEST) Message-Id: <200506081201.j58C1XDk023811@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Frank Hofmann - Solaris Sustaining cc: Joseph.Kowalski@Sun.COM, Artem.Kachitchkin@Sun.COM, Joseph.Kowalski@eng.sun.com, psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM, Frank.Hofmann@Sun.COM Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs In-Reply-To: <0IHR00CFAKOKB9@mayi-mail1.germany.sun.com> References: <0IHR00CFAKOKB9@mayi-mail1.germany.sun.com> Date: Wed, 08 Jun 2005 14:01:33 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 2336 >As I said in my other email, it's about "the right to hide". >On Windows, where everybody can request seeing "hidden" files, >they aren't really hidden - access to them is just obfuscated. > >There's no way on Windows for the admin to state "you may not see >these files under any circumstances". Which IMHO isn't how UNIX is >supposed to work, we don't need to copy bad things from Windows >just because Windows does bad things. > >If the Solaris admin says "I don't want you to see these files" >then you're not going to see them - point. If the admin doesn't >care, then why should we introduce an obfuscated way of accessing >these ? Well, the other option would then be to prepend the filenames of "hidden" files with a "." and vice versa. So: creating a file ".foo" -> create a hidden file "foo" rename .foo foo -> remove the hidden attribute Since hidden files are not really hidden, accessing ".foo" and "foo" should probably both work (in case of referencing files from within files on the pcfs filesystem, assuming the typical import to Solaris direction). Strange? Maybe. But at least it makes the tools all work. While PSARC is at it, can PSARC please reconsider PSARC/1996/443: Two semantics for case folding were proposed. The project team originally proposed an implementation which would fold case only when case information could have been lost; DOS 8.3 upper case only names on the media. This was proposed as the default. The other translation semantic was to always fold case. Continuing to have case folding being the default in a now case sensitive world was deemed undesir- able. The major use of pcfs is believed to be "sneaker net" file transfer between Solaris and Microsoft systems. To translate names would only serve to confuse and surprise customers. The selective translation mechanism originally proposed by the project team has the positive attribute of translating the minimum number of entries but has the nega- tive attributes of being difficult to characterize to users. Neither this translation algorithm nor a default of foldcase follow the "principle of least surprise". Clearly the project team was right and PSARC was wrong. We want case like Windows presents it. Casper From sacadmin Wed Jun 8 05:10:07 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58CA6s0028275 for ; Wed, 8 Jun 2005 05:10:07 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j58C9egr007841; Wed, 8 Jun 2005 08:09:40 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j58C9eSw007838; Wed, 8 Jun 2005 08:09:40 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17062.57348.311982.17818@gargle.gargle.HOWL> Date: Wed, 8 Jun 2005 08:09:40 -0400 From: James Carlson To: Frank Hofmann - Solaris Sustaining Cc: Artem.Kachitchkin@Sun.COM, psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs In-Reply-To: Frank Hofmann - Solaris Sustaining's message of 8 June 2005 12:45:56 References: <0IHR00CFAKOKB9@mayi-mail1.germany.sun.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 972 Frank Hofmann - Solaris Sustaining writes: > yes, they're no different from ".xxxxx" files on UNIX - you need to > ask politely to see them, but once you do they're just files. > The FAT filesystem doesn't allow for filenames to start with ".", and > has traditionally had the hidden attribute instead of this. Exactly. In fact, in the pcfs implementation I did on AIX, I mapped the name from "8.3" to ".8.3" when the hidden bit was set. (Clearly, not the right thing to do, but at least kept the spirit of the bit.) They're also like A0 files on CMS. ;-} I agree that hiding them by mount option is just the wrong thing to do because it's the wrong level of control. I'd even support ripping out the option itself if you wanted to do that. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Jun 8 05:22:47 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58CMks0028467 for ; Wed, 8 Jun 2005 05:22:47 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j58CMKKY007877; Wed, 8 Jun 2005 08:22:20 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j58CMKwB007874; Wed, 8 Jun 2005 08:22:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17062.58108.625753.879848@gargle.gargle.HOWL> Date: Wed, 8 Jun 2005 08:22:20 -0400 From: James Carlson To: Casper.Dik@Sun.COM Cc: Frank Hofmann - Solaris Sustaining , Artem.Kachitchkin@Sun.COM, psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs In-Reply-To: Casper.Dik@Sun.COM's message of 8 June 2005 14:01:33 References: <0IHR00CFAKOKB9@mayi-mail1.germany.sun.com> <200506081201.j58C1XDk023811@vaticaan.Holland.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 3144 Casper.Dik@Sun.COM writes: > Well, the other option would then be to prepend the filenames of > "hidden" files with a "." and vice versa. > > So: > > creating a file ".foo" > -> create a hidden file "foo" > rename .foo foo > -> remove the hidden attribute > > > Since hidden files are not really hidden, accessing ".foo" and > "foo" should probably both work (in case of referencing files > from within files on the pcfs filesystem, assuming the typical > import to Solaris direction). > > Strange? Maybe. But at least it makes the tools all work. Funny you should mention it ... I just dug up the old (pretty hackish) code I wrote for AIX. Here's an excerpt from the man page. (I wouldn't recommend anything like this today, as it'd be plainly incompatible with Windows long file names.) TRANSLATIONS The following translations are currently performed by the driver: Volume Label The MS-DOS volume label, if any, is presented as a symbolic link named LABEL in the top level directory. For example: ls -l /mnt/fd0/LABEL lrwxrwxrwx 1 root prog 9 Oct 17 1997 /mnt/fd0/LABEL@ -> os-2-warp This shows a volume label of "os-2-warp". The label itself is subject to the standard name conversion conventions, though the name "LABEL" is not. The volume label may be manipulated in the usual way by "rm LABEL" or "ln -s ... LABEL" to remove or set the label value. Note that neither symbolic nor hard links with any other name or in any subdirectory are not permitted, since MS-DOS does not have those features. Hidden The MS-DOS "hidden" flag is translated into a leading dot (.) in the file name. Such files are ordinarily omitted from ls(1) output. Files may be made hidden by renaming (mv(1)) to add a leading dot. System The MS-DOS "system" flag causes the lower 6 bits of the file mode bits to be cleared. The system flag can be set on a file by using: chmod go-rwx myfile Setting any of the lower 6 bits causes the system flag to be cleared. Read-Only The MS-DOS "read-only" flag is represented by turning off the write permission bits for all users in the file mode. The "read-only" flag can be set on a file by using: chmod -w myfile BUGS The MS-DOS "archive" bit is currently not translated into a Unix attribute. It is set any time a file is written and is never cleared. Both symbolic and hard links are unavailable (except as mentioned above for the volume label) since MS-DOS does not support these. It is not possible to distinguish among files with and without the MS-DOS "read-only" attribute when the entire file system is mounted read-only or has the write protection tab set. A file with a blank name (three letter extension only) is indistinguishable from a file with the MS-DOS "hidden" attribute and a one- to three-letter name. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Jun 8 05:25:11 2005 Received: from sunnl.Holland.Sun.COM (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58CPAs0028487 for ; Wed, 8 Jun 2005 05:25:10 -0700 (PDT) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.Holland.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id j58COdGg015917; Wed, 8 Jun 2005 14:24:39 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id j58COdDk010136; Wed, 8 Jun 2005 14:24:39 +0200 (MEST) Message-Id: <200506081224.j58COdDk010136@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: James Carlson cc: Frank Hofmann - Solaris Sustaining , Artem.Kachitchkin@Sun.COM, psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs In-Reply-To: <17062.58108.625753.879848@gargle.gargle.HOWL> References: <0IHR00CFAKOKB9@mayi-mail1.germany.sun.com> <200506081201.j58C1XDk023811@vaticaan.Holland.Sun.COM> <17062.58108.625753.879848@gargle.gargle.HOWL> Date: Wed, 08 Jun 2005 14:24:39 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 312 > A file with a blank name (three letter extension only) is > indistinguishable from a file with the MS-DOS "hidden" attribute and > a one- to three-letter name. Are such names actually valid? And can "extended names" start with a "."? I agree it's hackish and probably has many ill side effects. Casper From sacadmin Wed Jun 8 05:38:53 2005 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58Ccrs0028675 for ; Wed, 8 Jun 2005 05:38:53 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j58CcRwJ007927; Wed, 8 Jun 2005 08:38:27 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j58CcR4v007924; Wed, 8 Jun 2005 08:38:27 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17062.59075.137692.671271@gargle.gargle.HOWL> Date: Wed, 8 Jun 2005 08:38:27 -0400 From: James Carlson To: Casper.Dik@Sun.COM Cc: Frank Hofmann - Solaris Sustaining , Artem.Kachitchkin@Sun.COM, psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs In-Reply-To: Casper.Dik@Sun.COM's message of 8 June 2005 14:24:39 References: <0IHR00CFAKOKB9@mayi-mail1.germany.sun.com> <200506081201.j58C1XDk023811@vaticaan.Holland.Sun.COM> <17062.58108.625753.879848@gargle.gargle.HOWL> <200506081224.j58COdDk010136@vaticaan.Holland.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1018 Casper.Dik@Sun.COM writes: > > > A file with a blank name (three letter extension only) is > > indistinguishable from a file with the MS-DOS "hidden" attribute and > > a one- to three-letter name. > > Are such names actually valid? It's one of the things I ran into while testing ... about 7 years ago. Dunno if it's "valid," but I felt I needed to have a reasonable translation for every possible combination of bits I could find on the disk, and the string " ABC" is possible. Giving up and returning EINVAL or logging an error seemed like the wrong answer, when it means that the user just loses his data because I'm being priggish. > And can "extended names" start with a "."? I agree it's hackish and > probably has many ill side effects. As far as I can tell, they can. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Jun 8 05:40:13 2005 Received: from phys-mayi-1 (phys-mayi-1-ipmp1.Germany.Sun.COM [129.157.128.114]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58CeDs0029251 for ; Wed, 8 Jun 2005 05:40:13 -0700 (PDT) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IHR00101N0GGR@mayi-mail1.germany.sun.com> (original mail from frankho@mayi-mail1.germany.sun.com) for psarc@sac.sfbay.sun.com; Wed, 08 Jun 2005 14:39:47 +0200 (MEST) Received: from estale (estale.UK.Sun.COM [129.156.173.199]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with SMTP id <0IHR0056JN6A76@mayi-mail1.germany.sun.com>; Wed, 08 Jun 2005 14:39:46 +0200 (MEST) Date: Wed, 08 Jun 2005 13:39:46 +0100 (BST) From: Frank Hofmann - Solaris Sustaining Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs To: James.D.Carlson@Sun.COM, Casper.Dik@Sun.COM Cc: Frank.Hofmann@Sun.COM, Artem.Kachitchkin@Sun.COM, psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM Reply-to: Frank Hofmann - Solaris Sustaining Message-id: <0IHR0056MN6A76@mayi-mail1.germany.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_16 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-MD5: bop+YTavA0PC5SDWG5ssjg== Status: RO Content-Length: 1152 > > A file with a blank name (three letter extension only) is > > indistinguishable from a file with the MS-DOS "hidden" attribute and > > a one- to three-letter name. > > Are such names actually valid? They are not. As per FAT specification again: "The DIR_Name field is actually broken into two parts: the 8-character main part of the name, and the 3-character extension. These two parts are trailing space padded with bytes of 0x20. DIR_Name[0] may not equal 0x20. There is an implied . character between the main part of the name and the extension part of the name that is not present in DIR_Name. Lower case characters are not allowed in DIR_Name (what these characters are is country specific)." page 24. > > And can "extended names" start with a "."? I agree it's hackish and > probably has many ill side effects. If you mean "using OEM codepages" by "extended [ characters ]" as the FAT spec says, then clearly no as the above applies. If you mean "long filenames", then yes: "Leading and embedded periods are allowed in a name and are stored in the long name. Trailing periods are ignored." page 29. FrankH. From sacadmin Wed Jun 8 05:52:35 2005 Received: from phys-mayi-1 (phys-mayi-1-ipmp1.Germany.Sun.COM [129.157.128.114]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58CqYs0029368 for ; Wed, 8 Jun 2005 05:52:34 -0700 (PDT) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IHR00A01NONOI@mayi-mail1.germany.sun.com> (original mail from frankho@mayi-mail1.germany.sun.com) for psarc@sac.sfbay.sun.com; Wed, 08 Jun 2005 14:52:08 +0200 (MEST) Received: from estale (estale.UK.Sun.COM [129.156.173.199]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with SMTP id <0IHR0053MNQT76@mayi-mail1.germany.sun.com>; Wed, 08 Jun 2005 14:52:06 +0200 (MEST) Date: Wed, 08 Jun 2005 13:52:05 +0100 (BST) From: Frank Hofmann - Solaris Sustaining Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs To: psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM, Joseph.Kowalski@eng.sun.com Cc: Frank.Hofmann@Sun.COM Reply-to: Frank Hofmann - Solaris Sustaining Message-id: <0IHR0053PNQT76@mayi-mail1.germany.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_16 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-MD5: mXSbA2aTGz33VIoAksf+kw== Status: RO Content-Length: 1786 [ ... ] > This is the *other* PCFS case. 8^) > > > The Proposed Solution > > > > PCFS will turn on the "hidden" mount option by default, making > > hidden files visible to the user. This gives the most consistent > > user experience by not hiding information from the user by default. > > Disabling the feature is still an option available to the system > > administrator if so desired. To do that, the system will revert to > > the current behaviour if the "nohidden" mount option is explicitly > > used. > > Asserting that the most consistent user experience is contrary to the default > user experience on Windows is lost on me. Could you please explain the > rationale here? See Artem's reply, and my followups on that. And what the "default" experience on Windows is is debatable, see bottom. > > Also, I would believe that most PCFS mounts are done by volume manager, > rather than a system administrator. I'm not sure how easy it is to change > mount options for volume manager (as I make a significant effort to avoid > volume manager - I'm just a ludite in this respect). It's trivial, from the suggested manpage change to rmmount.conf(4): mount * pcfs -o nohidden The nohidden mount option will be passed when a pcfs file system is mounted on any media type, preventing users from accessing files on the medium for which the hidden attribute is set. i.e. no different from e.g. making the mount readonly. > > Finally, even if its a good idea, its not clear to me that having hidden > files suddenly not become hidden (by default) is appropriate for a patch > release binding. > > All in all, I think the existing default value (where hidden files are > indeed hidden) is the preferred implementation. From the "default user experience" point of view I don't agree with Status: RO this. Take the example of the iPod - you plug that into your Windows machine and iTunes pops up showing you all those "hidden" files. The same will happen on some Digital cameras that "hide" the files - the camera-specific app will pop up and make them accessible. By default. Yes, it's a special application that gives you access but you have this access by default. This is why I propose "make accessible by default". Because that's the user experience on Windows - not in all cases but in many. FrankH. From sacadmin Wed Jun 8 06:20:47 2005 Received: from phys-mayi-1 (phys-mayi-1-ipmp1.Germany.Sun.COM [129.157.128.114]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58DKks0001140 for ; Wed, 8 Jun 2005 06:20:47 -0700 (PDT) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IHR00701P0A8F@mayi-mail1.germany.sun.com> (original mail from frankho@mayi-mail1.germany.sun.com) for psarc@sac.sfbay.sun.com; Wed, 08 Jun 2005 15:20:21 +0200 (MEST) Received: from estale (estale.UK.Sun.COM [129.156.173.199]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with SMTP id <0IHR005LXP1W76@mayi-mail1.germany.sun.com>; Wed, 08 Jun 2005 15:20:20 +0200 (MEST) Date: Wed, 08 Jun 2005 14:20:20 +0100 (BST) From: Frank Hofmann - Solaris Sustaining Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs To: Casper.Dik@Sun.COM Cc: Joseph.Kowalski@Sun.COM, Artem.Kachitchkin@Sun.COM, Joseph.Kowalski@eng.sun.com, psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM, Frank.Hofmann@Sun.COM Reply-to: Frank Hofmann - Solaris Sustaining Message-id: <0IHR005LYP1W76@mayi-mail1.germany.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_16 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-MD5: mGFvwPbD9nuVa+n3yJQYAA== Status: RO Content-Length: 1838 > Well, the other option would then be to prepend the filenames of > "hidden" files with a "." and vice versa. > > So: > > creating a file ".foo" > -> create a hidden file "foo" > rename .foo foo > -> remove the hidden attribute > > > Since hidden files are not really hidden, accessing ".foo" and > "foo" should probably both work (in case of referencing files > from within files on the pcfs filesystem, assuming the typical > import to Solaris direction). > > Strange? Maybe. But at least it makes the tools all work. So we seem to have passed the "shall we do it ?" stage (yes) towards the "how do we do it" stage. Good. The option "use a mount option" has the following advantages: 1. We have it. It's undocumented but there, and people (may) have found out about it. 2. It allows the UNIX-style "let root control this" approach. 3. It's almost zero effort wrt. to the codechanges required. 4. It keeps the filenames the same as on DOS/Windows The option "translate 'DOS hidden' to 'UNIX-style .xxx'" has the following advantages: 1. It preserves the "hidden files aren't really hidden" semantics 2. It preserves the UNIX "what files are hidden" semantics 3. It allows: - by the very fact that a filename starts '.xxx', to detect the presence of "hiddenness" - via rename(3C), an existing, simple mechanism to actually modify the attribute. all without requiring to introduce pcfs-specific interfaces. Another option would be to do what e.g. FreeBSD does and not treat hidden/system files in any specific way. I.e. make them accessible just like all other files on the medium. Get rid of the mount option. My lazy half opts for the first, but my rational one doesn't have a particular preference - except to satisfy the boundary condition that making these files accessible is a *must*. FrankH. From sacadmin Wed Jun 8 06:27:40 2005 Received: from phys-mpk-1 (phys-mpk-1 [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58DRes0001189 for ; Wed, 8 Jun 2005 06:27:40 -0700 (PDT) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IHR00I01ORCSD@mpk-mail1.sfbay.sun.com> (original mail from Lawrence.Lee@sun.com) for psarc@sac.sfbay.sun.com; Wed, 08 Jun 2005 06:27:15 -0700 (PDT) Received: from [192.9.61.208] (punchin-lclee.SFBay.Sun.COM [192.9.61.208]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IHR00G1TPDDFE@mpk-mail1.sfbay.sun.com>; Wed, 08 Jun 2005 06:27:14 -0700 (PDT) Date: Wed, 08 Jun 2005 06:31:20 -0700 From: Larry Lee Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs In-reply-to: <0IHR005LYP1W76@mayi-mail1.germany.sun.com> To: Frank Hofmann - Solaris Sustaining Cc: Casper.Dik@Sun.COM, Joseph.Kowalski@Sun.COM, Artem.Kachitchkin@Sun.COM, psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM, Frank.Hofmann@Sun.COM Message-id: <42A6F328.2090006@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 References: <0IHR005LYP1W76@mayi-mail1.germany.sun.com> Status: RO Content-Length: 644 Frank Hofmann - Solaris Sustaining wrote: >The option "translate 'DOS hidden' to 'UNIX-style .xxx'" has the >following advantages: > >1. It preserves the "hidden files aren't really hidden" semantics >2. It preserves the UNIX "what files are hidden" semantics >3. It allows: > - by the very fact that a filename starts '.xxx', to detect > the presence of "hiddenness" > - via rename(3C), an existing, simple mechanism to actually > modify the attribute. > all without requiring to introduce pcfs-specific interfaces. > > > Don't we also support long filenames on pcfs? Don't long filenames allow a leading period? > >FrankH. > > > From sacadmin Wed Jun 8 06:37:29 2005 Received: from phys-mayi-1 (phys-mayi-1-ipmp1.Germany.Sun.COM [129.157.128.114]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58DbSs0001262 for ; Wed, 8 Jun 2005 06:37:28 -0700 (PDT) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IHR00E01PNQPR@mayi-mail1.germany.sun.com> (original mail from frankho@mayi-mail1.germany.sun.com) for psarc@sac.sfbay.sun.com; Wed, 08 Jun 2005 15:37:02 +0200 (MEST) Received: from estale (estale.UK.Sun.COM [129.156.173.199]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with SMTP id <0IHR005DYPTP76@mayi-mail1.germany.sun.com>; Wed, 08 Jun 2005 15:37:02 +0200 (MEST) Date: Wed, 08 Jun 2005 14:37:01 +0100 (BST) From: Frank Hofmann - Solaris Sustaining Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs To: Frank.Hofmann@Sun.COM, Lawrence.Lee@Sun.COM Cc: Casper.Dik@Sun.COM, Joseph.Kowalski@Sun.COM, Artem.Kachitchkin@Sun.COM, psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM, Frank.Hofmann@Sun.COM Reply-to: Frank Hofmann - Solaris Sustaining Message-id: <0IHR005DZPTP76@mayi-mail1.germany.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_16 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-MD5: otC43oQbEupGx0kr9mJ3Nw== Status: RO Content-Length: 674 > >The option "translate 'DOS hidden' to 'UNIX-style .xxx'" has the > >following advantages: > > > >1. It preserves the "hidden files aren't really hidden" semantics > >2. It preserves the UNIX "what files are hidden" semantics > >3. It allows: > > - by the very fact that a filename starts '.xxx', to detect > > the presence of "hiddenness" > > - via rename(3C), an existing, simple mechanism to actually > > modify the attribute. > > all without requiring to introduce pcfs-specific interfaces. > > > Don't we also support long filenames on pcfs? > Don't long filenames allow a leading period? Right on both - which makes the above somewhat ambiguous... FrankH. From sacadmin Wed Jun 8 09:15:22 2005 Received: from jurassic.eng.sun.com (jurassic [129.146.17.55] (may be forged)) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58GFIs0010841 for ; Wed, 8 Jun 2005 09:15:22 -0700 (PDT) Received: from heckle (vpn-129-150-26-165.SFBay.Sun.COM [129.150.26.165]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with SMTP id j58GEloI807496; Wed, 8 Jun 2005 09:14:50 -0700 (PDT) Message-Id: <200506081614.j58GEloI807496@jurassic.eng.sun.com> Date: Wed, 8 Jun 2005 09:14:15 -0700 (PDT) From: "Joseph E. Kowalski III" Reply-To: "Joseph E. Kowalski III" Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs To: frankho@mayi-mail1.germany.sun.com, Casper.Dik@Sun.COM Cc: Joseph.Kowalski@Sun.COM, Artem.Kachitchkin@Sun.COM, Joseph.Kowalski@eng.sun.com, psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM, Frank.Hofmann@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /JgeA9ewsmuq7TyyQu7OAA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6 SunOS 5.10 sun4u sparc Status: RO Content-Length: 2485 > From: Casper.Dik@Sun.COM ... > Well, the other option would then be to prepend the filenames of > "hidden" files with a "." and vice versa. > > So: > > creating a file ".foo" > -> create a hidden file "foo" > rename .foo foo > -> remove the hidden attribute > > > Since hidden files are not really hidden, accessing ".foo" and > "foo" should probably both work (in case of referencing files > from within files on the pcfs filesystem, assuming the typical > import to Solaris direction). > > Strange? Maybe. But at least it makes the tools all work. Yea, I thought about this, but refrained from suggesting it. If PCFS was a new thing, I think something like this would be the right thing to do. However, at this point in time it seems like too much of an incompatable change to consider. > While PSARC is at it, can PSARC please reconsider PSARC/1996/443: > > Two semantics for case folding were proposed. The project > team originally proposed an implementation which would fold > case only when case information could have been lost; DOS > 8.3 upper case only names on the media. This was proposed > as the default. The other translation semantic was to > always fold case. Continuing to have case folding being the > default in a now case sensitive world was deemed undesir- > able. The major use of pcfs is believed to be "sneaker net" > file transfer between Solaris and Microsoft systems. To > translate names would only serve to confuse and surprise > customers. The selective translation mechanism originally > proposed by the project team has the positive attribute of > translating the minimum number of entries but has the nega- > tive attributes of being difficult to characterize to users. > Neither this translation algorithm nor a default of foldcase > follow the "principle of least surprise". > > > Clearly the project team was right and PSARC was wrong. We want > case like Windows presents it. This isn't clear to me. More exactly, I believe PCFS (through an accepted incompatable change) does present case like Windows presents it: at least Windows 95+. Remember, that this case was bound by the original implementation of PCFS which if I recall correctly, folded everything to lower case (I have no clue as to why). Anyway, I don't think PSARC can consider this, unless somebody out there wants to author a case proposing it. - jek3 From sacadmin Wed Jun 8 09:29:34 2005 Received: from sunnl.Holland.Sun.COM (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58GTXs0011023 for ; Wed, 8 Jun 2005 09:29:34 -0700 (PDT) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.Holland.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id j58GSnGg025634; Wed, 8 Jun 2005 18:28:49 +0200 (MEST) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id j58GSmDk029299; Wed, 8 Jun 2005 18:28:49 +0200 (MEST) Message-Id: <200506081628.j58GSmDk029299@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: "Joseph E. Kowalski III" cc: frankho@mayi-mail1.germany.sun.com, Joseph.Kowalski@Sun.COM, Artem.Kachitchkin@Sun.COM, psarc@sac.sfbay.sun.com, Brian.Utterback@Sun.COM, Frank.Hofmann@Sun.COM Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs In-Reply-To: <200506081614.j58GEloI807496@jurassic.eng.sun.com> References: <200506081614.j58GEloI807496@jurassic.eng.sun.com> Date: Wed, 08 Jun 2005 18:28:48 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 628 >This isn't clear to me. More exactly, I believe PCFS (through an >accepted incompatable change) does present case like Windows presents >it: at least Windows 95+. >Remember, that this case was bound by the original implementation Strange I seem to remember that files showed up as "Io.sys" and "Msdos.sys" But not so in XP so I guess it's fine as it is now. >of PCFS which if I recall correctly, folded everything to lower case >(I have no clue as to why). > >Anyway, I don't think PSARC can consider this, unless somebody out there >wants to author a case proposing it. I'll retract my comments on that case. Casper From sacadmin Wed Jun 8 10:11:37 2005 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j58HBas0014130 for ; Wed, 8 Jun 2005 10:11:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j58HBAp04165; Wed, 8 Jun 2005 10:11:10 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0IHR00E06ZP2AX00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 08 Jun 2005 10:10:14 -0700 (PDT) Received: from jurassic.eng.sun.com ([129.146.104.45]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IHR00BOTZP26B50@nwk-avmta-1.sfbay.Sun.COM>; Wed, 08 Jun 2005 10:10:14 -0700 (PDT) Received: from 129.146.108.198 (braveheart.SFBay.Sun.COM [129.146.108.198]) by jurassic.eng.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j58HB7Ka830218; Wed, 08 Jun 2005 10:11:07 -0700 (PDT) Date: Wed, 08 Jun 2005 10:10:45 -0700 From: Darren J Moffat Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs In-reply-to: <200506081201.j58C1XDk023811@vaticaan.Holland.Sun.COM> To: psarc@Sun.COM Cc: Frank Hofmann - Solaris Sustaining , Artem.Kachitchkin@Sun.COM, Brian.Utterback@Sun.COM Message-id: <1118250645.2835.60.camel@braveheart> Organization: Sun Microsystems, Inc. MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.316 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.0.1.144180 References: <0IHR00CFAKOKB9@mayi-mail1.germany.sun.com> <200506081201.j58C1XDk023811@vaticaan.Holland.Sun.COM> Status: RO Content-Length: 1392 On Wed, 2005-06-08 at 05:01, Casper.Dik@sun.com wrote: > Well, the other option would then be to prepend the filenames of > "hidden" files with a "." and vice versa. You can NOT just change the names of the file; putting '.' in front of them changes the names of the files and WILL break the applications. For example: /rmdisk/darren ipod/iPod_Control If we do the mapping it becomes: /rmdisk/darren ipod/.iPod_Control This means that we now need to patch gtkpod to look for a name starting with a '.' on Solaris but without it on every other platform that gtkpod runs on. This is stupid and we will look stupid, today gtkpod works just find on Solaris without a patch like that. Or we need to accept both foo and .foo, but then why add that complexity, what is the REAL customer benefit here ? The only correct thing to do in my opinion is to just document the mount option that is already publicly known about. As for changing the default maybe an acceptable middle ground is change the default vold.conf for new installs, warn on upgrade and for manual mounts leave it the way it already is. At the end of the day I think this is a perfect case of ARC trying to over engineer and be over protective about interface change, seriously guys/gals lets get with the program here and consider what the Linux/BSD/MacOS X do and just follow that. -- Darren J Moffat From sacadmin Wed Jun 22 09:59:47 2005 Received: from phys-mayi-1 (phys-mayi-1-ipmp1.Germany.Sun.COM [129.157.128.114]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5MGxlEu019681 for ; Wed, 22 Jun 2005 09:59:47 -0700 (PDT) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IIH00K01WA062@mayi-mail1.germany.sun.com> (original mail from Frank.Hofmann@sun.com) for psarc@sac.sfbay.sun.com; Wed, 22 Jun 2005 18:59:46 +0200 (MEST) Received: from estale (estale.UK.Sun.COM [129.156.173.199]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with SMTP id <0IIH0050SWJLZ0@mayi-mail1.germany.sun.com> for psarc@sac.sfbay.sun.com; Wed, 22 Jun 2005 18:59:46 +0200 (MEST) Date: Wed, 22 Jun 2005 17:59:46 +0100 (BST) From: Frank Hofmann - Solaris Sustaining Subject: 2005/360 (pcfs hidden files) and 2005/361 (pcfs timestamps) To: psarc@sac.sfbay.sun.com Reply-to: Frank Hofmann - Solaris Sustaining Message-id: <0IIH0050VWJMZ0@mayi-mail1.germany.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_16 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-MD5: yGr4pRQXPWwmgGTXrAnA+Q== Status: RO Content-Length: 143 Hi, please extend the timer on these till next week's meeting, to give everyone enough time to check the updated submissions. Frank Hofmann From sacadmin Wed Jun 22 10:30:42 2005 Received: from phys-mayi-1 (phys-mayi-1.Germany.Sun.COM [129.157.128.83]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5MHUfEu021308 for ; Wed, 22 Jun 2005 10:30:42 -0700 (PDT) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IIH00401XT0JZ@mayi-mail1.germany.sun.com> (original mail from Frank.Hofmann@sun.com) for psarc@sac.sfbay.sun.com; Wed, 22 Jun 2005 19:30:40 +0200 (MEST) Received: from estale (estale.UK.Sun.COM [129.156.173.199]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with SMTP id <0IIH0057WXZ424@mayi-mail1.germany.sun.com> for psarc@sac.sfbay.sun.com; Wed, 22 Jun 2005 19:30:40 +0200 (MEST) Date: Wed, 22 Jun 2005 18:30:40 +0100 (BST) From: Frank Hofmann - Solaris Sustaining Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs To: psarc@sac.sfbay.sun.com Reply-to: Frank Hofmann - Solaris Sustaining Message-id: <0IIH0057ZXZ424@mayi-mail1.germany.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_16 SunOS 5.11 sun4u sparc Content-type: multipart/mixed; boundary="Boundary_(ID_8Tdbxhr/DRXiXC7qvVdHuQ)" Status: RO Content-Length: 5953 --Boundary_(ID_8Tdbxhr/DRXiXC7qvVdHuQ) Content-type: TEXT/plain; charset=us-ascii Content-MD5: 9e0JaCvDTlApS8Nw81QX2w== Hi, attached is the revised spec for this case. FrankH. --Boundary_(ID_8Tdbxhr/DRXiXC7qvVdHuQ) Content-type: TEXT/plain; name=fasttrack.pcfs-hidden; charset=us-ascii; x-unix-mode=0600 Content-description: fasttrack.pcfs-hidden Content-MD5: BVXwpbHaP+ftr5RLPBXoow== Case: 2005/xxx Document and enable visibility of hidden files in pcfs Author: Frank Hofmann Summary: This proposal requests, for Patch binding, * to elevate the interface status of the existing pcfs mount options "hidden"/"nohidden" from "Private" to "Unstable" commitment level. I.e. document this feature. * to change the default behaviour of pcfs so that "-o hidden" (the ability to see files on a FAT filesystem that have the 'hidden' FAT attribute bit set) becomes the default. The Problem The original submission for PSARC 1996/443 contained the pcfs- specific mount options "-o hidden" and "-o nohidden" which enabled users of the pcfs filesystem to see files that have the (non-UNIX, non-POSIX) 'hidden' FAT file attribute set. While the code that was delivered for 1996/443 had support for these options in, they had been withdrawn from the approved part of PSARC 1996/443. The reasons for why "hidden" was withdrawn were: 1. No agreement could be reached regarding the name of the mount option to "make hidden files visible". 2. No agreement could be reached regarding the (impossible) mapping of FAT attributes to the 'generic' POSIX file permission bits, and the (un)necessity for Solaris utilities to switch on/off pcfs-specific file attributes. Lacking this, support for accessing hidden files on pcfs was considered "a hack". 3. No market was seen for allowing access to hidden files. Quote from the mail archive for PSARC 1996/443: Most users can't see hidden files under DOS or Windows anyway; they have to get special tools to change them, tools that are the equivalent of fsdb. This was incorrect even in 1996, so the decision not to productize "hidden"/"nohidden" was based on incorrect facts. This situation has significantly changed eight years later. - It is trivial today (a switch accessible in Windows' Explorer Menus) to see hidden files on a FAT filesystem under Microsoft Windows. That's far from requiring "the equivalent of fsdb". - A mapping between filesystem-specific attributes and POSIX attributes (in full consequence: An extension of the POSIX file attribute set) has not been done. Extended file attributes are still not a POSIX standard, and the generic development in other filesystems on Solaris has made such "fs-specific attributes" into mount options or ioctls (example: ufs' handling of direct I/O). The advice given in PSARC 1996/443 therefore can be considered obsolete. - there's a market: Some Digital Camera and portable music player manufacturers (noticeably Apple's Ipod device) are using FAT filesystems and turn on the 'hidden' bit for ALL files on that device's mass storage. Which means support for reading/writing the data on such devices depends on making their contents visible. See RFE 1181439. The Proposed Solution PCFS will turn on the "hidden" mount option by default, making hidden files visible to the user. This gives the most consistent user experience by not hiding information from the user by default. Disabling the feature is still an option available to the system administrator if so desired. To do that, the system will revert to the current behaviour if the "nohidden" mount option is explicitly used. Reasoning ========= Other alternatives such as having PCFS rename files with the "hidden" PCFS attribute set to the UNIX-style ".hiddenfile" (i.e prepend a filename with '.' to make it invisible in a 'ls' without '-l' option) were discussed but this causes ambiguities as well as failure of existing applications that expect to see files with a given name, a "hidden" attribute notwithstanding. A real-world example application that behaves like this is the UNIX program "gtkpod" that allows access to Apple iPod music players. Likewise, just documenting the existance of "hidden"/"nohidden" mount options but not changing the default behaviour causes bad user experience, because access to such files will need explicit operator intervention, which again makes existing applications fail which just expect to see such files. The example for this is again "gtkpod". Retaining and documenting the current "hidden"/"nohidden" mount options but making "hidden" (show hidden files) the default behaviour has the advantages: 1. No surprise to users/admins who found out about the undocumented options via Usenet, Solaris headers or www.opensolaris.org sourcecode. 2. No surprise to applications written for Linux, *BSD or MacOSX, which do not perform any "name translation" for hidden files. Such applications just work. 3. By far the best cost/benefit ratio of all options. Note on "system" files ====================== The (also non-POSIX) "system" PCFS file attribute has no bearing in this case - "system" does not imply "hidden". This case does not attempt to define/modify PCFS's behaviour wrt. to files having the "system" attribute being set/unset. MAN PAGE CHANGES The man page for mount_pcfs(1M) will be changed to include usage instructions on the "hidden"/"nohidden" mount options. It will also be changed to state that "hidden" is the new default behaviour. The man page for pcfs(7FS) describes the current behaviour (hidden files not being shown) under "BUGS". That section will be removed. An example on how to use the "nohidden" mount option will be added to the Examples section of rmmount.conf(4). Manpage diffs are available. --Boundary_(ID_8Tdbxhr/DRXiXC7qvVdHuQ)-- From sacadmin Wed Jun 29 09:19:22 2005 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j5TGJLEu016730 for ; Wed, 29 Jun 2005 09:19:21 -0700 (PDT) Received: from [129.148.226.13] (sr1-unsh01-03.East.Sun.COM [129.148.226.13]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j5TGJJFt004413; Wed, 29 Jun 2005 12:19:20 -0400 (EDT) Message-ID: <42C2CA07.1080605@sun.com> Date: Wed, 29 Jun 2005 12:19:19 -0400 From: Brian Utterback User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050628) X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com CC: Frank.Hofmann@sun.com Subject: Re: 2005/360 Document and enable visibility of hidden files in pcfs References: <0IIH0057ZXZ424@mayi-mail1.germany.sun.com> In-Reply-To: <0IIH0057ZXZ424@mayi-mail1.germany.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 396 The timer has expired on this case. There were no further comments after the revised spec, so I am marking it "closed approved fasttrack". -- blu Remember when SOX compliant meant they were both the same color? ---------------------------------------------------------------------- Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom