Another computer question...

Black Hole said:
Maybe I'll hang on for a bit, in case I realise there's something else I need to recover.
Click to expand...
My process these days for such dilemmas is to put it in 'storage' and when a few years (or these days months or even weeks) later I come across it having forgotten it existed ... Then I bin it.
It works for boxes of stuff in the loft anyway :)
 
Black Hole said:
I don't see why, in my ambient temperature which remained under 30 deg.C, a UPD should peg out when worldwide people must be using them at higher ambient temperatures.
Click to expand...
True, but high temperatures accelerate aging. If these chips are actually running at high temperatures in normal operation then after a time the extra few degrees of a heat-wave might be the straw ...
 
I must be going senile! How do I copy a specific directory and its contents to another location on the Windows (7 Starter) command line? Everything I've tried so far copies the contents of the directory but not the directory itself. Surely zipping and unzipping isn't the only answer??!
 
Don’t know for latest versions of windows. Older version:

xcopy/s “from path” “to path”

Where paths probably need the quotation marks, and are of the usual format eg. C:\program files\rubbish (possibly not requiring trailing \ )
 
EEPhil said:
xcopy/s “from path” “to path”
Click to expand...
Nope. That copies the "naked" contents too. What I finally came up with is:

> robocopy <parent> <destination> <filespec> /MIR /S /DCOPY:T

...but even that didn't let me specify exactly which directory I wanted to copy, I had to use <filespec> to match the contents to copy which then created the relevant directory under <destination> (and the /DCOPY:T switch copies across the timestamp for that new directory). And the command had to be run from the grandparent level.
 
EEPhil said:
I'm not sure whether you need to create the target directory first with xcopy
Click to expand...
That's the point. I want to copy the directory and contents (and preferably maintain the timestamp on the directory file). By "naked" I mean contents only without the directory wrapper.

Neither copy nor xcopy nor robocopy seem prepared to copy a specified subdirectory of the current directory. If you specify a subdirectory as the subject, they say "the user has specified a directory, that must mean the contents of". I can force it by starting from the parent directory, but then I get either the whole tree (/E), or any part of the tree which contains files matching the pattern (/S) – I don't get to say "I only want this particular subdirectory included in the search-and-copy".

This seems such a simple thing: "when I said <dir> I meant <dir> and not <dir>\*.*"!

What I'm actually doing is some investigation which requires I can go back to a baseline set of test files with timestamps and attributes intact. The easiest way seems to be to have a zip of the baseline set and unzip it to return to baseline, but even that doesn't preserve timestamps on directories, only files. I believe this is because the OS requires directories to be created rather than copied, and anything which preserves a directory timestamp (ie robocopy) is actually creating the folder and then correcting the timestamp. I can live with that.

PS: Bastard markup wouldn't let me post asterisks – they were interpreted as italics tags! I had to enclose in plain.
 
I appear to have installed a sort of link management shell extension on my PC (from https://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html). One of the options is a "smart copy". Obviously this is not a command line procedure. You left click on the source directory, "Pick Link Source", go to where you want to "drop" your (not) link, left click & "Drop As" and choose "Smart Copy". It copies the directory and contents to a new directory (which, unfortunately, it names itself). As far as I can see all the time stamps including the top directory match the timestamps of the originals and, despite the name of the extension, they are not links in this case.

The only time I've known timestamps to be preserved is with backup utilities (usually on non-Windows systems). I suppose you could argue zip falls into this category. None of zip, rar or 7z archivers seem to preserve the creation time on directories. rar and 7z preserve the last update time.

This ought to be easier...
 
Black Hole said:
That's the point. I want to copy the directory and contents (and preferably maintain the timestamp on the directory file). By "naked" I mean contents only without the directory wrapper.
Click to expand...

I'm not sure you can on a command line, unless you go 'copy . destination' when in the directory whose files you wish to copy.

[edit]
ugh - same problem as you with asterisks, it has just left the 'dot' of the wildcard asterisk-dot-asterisk.
[/edit]
 
Curious! From where did I learn to embolden by enclosing in a pair of *, /italicise/ and underline by enclosing in a pair of _ from then? I thought is was from my earlier Janet/internet use with teletext type terminals.
 
This is just to make a note really:

I've noticed that including emoticons in SMS text messages consumes a large number of the characters in the allowance.

Three messages can be aggregated, so that's 3x160 = 480 characters. Inserting one emoticon/emoji took the "characters remaining" figure from "111/2" to "4/3" (four characters out of three messages), so I reckon that's from

160 x 2 - 111 = 209

to

160 x 3 - 4 = 476

ie 267 characters.

So that leads to the idea that an emoticon is actually encoded as a graphic. I had previously assumed emoticons would be some kind of extended character set, with a short code indexing a predefined look-up table at each end, but if not... does that mean we could actually define our own graphics??
 
Sounds like your emoticons are being converted to emojis. I always stick with emoticons for SMS texts : ) and only use emojis in Whatsapp and forum posts. :)
 
My understanding is/was that anything graphic makes the message into an MMS.
Like gomezz I only use text smileys, daddies, etc, in SMS.
 
gomezz said:
Sounds like your emoticons are being converted to emojis
Click to expand...
Maybe I'm not familiar with the terminology, I was not making a distinction. I was referring to the pop-up on an Android soft keypad which offers a variety of symbols (including national flags, but never anything I happen to be looking for). Pure text I call a smiley.

MikeSh said:
My understanding is/was that anything graphic makes the message into an MMS.
Click to expand...
These do not, somehow they get embedded as text and then reconstructed at the receiving end. It would be interesting to see how they get presented on a strictly text only old-skool phone.
 
I have found the answer here: https://thesmsworks.co.uk/blog/emojis-sms/

Using an emoji will require the whole text message to be sent in unicode. Unicode is an encoding standard that allows you to send characters that are not part of the standard character set that you would normally use. (The standard characters are known as the GSM character set.)

When sending a text in unicode you have fewer characters per text credit to play with.

A standard text allows you to send 160 characters per text credit. When you send an emoji (and send using unicode), this is reduced to just 70 characters.
Click to expand...

So emojis are sent as Unicode, but the overall message allowance reduces by the conversion of the whole message from ASCII to Unicode.

Re-addressing my previous calculation:

160 x 2 - 111 = 209

to

70 x 3 - 4 = 206

...so the emoji occupied -3 units (whatever the current unit is). Something is not quite right, but it's close.

What's the correspondence between 160 plain characters and 70 Unicode characters? Maybe 160 x 7 bits = 70 x 16 bits.

But surely that's not the whole answer, because there might be some preamble to tell the receiving end that it's Unicode, and not all Unicode is 16 bits. As I understand it, Unicode is a superset of ASCII, so wouldn't the plain characters correspond 1:1 in Unicode anyway? Maybe, instead of "Unicode", we should be talking about UTF-16.
 
Last edited:
You must log in or register to reply here.
Back
Top