case sensitive file names

[Roedy Green]

Is there a better way to find out if your file system has case
sensitive names other than comparing two dummy file names that differ
only in case?
--
Roedy Green Canadian Mind Products
http://mindprod.com

"It wasn’t the Exxon Valdez captain’s driving that caused the Alaskan oil spill. It was yours."
~ Greenpeace advertisement New York Times 1990-02-25

 

[Mark Thornton]

Is there a better way to find out if your file system has case
sensitive names other than comparing two dummy file names that differ
only in case?

Even that doesn't give the right answer --- there are systems where some
file systems are case sensitive and other are not (e.g. any Linux system
with a FAT formatted device). Comparing File objects only tells you
about the default case sensitivity for the operating system, not the
actual case sensitivity in a particular directory.

Mark Thornton

 

[Mike Schilling]

Is there a better way to find out if your file system has case
sensitive names other than comparing two dummy file names that
differ
only in case?

I think we went through this a while ago.and hit most (if not all) of
the corner cases, e.g. remotely mounted filesystems whose conventions
differ from the OS's. IIRC, the conclusion was that there's no way to
be certain, including comparing File objects.

 

[Roedy Green]

Can you provide a greater context for your question?

I have just about a completed a simple backup program. It checks to
see if files have changed and if so updates the archive. It maintain a
TrueZip file, deleting, updating, adding as needed to keep it in sync
with a constellation of files to back up.

The way out of this conundrum was I decided to convert all file names
to canonical form, both to store in the archive and externally then
compare case-sensitively. That works no matter what case-sensitivity
the OS or corners of it have.

--
Roedy Green Canadian Mind Products
http://mindprod.com

"It wasn’t the Exxon Valdez captain’s driving that caused the Alaskan oil spill. It was yours."
~ Greenpeace advertisement New York Times 1990-02-25

 

[Mark Thornton]

I think we went through this a while ago.and hit most (if not all) of
the corner cases,

e.g. remotely mounted filesystems whose conventions
differ from the OS's.

This case is hard to impossible even from native code.

Mark

 

[Mike Schilling]

I have just about a completed a simple backup program. It checks to
see if files have changed and if so updates the archive. It maintain
a
TrueZip file, deleting, updating, adding as needed to keep it in
sync
with a constellation of files to back up.

The way out of this conundrum was I decided to convert all file
names
to canonical form, both to store in the archive and externally then
compare case-sensitively. That works no matter what case-sensitivity
the OS or corners of it have.

I must be missing something. Unless there are filesystems which
*report* filenames inconsistently (i.e.call a file aaa.txt on Monday
and AAA.TXT on Tuesday), why do you care whether the file system is
case-sensitive or not? If On Monday there's an AAA.TXT and on Tuesday
there's no AAA.TXT but there's an aaa.txt, assume it's a different
file. (If on Tuesday there's both an AAA.TXT and an aaa.txt, you'll
know it's case-sensitive.)

 

[Andreas Leitgeb]

I must be missing something. Unless there are filesystems which
*report* filenames inconsistently (i.e.call a file aaa.txt on Monday
and AAA.TXT on Tuesday), why do you care whether the file system is
case-sensitive or not?

Let's assume a case-INsensitive filesystem.
On monday, there is a file aaa.txt with contents "foo"
On tuesday, this file is edited by someone (e.g. using an
old msdos-editor), so the new file with content "bar"
now happens to be named AAA.TXT

Now, the backup-tool sees it as a different file, and
adds it to the archive.

Then, 42 days later, this file has to be restored.
It's now a matter of luck (actually of how the
unpacker deals with it) whether aaa.txt or AAA.TXT
(but not both!) remain after unpacking.

If you specifically restore aaa.txt it will not even
have a look at AAA.TXT, so you'll definitely restore
the one with obsolete contents.

 

[Roedy Green]

If On Monday there's an AAA.TXT and on Tuesday
there's no AAA.TXT but there's an aaa.txt, assume it's a different
file. (If on Tuesday there's both an AAA.TXT and an aaa.txt, you'll
know it's case-sensitive.)

If somebody asks you to back up \snap one day and \Snap the next there
is no point in doing it over from scratch if the file system is
case-insensitive.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"It wasn’t the Exxon Valdez captain’s driving that caused the Alaskan oil spill. It was yours."
~ Greenpeace advertisement New York Times 1990-02-25

 

[Mark Thornton]

If somebody asks you to back up \snap one day and \Snap the next there
is no point in doing it over from scratch if the file system is
case-insensitive.

Such changes are very rare.

 

[Mike Schilling]

Let's assume a case-INsensitive filesystem.
On monday, there is a file aaa.txt with contents "foo"
On tuesday, this file is edited by someone (e.g. using an
old msdos-editor), so the new file with content "bar"
now happens to be named AAA.TXT

Now, the backup-tool sees it as a different file, and
adds it to the archive.

And marks "aaa.txt" as having been deleted, since it no longer exists.

Then, 42 days later, this file has to be restored.
It's now a matter of luck (actually of how the
unpacker deals with it) whether aaa.txt or AAA.TXT
(but not both!) remain after unpacking.

If you specifically restore aaa.txt it will not even
have a look at AAA.TXT, so you'll definitely restore
the one with obsolete contents.

There are lots of cases: let's try to go through them.

1. If you're restoring the entire state of the world before the
renaming, AAA.TXT gets deleted and aaa.txt recreated. This is
correct.

2. If you're restoring the state of that directory before the
renaming, likewise.

3. If you're restoring specifically AAA.TXT, it gets deleted. Feel
free to prompt that there's an aaa.txt, and ask the user if he'd like
that instead. Even in a case-sensitive filesystem, he might.

4. If you're restoring specifically aaa.txt, it gets restored and
AAA.TXT gets (implictly) deleted.. This is correct.

No doubt I've left something out.

 

[Mike Schilling]

If somebody asks you to back up \snap one day and \Snap the next
there
is no point in doing it over from scratch if the file system is
case-insensitive.

How likely is that? Far more likely that there's a file of
directories to be backed up, to which directories are sometimes added
or subtracted, but their names won't be randomized.

 

[Andreas Leitgeb]

And marks "aaa.txt" as having been deleted, since it no longer exists.
[...]
No doubt I've left something out.

You wrote that last line for me, didn't you? ;-)

 

[Arne Vajhøj]

Is there a better way to find out if your file system has case
sensitive names other than comparing two dummy file names that differ
only in case?

We had this discussion not long time ago.

Best advice: code your app so that it does not matter.

If that is not possible then the most practical advice
is to use the simple approach you suggest like:

public static boolean isFCS() {
return (new File("A")).equals(new File("a"));
}

and then ignore all the weird cases - you can not
cover them all anyway.

Arne

 

[Arne Vajhøj]

Can you provide a greater context for your question?

Keep in mind, on Windows with NTFS, it is unusual but legal for native
apps to create different files with the same name differing only in
case: see http://support.microsoft.com/kb/100625

Whether or not NTFS is considered case-sensative is dependant on whether
or not the calling application was compiled to pass the
FILE_FLAG_POSIX_SEMANTICS flag to native filesystem calls.

Give that such files will not work with standard Win32 apps
(from notepad and up), then the chance of seeing that
used must be pretty small.

Arne

 

[Mike Schilling]

And marks "aaa.txt" as having been deleted, since it no longer
exists. [...]
No doubt I've left something out.

You wrote that last line for me, didn't you? ;-)

No, pure CYA on my part