Wikipedia:Reference desk/Archives/Computing/2021 December 24

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

December 24

Facebook Pages

We are not Facebook, and cannot fix this. Been posted in multiple locations on wiki. Joseph2302 (talk) 17:36, 14 January 2022 (UTC)
The following discussion has been closed. Please do not modify it.
I am facing a problem with Facebook. The "Suggest Edits" option is missing today on many pages as seen in the following screenshot. I am facing this problem both in the App and in the browser. Previously, everything was working fine. I need this to be fixed. Why is this a Wikipedia issue? Doesn't Facebook have a help or support page? Martin of Sheffield (talk) 11:01, 24 December 2021 (UTC) The reference desk is for non-Wikipedia related questions. Neel.arunabh (talk) 11:18, 24 December 2021 (UTC) Nevertheless, you would do better to ask Facebook, or other Facebook users, but the feature is probably only temporarily disabled.--Shantavira|feed me 11:25, 24 December 2021 (UTC) Questions yes, but "I need this to be fixed"? Martin of Sheffield (talk) 14:05, 24 December 2021 (UTC) "Facebook is part of the Internet; this Helpdesk is on the Internet; therefore this is a place to demand help with Facebook, because all of the Internet is one thing" might be the thought process here. Sigh. {The poster formerly known as 87.81.230.195} 90.195.175.140 (talk) 05:46, 25 December 2021 (UTC) I am still waiting for that first problem to be fixed and now I am facing a second problem as well. I play a game called "Quiz Planet". That normally has a "daily game" as well as an option to play with friends. However, since December 26, the "Daily Game" is missing. This too needs to be fixed. Neel.arunabh (talk) 07:57, 27 December 2021 (UTC) You're as likely to be able to fix this yourself as anyone else reading this. --jpgordon𝄢𝄆𝄐𝄇 16:34, 28 December 2021 (UTC) I tried contacting FB. I have not got any replies yet. Already 6 days have passed. Neel.arunabh (talk) 07:53, 29 December 2021 (UTC) It is almost a week and I am still waiting for this problem to be fixed. Neel.arunabh (talk) 07:25, 30 December 2021 (UTC) So, please let me know when this problem will be fixed. Neel.arunabh (talk) 13:53, 30 December 2021 (UTC) The chance of a random Wikipedia editor being able to "fix" Facebook's proprietary code is pretty well zero. Likewise there is virtually no chance that anyone here would have any idea when FB would do anything. It is, after all, in the middle of the holiday season so FB may not have many staff available. Please take this issue to FB, it is your only hope. Martin of Sheffield (talk) 16:00, 30 December 2021 (UTC)

Collating files

I am scanning hundreds of typescript pages to digitize and edit the text. The pages are scanned in sequence and the scanner automatically saves each OCR text file with a filename such as 20211218122757-0001A.txt, which it presumably generates based on the current date and time. I then collate all the pages from a command line with the instruction copy *.txt all.txt and all the pages go into one file, with all the pages in the correct order, almost. There are always just a few pages out of order. Why is this and how to correct it?--Shantavira|^{feed me} 14:30, 24 December 2021 (UTC)

This is a pure guess, but is it possible that some files hit the computer within the same second? From your file name I'm guessing at 2021-12-18_12:27:57. If there was another file dated 2021-12-18_12:27:57 could they get mixed? I've had similar problems with photos using date/time names. Martin of Sheffield (talk) 15:00, 24 December 2021 (UTC)

Seconded. The 0001A part is meant to help such things, though my experience is that they don't always work the way you'd think (probably dependent on the scanner/batching mechanism). It may be necessary to manually fix the file names to get them to sort correctly. If you're planning to do this kind of thing again, you may have an option to use sequential numbering instead. Matt Deres (talk) 18:23, 24 December 2021 (UTC)

Did you delete the text files? I wonder if the ordering error is visible in the order of files in the directory. That might reveal the cause. Presumably a default system sort method such as alphabetic sorting is used by the copy command to match its wildcard *. So you should be able to sort this way yourself, and see examples of how it's going wrong.  Card Zero  (talk) 15:05, 24 December 2021 (UTC)

It would help us enormously to know what system this is on. Windows, Mac OS X, GNU/Linux, a BSD, Android? You're doing this in a command-line interface? A thing that sticks out to me is the use of *. This gets interpreted somewhere as a "wildcard" character, but that somewhere varies. Whatever does that interpreting is what's responsible for ordering the filenames, and that may be where your problem lies. On POSIX systems (modern "Unix"), your shell is what expands that into a list of filenames, and when it does so it orders them according to the current locale settings, which control stuff like collation order: how strings are typographically ordered, meaning this determines what order those filenames get put in. --47.155.96.47 (talk) 05:30, 25 December 2021 (UTC)

If the (plausible) same-second theory is correct, files with filenames that are out of order will share the part before the hyphen, which should not be hard to detect. Then by suitably renaming the few disorderly ones you can restore order and make copy *.txt all.txt work its wild-card magic as desired.  --Lambiam 10:26, 25 December 2021 (UTC)

I'd assumed a Windows user since: (1) the OP used copy not cp and (2) no mention of an OS often (not always) implies that the OP isn't aware of other OSs. Shantavira – please correct any of the foregoing assumptions if they are wrong! Martin of Sheffield (talk) 10:48, 25 December 2021 (UTC)

Thanks everyone. This is indeed under Windows. Each scan and OCR takes about half a minute, so the timestamp in the filename will be unique. I'm guessing maybe the default collation order is the physical order on the SSD which might not always be the same as the order in which they are saved. I found a suggested command line on stackoverflow that is supposed to force them to be collated in order of creation: for /F "tokens=*" %%i in ('dir /b /OD *.txt') do type "%%i" >> combine.txt, but that just produced an error message.--Shantavira|^{feed me} 11:47, 25 December 2021 (UTC)

just produced an error message — It would be more helpful if you told us what the error message was. I suspect that it was %%i was unexpected at this time. If that's the case, the problem is that %%i (with two percentage signs) will only work inside a batch file. To run the command at the command prompt, use replace both instances of %%i with %i (one percentage sign). Mitch Ames (talk) 13:09, 25 December 2021 (UTC)

in order of creation — Strictly speaking dir /OD lists them in order of modification, not creation. For your purposes that probably doesn't matter - but it would if, for example, you manually edited a file (eg to fix a mistake) other than the last after creating them all. dir /ON would list by name, which could be useful if the names are always in the desired order. Mitch Ames (talk) 13:19, 25 December 2021 (UTC)

Piece of advice: if you're just throwing these files away after you're done, you're shortening the life of the SSD for no good reason. SSDs have a finite number of writes. You can easily use ramdisks on modern Windows. Web search "windows ramdisk". This probably won't be noticeable for things like text, but it will also be faster since you're skipping the step of writing temporary stuff to the drive. --47.155.96.47 (talk) 00:39, 26 December 2021 (UTC)

I'm not an NTFS expert, and Microsoft has a habit of doing things in odd ways, but here is a thought drawn from RSX/VMS/VM/UNIX/Linux experience. Contrary to the simplistic interpretation, a directory is just an index of names and pointers to the real file metadata. In many systems a file can be entered into multiple directories, even under different names. The filesystem has an area of structures which hold the metadata and can index into them quickly. For instance /home/MartinOfSheffield/myfile.txt would be found in the directory file /home/MartinOfSheffield and would be a pointer to 0123 4567 89AB CDEF (for a 32-bit filesystem). Going now to the filesystem look up entry 0123 4567 89AB CDEF and you'll find the various dates, information about revisions and where on the disk surface the real data lies. The relevance of all this is that the directory file may, or may not be kept sorted. If it is sorted then you would expect "*" to find the files in alphabetical order, but if slots are reused then it is possible that "*" will find the files in some other order. Under *nix you can see this in a few utilities such as cpio where the file name order within a directory can seem a bit arbitrary. As I said above, I'm not an NTFS expert, but could something similar be happening here? Will copy * ... sort alphabetically? Martin of Sheffield (talk) 09:09, 26 December 2021 (UTC)