> One obvious way round this would be to have the file always appear
> under the MSDOS version of the name, with the LFN version appearing as
> a hard link to it. Throw that in, and the problem mentioned above goes
> away since tar then sees and records both versions of the name.
> This would place two limitations on the hard link facility:
> 1. Only one hard link to any given file. Therefore, the link
> count field in long directory listings is limited to show
> either 1 link (for a file without an LFN) or 2 links (for
> a file with an LFN).
> 2. The hard link must be in the same directory as the file it
> points to.
> I don't see either of those limitations as being any more restrictive
> than what's already in use.
> As far as I can se, the following problems would need dealing with if
> this approach was adopted:
> 1. Attempts to delete the MSDOS named link without deleting the
> LFN named link first.
> 2. Attempts to rename the MSDOS named link to a name that is not
> compatible with the MSDOS 8.3 requirements.
> 3. Attempts to rename the LFN named link to an MSDOS named link.
> Attempts to delete the LFN name would succeed, resulting in the file
> only having its MSDOS format name, and attempts to delete an MSDOS
> named file with no LFN attached to it would succeed and remove the
> file.
> Comments?
But who will DO it ? AFAIK right now vfat does not work at all :-(( But yes,
it looks like good idea since right now you can not SEE short names but can
USE them (rm shortnam.ext will remove file, for example; and you can not
create new file with existing short name, etc). It's frustrating even without
backup problems (in fact backup problems are not THAT bad: just use doslfnbk
from dosemu :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/