Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
This showed up in download folder recently.
The file is empty but the filename was:
''$'\001\331\006''#f2#8'$'\f''#'$'\037\036\006\004''###'$'\240\002\240\002\b\003\004\340\002\340\002\340\002\034\034\001\001\004\250\210\002\250\210\002\020\001\005\220\002\220\002\220\002''e'$'\222'
Which bothered me right away because it looks like $unicode_chars, many of them being commands?
001 Start of heading
331 no idea
006 Accept char
\004 End of transmission
At any rate, how does such a file show up on your computer?
Linux file names can contain any character, except the null character (\0) and the slash character / (directory separator) 1. So yes, a file name can contain executable code or any kind of data. It doesn't mean it can be executed, though. The only functions provided by the operating system are file operations, like opening the file, directory listing, etc. To be able to execute the code it must be inside the file, not on its name.
1 https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations
This showed up in download folder recently.
You (not your computer) is responsible for your downloads!
At any rate, how does such a file show up on your computer?
Smells like your computer (or the computer from which you downloaded carelessly) has been compromised by some vulnerability or cyberattack, or that a very buggy program (with buffer overflow) has been carelessly run.
Another possibility is a severe hardware problem, e.g. a dying hard disk or SSD, faulty RAM, cosmic rays, a careless power outage, which corrupted some file system.
Consider using strace(1), gdb(1), fsck(8), dmesg(1) to investigate more.
Backup carefully your important data before.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
When I first learned Linux, I was told almost everything in Linux is file. This morning, when I repeated it to my girlfriend. She asked what is not? I tried to find an example for half a day.
So my question is what is not file in Linux?
Almost. Almost everything in Posix is handled through a file descriptor. This means that the same functions used for file operations also apply for pipes, sockets, and hardware devices. This also means that if you use select (or one of its better alternatives), you can have one point in your program where you wait for all possible inputs.
With that said, some things in Posix, and in particular, in Linux, are definitely not files.
The most obvious ones are signals. They are handled asynchronously to the program's execution, and therefor cannot take on a file interface. For that purpose, pselect and one of its better alternatives were invented.
Things more subtly not files are thread synchronization constructs (mutexs, semaphores, etc.). Some attempt have been made to make those available as file descriptors as well (see signalfd and eventfd), but those hardly caught on. I believe that this is due, in large part, for them having a vastly different performance profiles than the ususal way of handling them.
for example computer hardware (CPU, RAM, Etc) is not actually a file, but it is represented as a file in linux.
More details here
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I am just preparing a doc file. i am using LibreOffice in ubuntu.
The name of the file is
WebApplicationRequirements.doc
When i am saving that in a drive, an extra file shows in the hidden file.
The name is
.~lock.WebApplicationRequirements.doc#
When i am pushing that in a remote repository it is including that hidden file. If i delete that fill will it harm the original file. And why it is happening?
As the name suggests, that hidden file is a lock file used internally by LibreOffice. To prevent multiple LibreOffice application instances from writing to the same file at the same time. It's not generally harmful to delete that file. It should get re-created again next time you open that file again in LibreOffice.
You haven't indicated what remote repo system you are using. But also note that most repro systems (e.g. git) have the concept of ignore files which allow you to configure which files to ignore during commit. If your repro system has that you probably want to add a rule to ignore the lock files so that they are not committed/pushed.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I'm using a small Linux computer in which the software is on an sd card. I needed a program to run at start-up, so I did sudo nano /etc/rc.local and then I added a new line btwn F1 and exit 0 that contains the complete path to my program. This works great, but now I'm locked out. My program runs at start-up like I wanted, but I need to access the program and tweak a few things. I did try putting the sd card in my desktop Windows computer and add init=/bin/sh to the end of the cmdline.txt file. But this had no effect, any suggestions?
Presumably, boot up a desktop Linux machine - mount the sd card, edit the /mnt/etc/rc.local to remove the newline and complete path to your program (from between F1 and exit 0). Then umount the sd card and boot it up. If it won't boot, try and undo that edit to cmdline.txt (which I don't think actually does anything - being a txt file).
This question probably belongs on Super User rather than here.
However, it would probably be easiest for you to get access to a Linux PC and try to edit the file there rather than on the embedded board itself.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
What would happen if the Linux kernel deleted itself? Will there be a moment when it could no longer delete files because rm or the program used for deletion has been deleted too?
Regards.
The question is (apart from being off-topic) somewhat wrong in itself, as rm is not part of the kernel, but either a shell built-in or a separate user-level program. Admittedly, rm uses a syscall provided by the kernel, but that is irrelevant.
The kernel itself is loaded from a compressed image and locked in RAM. It does not matter whether you delete the compressed image until you reboot (which will fail with the boot loader giving you a message like "vmlinuz not found"). You have no way of removing the kernel from RAM (well, other than rebooting...).
Also, for the most part, it does not even matter whether you delete a file, including a running program's executable anyway (if we may be so daunting as to call the kernel a "program" for a moment) under Linux, because deleting a file merely removes the link, not the file. It is a Windows-typical assumption that deleting a file does evil, destructive things.
Under Unix-like systems, it is perfectly possible to delete (or replace) a program while it is running, and it will not cause any problems at all. You will remove the name in the filesystem, that's all. Any open descriptors will remain valid until the last one is closed, the original file will stay intact as-is for any observer who obtained a handle earlier, and it will be "gone" for everyone trying to get at it later.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
If I run find (Ubuntu, specifically), can I expect it to give me the same order of results every time? (Assuming, of course, that the actual files haven't changed.)
In other words, if I run
$ find foo
and it gives me
bar.txt
foo.txt
can I expect that it will never give me
foo.txt
bar.txt
?
The answer is "probably" but you shouldn't rely on it because any number of things can affect it.
What order do you want the files in? Decide on that and then use a find command (perhaps piped into sort) which reproducibly gets the result you need.
The order of the files is determined by the fine details of the filesystem format and the filesystem driver. You can't rely on it. Depending on the filesystem and operating system, here are things that might change the order:
A file is created or removed in a traversed directory (even if none of the listed files changed).
The files are moved around (e.g. transfered to a different filesystem or restored from backup).
A defragmenter or filesystem check ran and decided to move things around.
If you want a reproducible order, sort the results. find … | sort will do nicely if none of the file names contain newlines.