Case insensibility in filenames and rsync, mount.
 

Is there a way of making rsync (an offspring of rcp) case insensitive? Perhaps mounting the file system (not linux) in some special way? Regards.

Which file system is it?

vfat. Specifically, fat32.

The mount man page does not have any such options for vfat or fat so let's take a step back and ask what you want to achieve and how do your current methods fail ... ?

I have a cd-r, recorded by me, with files whose filenames are uppercase and files whose names are mixed upper/lowercase. This is CD://STORE1/, with STORE1 only tree on the cd. This CD-R has been recorded in several sessions from the main tree, /big/store1 on the hard disk, which is that I maintain, doing periodical burnings as a means of backing up.

Now /big/store1 has grown so much, it would not fit in CD. So, DVD. At first I thought of getting the CD-R image, and, together by an image generated by /big/store1/, let mkisofs do the work. But soon I saw I was wrong (may be not).

I then recurred to rsync, by your advice, if I remember well. And here I'm stuck. As you can see, not much work done.

EDIT: getting the image from the CD, burning it into the DVD and making a second session, on the DVD, with the other image would, on first thought, solve the problem. However, mkisofs/cdrecord are not as intelligent as to solve the filename problem, I guess, and we are back at the beginning.

Confirming understanding and clarifying:

1. /big/store1 is the vfat file system?
2. Files on the vfat file system have names with uppercase characters only?
3. If a) the answer to the last question is "yes" b) all the files on the CD came from the vfat file system and c) some of the files on CD have mixed case names then how did the files on the CD end up with mixed case names?
4. How are you using rsync to prepare files for mkisofs to write to the CD? A copy and paste of the commands or script would be more informative than a verbal description.
5. Do you have plenty of HDD space for making temporary copies etc.?

Sorry if I was ambiguous.

1. Yes.

2. Yes.

3. /big/store1, where /big is vfat, can be partitioned into two sets: files with all uppercase names and files with mixed upper/lowercase names. History: I used to work a lot in MS-DOS 5.00, under which you must stick to the 8.3 filename convention. As sometimes I booted in windows 95/98, and downloaded files through the internet, this is the origin of the mixed names (example of a mixed name: cpp5compiler.zip.GetRight). Note: all the files in /big/store1 have double entries in their directories. 'ls AUTOTRAX' gives the same output as 'ls autotrax'.

4. rsync -u /media/cdrom0/STORE1/ /big/store1. Alas, big mistake, is it not (the final slash)? I also issued 'rsync -u /media/cdrom0/STORE1/SOFT/* ./*, where ./ = /big/store1/soft. You can see a copy of the output in attached file.

5. I do.

No worries; it's very hard to be complete, concise and precise. Sorry for needing such a detailed picture to understand! And I still don't fully understand so more questions coming up.

About "Note: all the files in /big/store1 have double entries in their directories. 'ls AUTOTRAX' gives the same output as 'ls autotrax'": does that mean you have copies of every file in the AUTOTRAX directory in the autotrax directory or that there is only one copy of each file and it is somehow accessible via both directories? Maybe one of the directories is a link to the other?

About rsync -u /media/cdrom0/STORE1/ /big/store1: is this intended to copy any files from the CD that do not already exist under /big/store1? The final / on /media/cdrom0/STORE1/ is what you want; from the rsync man page it means "copy the contents of this directory" as opposed to "copy the directory by name". If you want it to copy subdirectories as well you need the -r option as well.

Are you still using DOS 5.00 and Windows 95? If not the simplest approach may be to accept whatever upper/lower/mixed case names you currently have, to find and remove any files differing only in name and then to work out how to back them up to DVD.

Have I misunderstood anything?

Any more questions coming up will be gladly received as it is I who is in need of help.

Take autotrax as an example. That is a regular file and is under dir .../soft/. The entry in .../soft/ is repeated. Once with filename 'autotrax' and one with filename 'AUTOTRAX'. But they're the same file. So it is not a hard link. The node is the same. I think this comes from win95/98 at file creation. But the same happens with all files in /big/store1/. If I went to win98 where I know the structure of vfat, I could do a dump of that zone of the HDD and I pretty sure I would find out things are as mentioned. As an example of double entries, when win95/98 was asked to write a file in the DOS 5.00 partition, and the file name was not 8.3, it wrote the file name in a contracted form and, along with it, the whole name. Eg, 'Tamil Nadu' would appear as the double entry
Yes, it is intended to copy files not already existing in the target. And I now see the syntax for rsync, subtituting '/*' for the final '/', is just that of cp at least for local to local.

DOS 5.00 only occasionally, because it lets do almost anything with the machine. Windows for some tasks it runs better than my linux box, but only because slack is not for beginners.

Have a fine weekend.

Got it! This is the "long/short names" backwards compatibility feature introduced with Windows 95. Can DOS 5.00 handle long names? If not and you want to access these files when running DOS 5.00 then you want to keep the short names ... ?

rsync's syntax is not exactly the same as cp's; for cp <directory> and <directory>/ are equivalent; rsync treats <directory> the same but treats <directory>/ as meaning the "every file and directory in <directory>". cp does not accept <directory>/*, it is the shell that expands the * in <directory>/* to produce a list of files and directories for cp to operate on. To illustrate:

Yes, it is. And only the OS that was in the secret could read the long one. DOS 5.00 cannot. Only in their contracted form.

On the contrary. No interest in keeping the short names. Roger about the shell glob expansion. Kind regards.

If you rm the file by its short name, does that also remove it by the long name (that would be consistent)?

Maybe easiest would be to rsync everything onto a Linux file system for cleaning up?

The test you suggested I did it. As was to be expected, removal of one (rm) makes the other to disappear. I would follow your opinion, to rsync everything onto my ext2 filesystem. But what happens when rsync finds two copies of the same file, one in the source and one in the target, but with different filenames? I think rsync has already given me the answer: he gets confused and won't proceed. But maybe there is an option to work around this difficulty. Can there be one?

Can you copy the rsync "confused" messages into a post in this thread?

I beg your pardon a thousand times, catkin, but at some point during this thread, I proceeded by hand and, as a result, I no longer have one of the sets at my disposal. It's been clumsy of me, I know, but I could not leave the procdrure hanging any longer, for reasons I need not to bother you with.

Any way, there being such a great quantity of commands in linux, I never end learning the existence of even the most basic. And I have placed rsync among the list of indispensable commands I keep, although the size of the manual intimidates me a bit. Do you know of any kind of tutor? Regards.

No problem.

rsync does have a lot of options so a big man page. I do not know of any tutor. Like the find command I do not attempt to remember all the options, just the capabilities and then look up all but the most common options as the need arises.

It's been a pleasure. Regards.