DZMM Posted June 26, 2018 Share Posted June 26, 2018 (edited) on the global share settings it says Quote Do not copy data from a disk share to a user share unless you know what you are doing. This may result in the loss of data and is not supported. Can I get a bit more background please. Is it safe to do this via putty/mc? When is it not safe? Does #1 also apply the other way i.e. copying from mnt/user/share ---> mnt/diskX Does this also apply to coping to unassigned drives/manual mountpoints e.g.mnt/user/share--->mnt/disks/ and vice versa? Thanks Edited June 26, 2018 by DZMM Quote Link to comment
DZMM Posted June 26, 2018 Author Share Posted June 26, 2018 Thanks, but a lot of that went over my head. Someone asked for similar clarification in language I understood here but didn't get an answer I've been doing a lot of copying from mnt/diskX/movies to mnt/disks/google_media/movies and that's been working fine. The main use case I want to check is if it's safe is copying from mnt/user/movies to mnt/disks/google_media/movies, as this will make my life a lot easier Quote Link to comment
JorgeB Posted June 26, 2018 Share Posted June 26, 2018 34 minutes ago, DZMM said: The main use case I want to check is if it's safe is copying from mnt/user/movies to mnt/disks/google_media/movies, as this will make my life a lot easier Yes, /mnt/disks is outside the user shares, user shares are on /mnt/user 1 Quote Link to comment
SSD Posted June 26, 2018 Share Posted June 26, 2018 Don't confuse disk shares (e.g., disk1, disk2) with "disks" shares created by the unassigned devices plugin. "Disks" shares can't participate in a user share, so there is no problem copying to/from user shares. 1 hour ago, DZMM said: Thanks, but a lot of that went over my head. Someone asked for similar clarification in language I understood here but didn't get an answer Here is another post on user share copy bug that might be clearer. Also gives some data on user shares you might not know. The other post was a bug report really aimed at explaining the issue to Limetech. Quote Link to comment
pwm Posted June 26, 2018 Share Posted June 26, 2018 I really don't like the too much used word "bug" in this context. In the general case, it isn't a bug in unRAID or in Linux but a problem that affects most (all?) OS when the same file is allowed aliased names. This makes it impossible for the program that performs the copy to notice that the source and destination names points to the same file. The application that performs the copy should normally never even try to copy without requiring an explicit "yes" or a force flag if the destination file name already exists. No sane copy program should default to overwrite existing files. That takes care of most of the issues. The application that performs the copy should also open the source file for exclusive read - in many situations such exclusivity will get translated to the specific file on the specific disk and stop the application from trying a write operation through a different alias. Another solution for the copy programs is if they make the copy to a temporary file name and first after a full copy performs a move to the intended destination name - requires more free disk space during the copy but guarantees that a power loss etc doesn't result in a partial destination file. I haven't tested it, but it would be a bug if the unRAID-specific shfs doesn't handles a file lock on a user share by creating the file lock on the actual disk share. If that doesn't happen, then it doesn't help if copy programs starts by requesting a read lock on the source file - Linux would not be able to report that the file is write-protected when the copy program then tries to open the file for write. Quote Link to comment
FlorinB Posted June 26, 2018 Share Posted June 26, 2018 5 hours ago, pwm said: I really don't like the too much used word "bug" in this context. In the general case, it isn't a bug in unRAID or in Linux but a problem that affects most (all?) OS when the same file is allowed aliased names. This makes it impossible for the program that performs the copy to notice that the source and destination names points to the same file. When you try to copy a file to itself and this ends up badly, with data loss, then for sure it is not the OS fault. I would not name it "bug" as well. Anyway this topic together with the other one from here, helped me to understand better what and how exactly this "bug" is behaving. Quote Link to comment
SSD Posted June 26, 2018 Share Posted June 26, 2018 7 hours ago, pwm said: I really don't like the too much used word "bug" in this context. In the general case, it isn't a bug in unRAID or in Linux but a problem that affects most (all?) OS when the same file is allowed aliased names. This makes it impossible for the program that performs the copy to notice that the source and destination names points to the same file. This is not true. Can you give an example where an OS aliasing feature causes to OS to not be able to detect a file is being overwritten. Most (all?) alias features including Windows shortcuts and Linux symlinks recognize that you are trying to copy a file on top of itself even through the feature. Even the old DOS ASSIGN and SUBST commands were smart enough to detect this. And the main use case for this bug - removing a disk from a user share and then copying from the excluded disk's disk share to the user share. No sane person would expect that to cause data loss without being pre-warned and understand user shares to a very deep level (see my previous post above). You can say let the user beware if you like, but there should at least be a bold warning on the user share's GUI page that a user must acknowledge before enabling user shares (this doesn't fix the bug but at least gives the user a fighting chance of not being bit by it). 7 hours ago, pwm said: The application that performs the copy should normally never even try to copy without requiring an explicit "yes" or a force flag if the destination file name already exists. No sane copy program should default to overwrite existing files. That takes care of most of the issues. The application, in this scenario, is the Linux itself ("cp" and "rsync" commands). As well as all other copy programs I know (midnight commander, windows "copy" command, windows GUI drag and drop copy, and others). Certainly you can't blame all of these OS commands and programs and say they are copying files incorrectly! The authors of shfs should have been able to foresee this issue and coded around it. 7 hours ago, pwm said: The application that performs the copy should also open the source file for exclusive read - in many situations such exclusivity will get translated to the specific file on the specific disk and stop the application from trying a write operation through a different alias. I have a lot of confidence that the "cp" command is doing everything right. It is the most basic and well tested. And if SHFS creates a situation where it can't copy files correctly, it is a bug in SHFS not Linux. Look at the "cp" command manpage for any warnings that if files are linked then cp may overwrite them. 7 hours ago, pwm said: Another solution for the copy programs is if they make the copy to a temporary file name and first after a full copy performs a move to the intended destination name - requires more free disk space during the copy but guarantees that a power loss etc doesn't result in a partial destination file. A copy does not remove the source until the destination is completely written. What you are referring to here is a "move". Having a copy operation that results in the source being lost ... not a bug? ? 7 hours ago, pwm said: I haven't tested it, but it would be a bug if the unRAID-specific shfs doesn't handles a file lock on a user share by creating the file lock on the actual disk share. If that doesn't happen, then it doesn't help if copy programs starts by requesting a read lock on the source file - Linux would not be able to report that the file is write-protected when the copy program then tries to open the file for write. Do your test. I expect this use case will fail and you'll be calling it a bug. If a piece of software subverts the base OS to destroy files by attempting to copy them over top of itself - it is a bug. The fact it isn't one that LimeTech can easily fix, is a different matter. 1 hour ago, FlorinB said: When you try to copy a file to itself and this ends up badly, with data loss, then for sure it is not the OS fault. I would not name it "bug" as well. This makes no sense at all. 1 hour ago, FlorinB said: Anyway this topic together with the other one from here, helped me to understand better what and how exactly this "bug" is behaving. I've responded in the thread you linked. The bug is not due to a file being referred to by different paths. The OS will recognize this situation if symlinks are used. It is only when the SHFS driver (which user shares depend upon) is in place that the bug exists. SHFS subverts the base OS protection against overwriting files. 1 Quote Link to comment
SSD Posted June 26, 2018 Share Posted June 26, 2018 @pwm / @FlorinB - Another suggestion is to rename the include / exclude options, and update the descriptions. When you turn on the "help" feature on a user share, here is what it says: These definitions are simply false. Except in a simple minded situation that the settings are set when the user share is created and no disk is ever excluded from a user share after files were place on that disk. Included / not excluded disk setting are ignored when browsing the user share. So excluded disks are always seen when browsing the user share. They are ignored when overwriting a file that exists on ANY disk in a folder with the user share name. They are ignored if the split level is satisfied on ANY disk in a folder with the user share name. They only apply when writing a file that is not being overwritten, and whose split level is not satisfied on any disk. So excluding a disk from the share does not exclude the disk from the share. A better description AND labeling should be used. Include/exclude is simply too easy to misunderstand. Maybe "Include for new files" and "Exclude for new files". At least a user will understand that it is not all encompassing. Quote Link to comment
pwm Posted June 26, 2018 Share Posted June 26, 2018 1 minute ago, SSD said: Can you give an example where an OS aliasing feature causes to OS to not be able to detect a file is being overwritten. The OS has zero reason to not allow a file to be overwritten EXCEPT if there is some action that wants to protect the file overwrite. Take this little program. It opens the same file twice and tries to copy. Will the OS stop it? #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #include <stdio.h> int main() { struct stat statbuf; if (lstat("overwrite.txt",&statbuf)) { fprintf(stderr,"Failed stat.\n"); return 1; } printf("input file %zu bytes large\n",statbuf.st_size); FILE *src = fopen("overwrite.txt","rb"); if (!src) return 1; FILE *dst = fopen("overwrite.txt","wb"); if (!src) return 1; char buf[1024]; size_t rlen = fread(buf,1,sizeof(buf),src); size_t wlen = fwrite(buf,1,rlen,dst); if (rlen != wlen) { fprintf(stderr,"Failed copying all data %zu bytes in, %zu bytes out\n",rlen,wlen); } else { printf("copied %zu bytes\n",wlen); } fclose(src); fclose(dst); return 0; } Result of test: pwm@europium:~/src/test$ ./overwrite input file 13 bytes large copied 0 bytes Oops - file was overwritten. Was unRAID involved? No! Was shfs involved? No! That was the result of a standard program directly accessing the same file twice in the local directory. No aliasing of any kind involved. So why did it happen? Because nothing told the OS that the input file "overwrite.txt" should be protected. So when the program decided to create an output file "overwrite.txt", the OS considered it ok to do. The OS depends on what applications request of it. If programs requests exclusivity etc will affect what the OS is expected to do. 17 minutes ago, SSD said: Most (all?) alias features including Windows shortcuts and Linux symlinks recognize that you are trying to copy a file on top of itself even through the feature. Even the old DOS ASSIGN and SUBST commands were smart enough to detect this. Symlinks are transparent - they get unwinded by the file open code so they end up pointing to the actual file. So it's trivial for the copy program to check if source and destination are the same. NFS, Samba, shfs, ... on the other hand can not unwind any transparent remapping - it's a open-by-proxy. Since we are talking about different name spaces, it isn't possible for a program to just "taste" the file meta-data to figure out it's the same file. But programs that issues a flock() command will tell NFS, Samba, ... to issue a flock() on the actual file. If shfs doesn't correctly handle file locks, then it's a bug in shfs. If shfs does handle file locks correctly, then you need to move your eyes on krusader and other programs supporting file copy and consider if they do all the required file locking required to gain exclusivity. 37 minutes ago, SSD said: Certainly you can't blame all of these OS commands and programs and say they are copying files incorrectly! No, I'm not blaming them because they do try to cheap and simple way of verifying if two files are the same. Below is same file name as source and destination - the normal cp command performed a stat and verified what inode the two files pointed to. Then lstat() to verify if was symlinks. stat("overwrite.txt", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 stat("overwrite.txt", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 stat("overwrite.txt", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 lstat("overwrite.txt", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 lstat("overwrite.txt", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 write(2, "cp: ", 4cp: ) = 4 write(2, "'overwrite.txt' and 'overwrite.t"..., 53'overwrite.txt' and 'overwrite.txt' are the same file) = 53 write(2, "\n", 1 Below is same when source and destination files are different: stat("other.txt", 0x7fff756e4070) = -1 ENOENT (No such file or directory) stat("overwrite.txt", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 stat("other.txt", 0x7fff756e3de0) = -1 ENOENT (No such file or directory) open("overwrite.txt", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 open("other.txt", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0 read(3, "hello world\n", 131072) = 12 write(4, "hello world\n", 12) = 12 read(3, "", 131072) = 0 close(4) = 0 close(3) = 0 So as you can see - it wasn't the OS but cp itself that verified if it would overwrite the destination file. And it can handle symlinks because they are transparent. But shfs, NFS, Samba, ... can't be transparent. And the OS can't do magic to help with the file locking operations that the copy programs do not do. 45 minutes ago, SSD said: The authors of shfs should have been able to foresee this issue and coded around it. How? The OS itself (and so shfs) must allow file overwrites. So it isn't allowed to have the OS (or shfs) block file overwrites. The mechanisms that exists is to request exclusivity. But that must be performed by the program performing the copy. It can't be done by shfs. 48 minutes ago, SSD said: A copy does not remove the source until the destination is completely written. What you are referring to here is a "move". No. What I'm referring to is a copy to a temporary file that is then moved as final step to replace any previous file. It's a standard method of implementing atomic file replacement - a program will either see the original destination file or they will see the fully copied new destination file. 50 minutes ago, SSD said: Having a copy operation that results in the source being lost ... not a bug? Call it a bug - but a bug in the copy program. The OS can't protect from this kind of copy accidents unless the OS is given the instruction to protect the file. So show where cp did instruct the OS it wanted to protect the file. 52 minutes ago, SSD said: If a piece of software subverts the base OS to destroy files by attempting to copy them over top of itself - it is a bug. I have in this post shown that cp doesn't perform any file locking. So if shfs handles flock() correctly or not, it doesn't help if cp doesn't make use of that feature. Quote Link to comment
SSD Posted June 27, 2018 Share Posted June 27, 2018 2 hours ago, pwm said: The OS has zero reason to not allow a file to be overwritten EXCEPT if there is some action that wants to protect the file overwrite. CP specifically WANTS to protect against file overwrites. So it is using the correct file modes and logic to protect against that scenario. We know that SHFS interferes with it doing its job. You say that NFS and Samba also can create overwrite opportunities, but there is no proof so far. BTW, if you compare the people using cp with the people using SHFS, you are talking about the different between the Atlantic Ocean and a mud puddle (maybe an exaggeration, but you get the idea). The amount of testing dwarfs SHFS. I can assure you if cp left holes in how it detects alias scenarios, they would have been expertly fixed long long ago. Quote Take this little program. It opens the same file twice and tries to copy. Will the OS stop it? #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #include <stdio.h> int main() { struct stat statbuf; if (lstat("overwrite.txt",&statbuf)) { fprintf(stderr,"Failed stat.\n"); return 1; } printf("input file %zu bytes large\n",statbuf.st_size); FILE *src = fopen("overwrite.txt","rb"); if (!src) return 1; FILE *dst = fopen("overwrite.txt","wb"); if (!src) return 1; char buf[1024]; size_t rlen = fread(buf,1,sizeof(buf),src); size_t wlen = fwrite(buf,1,rlen,dst); if (rlen != wlen) { fprintf(stderr,"Failed copying all data %zu bytes in, %zu bytes out\n",rlen,wlen); } else { printf("copied %zu bytes\n",wlen); } fclose(src); fclose(dst); return 0; } Result of test: pwm@europium:~/src/test$ ./overwrite input file 13 bytes large copied 0 bytes Oops - file was overwritten. Was unRAID involved? No! Was shfs involved? No! You've answered a completely different question - proving that with C you can force a file open for reading to be overwritten. C gives you a lot of control over file I/O. If you read the K&R and the C function reference they document how these file modes work. And this program is working exactly what it was written to do. This is not an example of creating the overwritten file scenario with a cp command. I'm assuming since you didn't post an example, you are not able to reproduce an example of a real user - that has never written a C program in their life - would get bitten by the OS's inability to recognize an overwrite due to some form of link/alias WITHOUT SHFS, which we know for sure can cause this. Quote That was the result of a standard program directly accessing the same file twice in the local directory. No aliasing of any kind involved. So why did it happen? Because nothing told the OS that the input file "overwrite.txt" should be protected. So when the program decided to create an output file "overwrite.txt", the OS considered it ok to do. The OS depends on what applications request of it. If programs requests exclusivity etc will affect what the OS is expected to do. Symlinks are transparent - they get unwinded by the file open code so they end up pointing to the actual file. So it's trivial for the copy program to check if source and destination are the same. NFS, Samba, shfs, ... on the other hand can not unwind any transparent remapping - it's a open-by-proxy. Since we are talking about different name spaces, it isn't possible for a program to just "taste" the file meta-data to figure out it's the same file. Ditto. Continuing to question the veracity of cp is silly. This is an SHFS byproduct. No evidence NFS or Samba create vulnerabilities. Quote But programs that issues a flock() command will tell NFS, Samba, ... to issue a flock() on the actual file. If shfs doesn't correctly handle file locks, then it's a bug in shfs. If shfs does handle file locks correctly, then you need to move your eyes on krusader and other programs supporting file copy and consider if they do all the required file locking required to gain exclusivity. I challenge you to find one that can resolve the overwrite issue that SHFS creates. If the most basic of Linux commands - cp - can't, I expect no copy program is going to be able to detect it. Quote No, I'm not blaming them because they do try to cheap and simple way of verifying if two files are the same. ??? You really think the Linux authors are being cheap in how they check for duplicate files from the cp command. That's pretty funny. We have some of the best computer scientists in the world involved in the Linux development and maintenance. I can assure you if there were a defect in cp that resulted in a source file being overwritten, it would have been reported and fixed long ago. This is a most egregious OS error. This is a cheap shot that cp is coded poorly, with no evidence. Quote Below is same file name as source and destination - the normal cp command performed a stat and verified what inode the two files pointed to. Then lstat() to verify if was symlinks. stat("overwrite.txt", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 stat("overwrite.txt", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 stat("overwrite.txt", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 lstat("overwrite.txt", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 lstat("overwrite.txt", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 write(2, "cp: ", 4cp: ) = 4 write(2, "'overwrite.txt' and 'overwrite.t"..., 53'overwrite.txt' and 'overwrite.txt' are the same file) = 53 write(2, "\n", 1 The inodes are only unique on a single disk. Every disk can have an inode 53. If the OS thinks the two files are on different disks, comparing the inodes is meaningless. Within a single user share, the same inode could very well be used multiple times and the files be on different physical disks and are not the same file. In short, an inode check is an invalid way to check for duplicates with SHFS involved. So this argument is not valid. The code is not at all clear. No idea if the current directory is on a physical disk or a user share. The "stat()" function is supposed to be in the form int stat(const char *path, struct stat *buf); But your code has the second argument is not a pointer. No idea what is in the "...". Not making sense. The write command write(2, "cp: ", 4cp: ) is not valid. No idea what this is trying to do. The "..." Quote Below is same when source and destination files are different: stat("other.txt", 0x7fff756e4070) = -1 ENOENT (No such file or directory) stat("overwrite.txt", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 stat("other.txt", 0x7fff756e3de0) = -1 ENOENT (No such file or directory) open("overwrite.txt", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=12, ...}) = 0 open("other.txt", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0 read(3, "hello world\n", 131072) = 12 write(4, "hello world\n", 12) = 12 read(3, "", 131072) = 0 close(4) = 0 close(3) = 0 So as you can see - it wasn't the OS but cp itself that verified if it would overwrite the destination file. And it can handle symlinks because they are transparent. But shfs, NFS, Samba, ... can't be transparent. And the OS can't do magic to help with the file locking operations that the copy programs do not do. Since inodes are not unique across disks, this entire argument is flawed. cp is part of the OS. Your C code is not. Code still funky. Not making any sense in this context. Your read command is reading into a string label. This would likely result in an exception of a corruption of program memory. No confidence this is working code. Now we have a manually coded number as the second argument to stat(). Should be a pointer. Quote How? The OS itself (and so shfs) must allow file overwrites. So it isn't allowed to have the OS (or shfs) block file overwrites. The mechanisms that exists is to request exclusivity. But that must be performed by the program performing the copy. It can't be done by shfs. SHFS is a low level driver. Similar low level drivers work in conjunction with the OS to identify overwrite situations. I believe SHFS could do the same. You saying its impossible is not convincing me. It may be expensive (slower), but I am confident it is possible. When you are writing in C, you can do most anything. Quote No. What I'm referring to is a copy to a temporary file that is then moved as final step to replace any previous file. It's a standard method of implementing atomic file replacement - a program will either see the original destination file or they will see the fully copied new destination file. This is what you had said ... Quote Another solution for the copy programs is if they make the copy to a temporary file name and first after a full copy performs a move to the intended destination name - requires more free disk space during the copy but guarantees that a power loss etc doesn't result in a partial destination file. A copy operation does not delete the source file. Only move operations could be impacted by a partial destination file. Unless you can't trust the copy command to work as advertised. You are right that double buffering could fix a broken copy command. But it would be silly for all of Linux to require double buffering to handle an issue with SHFS. It is the tail trying to wag the elephant. Quote Call it a bug - but a bug in the copy program. The OS can't protect from this kind of copy accidents unless the OS is given the instruction to protect the file. So show where cp did instruct the OS it wanted to protect the file. I have in this post shown that cp doesn't perform any file locking. So if shfs handles flock() correctly or not, it doesn't help if cp doesn't make use of that feature. You have not shown this at all. You have only shown that a C program can be written to enable the author to overwrite an existing file if that's what he wants to do. And presented a very simplistic argument comparing inodes, which wouldn't work with SHFS since inodes are not unique within a single user share. @pwm - I was a professional C programmer for over 15 years. Maybe a little rusty, but I know C very well. Have done work on a variety of platforms including DOS (the mainframe one), OS (mainframe), MS/DOS 1.0+, Windows 1.03+, OS/2 1.1+, AIX, and Linux. Your post is techno-babble that non-tech nerds might mistake for legitimate argument. I'm still hopeful to have a meaningful conversation. If there are other risks of overwriting files with Samba, NFS, or other programs, I am hopeful they will come out. But one thing I am sure - this issue is a SHFS issue, and not a defect in how cp detects aliased files. Quote Link to comment
ken-ji Posted June 27, 2018 Share Posted June 27, 2018 Just to add my two bits: # mkdir test1 test2 # mount -o bind test1 test2 # dd if=/dev/urandom of=test1/file1 count=1k 1024+0 records in 1024+0 records out 524288 bytes (524 kB, 512 KiB) copied, 0.0744947 s, 7.0 MB/s # ls -l test1/ test2/ test1/: total 512 -rw-r--r-- 1 root root 524288 Jun 27 10:07 file1 test2/: total 512 -rw-r--r-- 1 root root 524288 Jun 27 10:07 file1 # cp -v test1/file1 test2 cp: 'test1/file1' and 'test2/file1' are the same file Seeing that cp can actually detect the same files on a bind mount, it stands to reason that SHFS is returning a different stat attributes than the underlying file, thus fooling cp that the source and destination are different files and safe to clobber in the usual manner. So it's a bug (or as some devs like to call it: limitation) with SHFS. 1 Quote Link to comment
SSD Posted June 27, 2018 Share Posted June 27, 2018 57 minutes ago, ken-ji said: Just to add my two bits: # mkdir test1 test2 # mount -o bind test1 test2 # dd if=/dev/urandom of=test1/file1 count=1k 1024+0 records in 1024+0 records out 524288 bytes (524 kB, 512 KiB) copied, 0.0744947 s, 7.0 MB/s # ls -l test1/ test2/ test1/: total 512 -rw-r--r-- 1 root root 524288 Jun 27 10:07 file1 test2/: total 512 -rw-r--r-- 1 root root 524288 Jun 27 10:07 file1 # cp -v test1/file1 test2 cp: 'test1/file1' and 'test2/file1' are the same file Seeing that cp can actually detect the same files on a bind mount, it stands to reason that SHFS is returning a different stat attributes than the underlying file, thus fooling cp that the source and destination are different files and safe to clobber in the usual manner. So it's a bug (or as some devs like to call it: limitation) with SHFS. I think there are a couple of special challenges with SHFS: 1 - It is not determinate which physical disk is going to get a write to a user share without SHFS translating the "user share name" into a "disk specific name". And there may not be an easy way to have SHFS return that data to the OS within the contect of the copy orchestration protocol. 2 - SHFS volumes would appear to have multiple files with the same inode representing files on different physical disks. With symlinks it might be easier for cp to determine the physical disk, but with SHFS it would need help. And similar to above, the OS could not figure this out without help from SHFS. And this may not have been envisioned in the protocol. At the very least, SHFS should have petitioned the Linux governance board for a protocol change to allow SHFS to return the necessary details to allow the OS to not allow source files to be deleted. I can't help but believe they would see the value and implement it as part of a future Linux release. But given that SHFS has been around for at least 12 years, this appears to have not happened? Why? One reason might be that SHFS has not gotten complaints and therefore this has not been a priority. Another is that it IS possible to implement overwrite protection with SHFS within the current structure, and SHFS authors just haven't felt it is a priority based on few if any complaints - and this might be a non-trivial enhancement / rewrite. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.