XWorkplace 1.0.8 and truncated file-copy result?
Dariusz Piatkowski
I don't often use this function on such a large number of files/subdirectories,
but recently I added another 64GB HPFS partition to my current configuration.
I needed to move a large number of images (photos, etc) from the old partition
to the new and so I attempted to use the Xworkplace 'pickup/copy' functionality.
No issue there really...all file counts and sizes match...the strange thing is
that in my VIO sessions all filenames appear to be truncated to 8 chars on the
destination partition...ugh????
Again, these are both HPFS partitions, maybe this is how things have always
worked, but in all honesty I have either never seen this or this is something
new...LOL.
About to test the old 'xcopy' standby next...I am not expecting to see this
bevahiour though...it has always worked perfectly for me before.
Any ideas what's going on? Is there a setting somewhere that I'm missing?
OS/2 setup:
CP2 with FP6, 4 core with SMP
HPFS386 w/ 128MB cache
source drive = cached
target drive = uncached
partitions are on separate drives (not 2 partitions on the same drive)
Thanks!
Jonathan de Boyne Pollard
> to be truncated to 8 chars on the destination partition...ugh????
You'll almost certainly find the original names in their .LONGNAME
extended attributes. This is the behaviour that one experiences with
the Workplace Shell if it thinks that the target volume does not support
long names. I have a vague memory of a tool somewhere that reads out
the .LONGNAME attributes and renames the file to that name if it can.
There'll be something on Hobbes no doubt. It's not hard to knock
together a REXX script to do this, in any case.
Andreas Schnellbacher
> This is the behaviour that one experiences with the Workplace
> Shell if it thinks that the target volume does not support long
> names.
formatting and copying.
--
Andreas Schnellbacher
Marcel Müller
AFAIR it also happens when you are on a removable device and the volume
has been FAT16 at WPS startup.
Marcel