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.
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 4 years ago.
Improve this question
Well, I know you have to use -r with cp and rm when dealing with directories. It makes this job recursively (meaning it coping and removing all starting with things inside).
But why you dont do "mv -r" when moving / renaming directories?
Directories are just collections of pointers to locations of files on the filesystem. When you move a directory you are updating the file pointers of the new and old parents to contain/remove the one you moved. Thus, child file pointers inside do not require recursive action as none of the pointer locations have actually changed for them.
EDIT: I've just found a much more detailed answer on Unix & Linux StackExchange that will help explain this further.
https://unix.stackexchange.com/questions/46066/why-unix-mv-program-doesnt-need-r-recursive-option-for-directories-but-cp-do
For every move, new location is needed.
If one wants to move all files under directory alongwith the directory, just move the directory which is recursive.
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 4 years ago.
Improve this question
I'm currently studying Bash shell and have encountered command ls -F. I know it ls function is to append indicators to items lists, so to distinguish between different file types. I know that / is appended to directory and * is appended to executable files. But I have checked the manual page on ls command but couldn't find any information on indicator =>#|.
Could someone tell me what they represent? And it would be even better if can inform me where to find this kind of information when in need.
Try info ls, under "What information is listed":
‘-F’
‘--classify’
‘--indicator-style=classify’
Append a character to each file name indicating the file type.
Also, for regular files that are executable, append ‘*’. The file
type indicators are ‘/’ for directories, ‘#’ for symbolic links,
‘|’ for FIFOs, ‘=’ for sockets, ‘>’ for doors, and nothing for
regular files. Do not follow symbolic links listed on the command
line unless the ‘--dereference-command-line’ (‘-H’),
‘--dereference’ (‘-L’), or
‘--dereference-command-line-symlink-to-dir’ options are specified.
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
Today,I encounter a very tough problem which cost me nearly 6 hours.
When I remove a file called ha_wan.conf using rm -rf ha_wan.conf command under /etc directory,Success.When I use ls -al command to see the result,The file disappear.
But when I reboot the linux system,same file named ha_wan.conf come back,located under /etc/ directory.
I tried to delete it many many times,It is the same result.
What should I do,I want to permanently remove that file.Thanks.
There's no magic. You removed the file. If you still see it after a reboot, it means one of two things:
(very likely) Some service recreates the files on boot, or periodically. You can probably use standard system tools to find out which package contained that file. (for example dpkg -S ha_wan.conf in debian-like systems)
(unlikely) You're running some interesting system which uses a temporary filesystem in /etc. If you're using a standard desktop distribution, that's improbable. But if it's some kind of router / special device, then it could happen.
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
Trying to determine if there is a scenario in which the copy command may fail.
I don't mean something like $PATH not set or file missing, but more in line with if the file is being edited, if the file is a binary file and being accessed by a system process or if its a database file which is being accessed.
Some basic testing seems to indicate the cp command works fine even if the file is being edited but not sure if there are any OS commands or scenarios in which a cp would fail. For example, what if its a database file and being updated/saved as the exact time the cp takes place. Something like this would be hard to test yet may occur.
Would there be a list of scenarios in which the system prevents a cp command from executing?
There are plenty of ways cp might not do what you want.
Particular example that comes to mind: If you have a process that can read the destination of cp at any given time, there is no possible way to guarantee the reader won't start reading before cp is done copying and end up reading a partially written file. On small-ish files, this race condition may always work out in your favor, but it's still there.
The only way you can have a file that is always updated "atomically" from the perspective of readers such they always get either the old version or the new version, never a partial new version is via the rename system call. Which should be what mv uses for files on the same volume/partition.
Implementing cp is, at the very least 5 system calls: 2x open, 1x sendfile, 2x close.
So just be aware that even if cp succeeds, there can still be race conditions and unpredictable behavior.
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 1 year ago.
Improve this question
Is there any way to store any data in Linux tmp directory. As i know Linux clear its /tmp directory when system is rebooted. But I want to store data permanently.
Like #bereal said, this defeats the purpose of the /tmp directory. Let me quote the Linux Filesystem Hierarchy Standard:
The /tmp directory must be made available for programs that require temporary files.
Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.
You'll find a better place to store permanent data.
Since it's linux you are free to do what you want to do (as root). When /tmp is cleared depends on your system and can be changed; there is no particular magic involved. A good summary seems to be here: https://serverfault.com/questions/377348/when-does-tmp-get-cleared.
Of course if you are root you can set up an entirely different global directory, say "/not-quite-tmp" or such. But I assume that some progs not under your control write to tmp and you want to inspect or in any case persist those files.
While you are trying to do wrong things, it’s still possible.
/tmp directory is cleared accordigly to TMPTIME setting. The default is apparently 0, what means “clear on every startup”.
The value might be changed in /etc/default/rcS (value is to be set in days.)