My comments embedded below, flagged with "AMR:"
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Remco Post <r.post AT SARA DOT NL>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
10/10/2003 12:05
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: ADSM with Windows 2003 Server and SFU 3.5
Now, this is about the first response that makes sense.
On Friday, Oct 10, 2003, at 20:26 Europe/Amsterdam, Andrew Raibeck
wrote:
> True, TSM (like many other Win32 applications) does not support
> case-sensitive file names.
>
> It isn't that we are willing to admit that such files exist; of course
> they exist. Nor is that we are "unwilling" to back up files supported
> by
> NTFS.
>
> TSM, like any other application, relies on operating system API
> functions
> to operate on OS-specific elements (such as NTFS file systems and the
> files that reside thereon). NTFS supports the existence of
> case-sensitive
> file names, but there are limitations to the degree of support
> afforded by
> the OS API functions. Some of the issues involved:
>
> - TSM needs to manage case-sensitive file names is differently than
> case-insensitive names (hopefully that is obvious). For non-Unix file
> names, NTFS is case-preserving, but case-insensitive. Thus 'README.TXT'
> and 'readme.txt' are the same file. TSM must operate on this file so
> that
> if the name changes from 'README.TXT' to 'readme.txt' between backup
> versions, TSM treats it as the same file. For case-sensitive file
> names,
> TSM must treat 'README.TXT' and 'readme.txt' as different files.
>
What you are saying is that because Windows allows applications to
behave case-insensitive (basically, like any 20 year old dos app) TSM
must treat readme.txt as the same file as README.TXT, just because
there are loads of applications that still behave that way, and
basically if you open a file giving the wrong case but the right name,
windows co-operates.
AMR: After a fashion, yes, but not quite right, as your summary might lead
one to think that NTFS is merely "tolerating" this case-insensitivity. :-)
Rather, I think the opposite it true. This is only my assessment based
on my own observation, so I can not speak to Microsoft's intent; but in
implementation, it would seem that NTFS *prefers* case-insensitive names,
but *tolerates* case-sensitive names.
> - Most Win32 applications are not case-sensitive with regard to file
> names
> (as noted below, there are some Windows API functions that support
> case-sensitive file names). Windows also provides a POSIX subsystem
> that
> allows POSIX applications to create case-sensitive names.
>
> - Case-sensitive file names can coexist on the same volume with
> case-insensitive names. This means that at the NTFS volume level, an
> application can not make any blanket assumptions about the
> case-sensitivity of all files on the volume.
>
True. TSM probably (I never checked) restores case as it was backed-up.
> - There is nothing in a file's attributes to indicate the case
> sensitivity. Therefore an application can not make any assumptions
> about
> the case-sensitivity of a given file.
>
> - While some Windows file I/O functions support case-sensitive file
> names,
> others do not. For example, CreateFile(), which is used to open files,
> has
> support for case-sensitive file names; on the other hand,
> GetFileAttributes() (used to obtain a file's attributes) and
> GetFileSecurity() (used to obtain a file's security attributes) do not
> support case-sensitive file names. Thus if you have files 'readme.txt'
> and
> 'README.TXT', we would not be able to obtain file attribute and
> security
> information for both files.
>
which is a major shortcoming of windows, or the particular API TSM
uses. I guess you are right in saying that this is out of IBMs scope to
fix.
> - Since, as stated above, TSM needs to manage case-sensitive file names
> differently than case-insensitive file names, TSM *must* be able to
> distinguish case-sensitive names from case-insensitive names. Since
> NTFS
> allows the existence of *both*, but provides no functionality to
> distinguish them, it is not possible for TSM to distinguish them,
> either.
>
This only makes sense if the case of a filename is not preserved during
use. I agree that, with TSMs retention policies, we do want to be able
to match different versions of one file as close to the useres
perception as possible. Since the application changes the case in the
name at more or less random occasion, TSM must indeed not distinguish.
> In sum, while NTFS may allow case-sensitive file names to exist, the
> Windows operating system itself does not provide the functionality
> necessary to fully support these files. In fact, you will find that
> TSM is
> not the only application to have difficulty with case-sensitive files.
> For
> example, some basic OS functions like DIR or basic applications like
> NOTEPAD.EXE do not handle case-sensitive file names, either. Using some
> case-sensitive names I generated, the following is output from a sample
> session that demonstrates some odd behavior (note that "posix.exe" is a
> tool I created to generate case-sensitive file names):
>
Basically, what you are saying is that, if TSM had the API to properly
back-up sace-sensitive, you might not want to do so because most
windows applications are case-insensitive.
AMR: Not necessarily: if the APIs fully supported case-sensitive names AND
provided a mechanism to flag a file as case sensitive or insensitive, then
we could theoretically modify the client to behave accordingly. The
problem is, from the perspective of an application like TSM that knows
nothing about the nature or use of the files, without such APIs, it is not
possible to make this distinction. This is the difficulty with the dual
casing alternatives offered by NTFS.
So basically this boils down
to a big dilemma, do we want to treat a change in the filename the
windows way or the unix way? Unfortunately for the few of us unlucky
enough to suffer sfu, that is about the only case where the unix way is
better....
Now if TSM was like other back-up solutions, and we didn't distinguish
between old versions of changed files or deleted files, ther would not
be a problem (apart from the fact that windows sucks...)
AMR: Maybe, but maybe not... NTBACKUP does not handle case-sensitive file
names very well, either. Using the sample scenario I presented before, I
found that if I navigate to the C:\POSIX directory tree and click on one
of the three "readme.txt" files, all three files are selected; not just
the one file I clicked on. When I perform a backup of the C:\POSIX
directory and its files, delete the directory, then restore the files I
get back exactly one file!
> ==================================================
> C:\POSIX>posix README.TXT ReadMe.txt readme.txt
>
> C:\POSIX>dir
> Volume in drive C is Local Disk
> Volume Serial Number is B022-6D5D
>
> Directory of C:\POSIX
>
> 10/10/2003 10:47 <DIR> .
> 10/10/2003 10:47 <DIR> ..
> 10/10/2003 10:47 0 README.TXT
> 10/10/2003 10:47 0 ReadMe.txt
> 10/10/2003 10:47 0 readme.txt
> 3 File(s) 0 bytes
> 2 Dir(s) 3,427,893,248 bytes free
>
> C:\POSIX>echo Upper case name > README.TXT
>
> C:\POSIX>echo Lower case name > readme.txt
>
> C:\POSIX>echo Mixed case name > ReadMe.txt
>
> C:\POSIX>dir
> Volume in drive C is Local Disk
> Volume Serial Number is B022-6D5D
>
> Directory of C:\POSIX
>
> 10/10/2003 10:47 <DIR> .
> 10/10/2003 10:47 <DIR> ..
> 10/10/2003 10:47 18 README.TXT
> 10/10/2003 10:47 0 ReadMe.txt
> 10/10/2003 10:47 0 readme.txt
> 3 File(s) 18 bytes
> 2 Dir(s) 3,427,893,248 bytes free
>
> C:\POSIX>type README.TXT
> Mixed case name
> Mixed case name
> Mixed case name
>
> C:\POSIX>type "README.TXT"
> Mixed case name
> Mixed case name
> Mixed case name
>
> C:\POSIX>type "ReadMe.txt"
> Mixed case name
> Mixed case name
> Mixed case name
>
> C:\POSIX>del "readme.txt"
>
> C:\POSIX>dir
> Volume in drive C is Local Disk
> Volume Serial Number is B022-6D5D
>
> Directory of C:\POSIX
>
> 10/10/2003 10:48 <DIR> .
> 10/10/2003 10:48 <DIR> ..
> 0 File(s) 0 bytes
> 2 Dir(s) 3,427,893,248 bytes free
>
> C:\POSIX>
> ==================================================
>
> With all of that said, we are investigating ways to make TSM behave
> better
> than it does today, but I do not see a solution that fully supports
> case-sensitive names in the near- or medium-term, as we would need
> enhancements to the Windows APIs to facilitate such support.
>
> Regards,
>
> Andy
>
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Development
> Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> Internet e-mail: storman AT us.ibm DOT com
>
> The only dumb question is the one that goes unasked.
> The command line is your friend.
> "Good enough" is the enemy of excellence.
>
>
>
>
> Remco Post <r.post AT SARA DOT NL>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 10/10/2003 06:29
> Please respond to "ADSM: Dist Stor Manager"
>
> To: ADSM-L AT VM.MARIST DOT EDU
> cc:
> Subject: Re: ADSM with Windows 2003 Server and SFU 3.5
>
>
> On Fri, 10 Oct 2003 15:06:40 +0200
> Gregor Küpper <kuepper AT INFORMATIK.UNI-BONN DOT DE> wrote:
>
>> Hi,
>>
>> we have a installation with a Windows 2003 Cluster and Microsoft
>> Services for UNIX SFU 3.5
>> In SFU we enable case sensitive filename processing. ( AAA.txt is not
>> the same as aaa.txt )
>> We are able to backup these files, but cannot restore them.
>> The error message is: file already exist
>> Who can help us?
>>
>> Regards,
>>
>> Gregor K|pper
>
> IBM can. As soon as Tivoli is ready to admit that it is a feature of
> the
> NTFS filesystem to be not only case preserving, but also
> case-sensitive,
> and
> they are ready to admit that is is their job to be able to backup and
> restore all files that can legally excist on a NTFS filesystem.
>
> Basically IBM claims WAD, NTFS is not supposed to be used in a case
> sensitive way, so we don't support that....
>
> --
> Met vriendelijke groeten,
>
> Remco Post
>
> SARA - Reken- en Netwerkdiensten
> http://www.sara.nl
> High Performance Computing Tel. +31 20 592 8008 Fax. +31 20 668
> 3167
>
> "I really didn't foresee the Internet. But then, neither did the
> computer
> industry. Not that that tells us very much of course - the computer
> industry
> didn't even foresee that the century was going to end." -- Douglas
> Adams
>
--
Met vriendelijke groeten,
Remco Post
SARA - Reken- en Netwerkdiensten http://www.sara.nl
High Performance Computing Tel. +31 20 592 8008 Fax. +31 20 668 3167
"I really didn't foresee the Internet. But then, neither did the
computer
industry. Not that that tells us very much of course - the computer
industry
didn't even foresee that the century was going to end." -- Douglas Adams
|
